<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/src, branch v2.0.0</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<entry>
<title>distribute sciteco.desktop</title>
<updated>2023-06-19T18:20:13+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2023-06-19T18:20:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=75533443ecae81d6861bdc1402a0e4b271838979'/>
<id>75533443ecae81d6861bdc1402a0e4b271838979</id>
<content type='text'>
* Useful for packaging on platforms where we can only build from tarballs (FreeBSD)
* I don't know whether it's always safe and correct to install this file into $DATADIR/applications,
  so the file is only distributed but not installed yet.
* It contains a hardcoded binary name "gsciteco". This could actually differ
  depending on the concrete --program-prefix and it would be good to include the exact
  installation path.
  This however is not possible as long as we do not install this file.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Useful for packaging on platforms where we can only build from tarballs (FreeBSD)
* I don't know whether it's always safe and correct to install this file into $DATADIR/applications,
  so the file is only distributed but not installed yet.
* It contains a hardcoded binary name "gsciteco". This could actually differ
  depending on the concrete --program-prefix and it would be good to include the exact
  installation path.
  This however is not possible as long as we do not install this file.
</pre>
</div>
</content>
</entry>
<entry>
<title>the SciTECO data installation path is now configurable via --with-scitecodatadir</title>
<updated>2023-06-19T17:45:16+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2023-06-19T17:45:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=60a09132b62c3cae86f5e832830a4490ba5bf712'/>
<id>60a09132b62c3cae86f5e832830a4490ba5bf712</id>
<content type='text'>
* This is also the base of $SCITECOPATH.
* Changing it is useful for packaging where it is not possible to factor out the common
  files between Curses and Gtk builds into a "sciteco-common" package.
  As an alternative, you can now create disjunct sciteco-curses and sciteco-gtk packages.
* You will most likely want to use this for Gtk builds as in:
  --with-interface=gtk --program-prefix=g --with-scitecodatadir=/usr/local/share/gsciteco.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* This is also the base of $SCITECOPATH.
* Changing it is useful for packaging where it is not possible to factor out the common
  files between Curses and Gtk builds into a "sciteco-common" package.
  As an alternative, you can now create disjunct sciteco-curses and sciteco-gtk packages.
* You will most likely want to use this for Gtk builds as in:
  --with-interface=gtk --program-prefix=g --with-scitecodatadir=/usr/local/share/gsciteco.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed caret scrolling on startup</title>
<updated>2023-06-18T15:50:39+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2023-06-18T15:50:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=493504f12f79990dae7791efa27366b560151f2c'/>
<id>493504f12f79990dae7791efa27366b560151f2c</id>
<content type='text'>
* Since Scintilla no longer automatically scrolls the caret (see 941f48da6dde691a7800290cc729aaaacd051392),
  the caret wouldn't always end up in the view on startup.
* Added teco_interface_refresh() which includes SCI_SCROLLCARET and
  is invoked on startup. This helps with the Curses backend.
  It also reduces code redundancies.
* On Gtk, the caret cannot be easily scrolled on startup as long as no size is allocated
  to the window, so we also added a size-allocate callback to the
  window's event box. Sizes are less often allocated to the event box than to the
  window itself for some strange reason.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Since Scintilla no longer automatically scrolls the caret (see 941f48da6dde691a7800290cc729aaaacd051392),
  the caret wouldn't always end up in the view on startup.
* Added teco_interface_refresh() which includes SCI_SCROLLCARET and
  is invoked on startup. This helps with the Curses backend.
  It also reduces code redundancies.
* On Gtk, the caret cannot be easily scrolled on startup as long as no size is allocated
  to the window, so we also added a size-allocate callback to the
  window's event box. Sizes are less often allocated to the event box than to the
  window itself for some strange reason.
</pre>
</div>
</content>
</entry>
<entry>
<title>resolved warning in gtk-label.c due to wrong enum type</title>
<updated>2023-05-14T11:37:09+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2023-05-14T11:37:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=517ae85027f088615026fad6b880647dac5abf0a'/>
<id>517ae85027f088615026fad6b880647dac5abf0a</id>
<content type='text'>
* This probably did not cause any bugs.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* This probably did not cause any bugs.
</pre>
</div>
</content>
</entry>
<entry>
<title>FreeBSD: fixed the poll-thread memory limiting implementation - it's the default now</title>
<updated>2023-05-14T01:58:28+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2023-05-14T01:58:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=96b60afcf4293db2e6841b58500fd12d0344e75f'/>
<id>96b60afcf4293db2e6841b58500fd12d0344e75f</id>
<content type='text'>
* On FreeBSD both the dlmalloc replacement and poll-thread via sysctl() work
  but the poll-thread has been benchmarked to be significantly faster,
  at least on my machine.
  You can still ./configure --enable-malloc-replacement of course.
* Interestingly, the RSS of the process visible via htop does not decrease
  after OOMs or command-line terminations - with neither of the implementations.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* On FreeBSD both the dlmalloc replacement and poll-thread via sysctl() work
  but the poll-thread has been benchmarked to be significantly faster,
  at least on my machine.
  You can still ./configure --enable-malloc-replacement of course.
* Interestingly, the RSS of the process visible via htop does not decrease
  after OOMs or command-line terminations - with neither of the implementations.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixup EC on Win32 and interruptions via CTRL+C</title>
<updated>2023-05-12T10:12:34+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2023-05-12T10:12:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=aa2e96a3dc66b7c3607540847d8fada6bb1a6331'/>
<id>aa2e96a3dc66b7c3607540847d8fada6bb1a6331</id>
<content type='text'>
* This especially fixes spawning on 0,128ED-mode broken since
  f557af9a9112955d3b65f6ad0d54c0791189f961.
* The process is added to a job object now, which allows us to
  kill the entire process tree.
  Previously we we were leaving around orphaned processes.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* This especially fixes spawning on 0,128ED-mode broken since
  f557af9a9112955d3b65f6ad0d54c0791189f961.
* The process is added to a job object now, which allows us to
  kill the entire process tree.
  Previously we we were leaving around orphaned processes.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixup: building on UNIX</title>
<updated>2023-05-09T17:38:21+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2023-05-09T17:38:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=29bf2275f6cdf6e45f2987035097de2f79f0c6d2'/>
<id>29bf2275f6cdf6e45f2987035097de2f79f0c6d2</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed CTRL+C interruptions on Windows; optimized CTRL+C polling on Gtk+</title>
<updated>2023-05-09T17:08:32+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2023-05-09T17:08:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=f557af9a9112955d3b65f6ad0d54c0791189f961'/>
<id>f557af9a9112955d3b65f6ad0d54c0791189f961</id>
<content type='text'>
* teco_interrupt() turned out to be unsuitable to kill child processes (eg. when &lt;EB&gt; hangs).
  Instead, we have Win32-specific code now.
* Since SIGINT can be ignored on UNIX, pressing CTRL+C was not guaranteed to kill the
  child process (eg. when &lt;EB&gt; hangs).
  At the same time, it makes sense to send SIGINT first, so programs can terminate gracefully.
  The behaviour has therefore been adapted: Interrupting with CTRL+C the first time will kill
  gracefully. The second time, a more agressive signal is sent to kill the child process.
  Unfortunately, this would be relatively tricky and complicated to do on Windows, so CTRL+C will always
  "hard-kill" the child process.
* Moreover, teco_interrupt() killed the entire process on Windows when called the second time.
  This resulted in any interruption to terminate SciTECO unexpectedly when tried the second time on Gtk/Win32.
* teco_sigint_occurred renamed to teco_interrupted:
  There may be several different sources for setting this flag.
* Checking for CTRL+C on Gtk involves driving the main event loop repeatedly.
  This is a very expensive operation. We now do that only every 100ms. This is still sufficient since
  keyboard input comes from humans.
  This optimization saves 75% runtime on Windows and 90% on Linux.
  * The same optimization turned out to be contraproductive on PDCurses/WinGUI.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* teco_interrupt() turned out to be unsuitable to kill child processes (eg. when &lt;EB&gt; hangs).
  Instead, we have Win32-specific code now.
* Since SIGINT can be ignored on UNIX, pressing CTRL+C was not guaranteed to kill the
  child process (eg. when &lt;EB&gt; hangs).
  At the same time, it makes sense to send SIGINT first, so programs can terminate gracefully.
  The behaviour has therefore been adapted: Interrupting with CTRL+C the first time will kill
  gracefully. The second time, a more agressive signal is sent to kill the child process.
  Unfortunately, this would be relatively tricky and complicated to do on Windows, so CTRL+C will always
  "hard-kill" the child process.
* Moreover, teco_interrupt() killed the entire process on Windows when called the second time.
  This resulted in any interruption to terminate SciTECO unexpectedly when tried the second time on Gtk/Win32.
* teco_sigint_occurred renamed to teco_interrupted:
  There may be several different sources for setting this flag.
* Checking for CTRL+C on Gtk involves driving the main event loop repeatedly.
  This is a very expensive operation. We now do that only every 100ms. This is still sufficient since
  keyboard input comes from humans.
  This optimization saves 75% runtime on Windows and 90% on Linux.
  * The same optimization turned out to be contraproductive on PDCurses/WinGUI.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed &lt;EC&gt; interruptions on Gtk+ (and probably on PDCurses/Win32)</title>
<updated>2023-04-29T12:11:34+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2023-04-29T12:11:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=bac1efa51bf889d494013925586e87ef08307529'/>
<id>bac1efa51bf889d494013925586e87ef08307529</id>
<content type='text'>
* test case: ECwhile true; do true; done$
* Some platforms require polling via teco_interface_is_interrupted()
  for detecting interruptions, so we added an idle watcher to the
  Glib event loop in spawn.c.
* On platforms that do not require polling key presses (like Unix/ncurses),
  the idle watcher won't do any harm.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* test case: ECwhile true; do true; done$
* Some platforms require polling via teco_interface_is_interrupted()
  for detecting interruptions, so we added an idle watcher to the
  Glib event loop in spawn.c.
* On platforms that do not require polling key presses (like Unix/ncurses),
  the idle watcher won't do any harm.
</pre>
</div>
</content>
</entry>
<entry>
<title>Gtk: fixed scrolling in the command line widget</title>
<updated>2023-04-26T22:51:51+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2023-04-22T23:15:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=417ee008981c9aabc04fb574c63f3d90e232986c'/>
<id>417ee008981c9aabc04fb574c63f3d90e232986c</id>
<content type='text'>
* The caret wasn't always kept out of the UZ and at some point would totally leave the view.
  This was apparently cause by executing two SCI_SCROLLCARETs per teco_interface_cmdline_update().
* Instead, we now use a CARET_EVEN scroll policy which also works sufficiently well.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* The caret wasn't always kept out of the UZ and at some point would totally leave the view.
  This was apparently cause by executing two SCI_SCROLLCARETs per teco_interface_cmdline_update().
* Instead, we now use a CARET_EVEN scroll policy which also works sufficiently well.
</pre>
</div>
</content>
</entry>
</feed>
