<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/src, branch v2.4.0</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<entry>
<title>Gtk: fixed setting the mouse cursor after changing the active buffer</title>
<updated>2025-04-19T14:00:18+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-04-19T14:00:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=29f1dea16c4ffa21926ccdc5a3b3c73a56d9437a'/>
<id>29f1dea16c4ffa21926ccdc5a3b3c73a56d9437a</id>
<content type='text'>
* The GdkWindow stacking order obviously got messed up when swapping out
  the child widget in the GtkEventBox.
* This was probably also responsible for input events coming through
  to the Scintilla view even though the GtkEventBox should block all
  input events from reaching the Scintilla view.
  The event masking in teco_view_new() is probably no longer necessary -
  but better keep it to be on the safe side.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* The GdkWindow stacking order obviously got messed up when swapping out
  the child widget in the GtkEventBox.
* This was probably also responsible for input events coming through
  to the Scintilla view even though the GtkEventBox should block all
  input events from reaching the Scintilla view.
  The event masking in teco_view_new() is probably no longer necessary -
  but better keep it to be on the safe side.
</pre>
</div>
</content>
</entry>
<entry>
<title>Gtk: prevent drag-and-drop interaction and block more possibly dangerous touch and scroll events</title>
<updated>2025-04-18T03:02:27+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-04-18T03:02:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=816d2a300b24ce65a908e251be13b3f1b93cfa81'/>
<id>816d2a300b24ce65a908e251be13b3f1b93cfa81</id>
<content type='text'>
* You could drag and drop text into the Scintilla views, which would confuse SciTECO.
* In the future, we might actually want to support programmable drag-and-drop
  support via special key macros.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* You could drag and drop text into the Scintilla views, which would confuse SciTECO.
* In the future, we might actually want to support programmable drag-and-drop
  support via special key macros.
</pre>
</div>
</content>
</entry>
<entry>
<title>curses: minor cleanup - avoid preprocessor statements</title>
<updated>2025-04-16T15:15:05+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-04-16T15:11:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=77adddb6d19a69b25c4077af8b3d878c4ad9c439'/>
<id>77adddb6d19a69b25c4077af8b3d878c4ad9c439</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>try hard to preserve the vertical scrolling position when auto-scrolling dot</title>
<updated>2025-04-15T00:43:53+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-04-15T00:43:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=29fe0a121d967b7bfbe487e11fd877df13512bf7'/>
<id>29fe0a121d967b7bfbe487e11fd877df13512bf7</id>
<content type='text'>
* There are cases, especially where the entire buffer is piped through some
  external process or when removing and reinserting large parts of the buffer,
  that dot changes very little, but the vertical scrolling position gets resets.
  This is especially noticable with the macro @^U{[: HECcat$ ]:},
  but also with M#cf (clang-format wrapper from "Useful macros").
* We now try to preserve the vertical position ("first visible line")
  before scrolling caret.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* There are cases, especially where the entire buffer is piped through some
  external process or when removing and reinserting large parts of the buffer,
  that dot changes very little, but the vertical scrolling position gets resets.
  This is especially noticable with the macro @^U{[: HECcat$ ]:},
  but also with M#cf (clang-format wrapper from "Useful macros").
* We now try to preserve the vertical position ("first visible line")
  before scrolling caret.
</pre>
</div>
</content>
</entry>
<entry>
<title>Gtk: do not attempt automatic ANSI key translation for dead keys</title>
<updated>2025-04-13T03:58:11+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-04-13T03:48:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=4254346a03a06bb612895d43329651e36ad3b482'/>
<id>4254346a03a06bb612895d43329651e36ad3b482</id>
<content type='text'>
* At least on Windows it was observed that teco_interface_get_ansi_key()
  would find ANSI keys on other layouts, but nothing corresponding to the key itself.
  For instance, for a dead caret (^), we'd find backslash.
  This made it impossible to type caret in the parser start states.
* We clumsily detect whether a keyevent refers to a dead key by checking its
  symbolic name and pass it down to the input method unmodified.
* Fixes entering dead keys, at the very least on Windows, but potentially
  on all other systems as well.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* At least on Windows it was observed that teco_interface_get_ansi_key()
  would find ANSI keys on other layouts, but nothing corresponding to the key itself.
  For instance, for a dead caret (^), we'd find backslash.
  This made it impossible to type caret in the parser start states.
* We clumsily detect whether a keyevent refers to a dead key by checking its
  symbolic name and pass it down to the input method unmodified.
* Fixes entering dead keys, at the very least on Windows, but potentially
  on all other systems as well.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed error message for nW and nP if it would move the pointer beyond the document's boundaries</title>
<updated>2025-04-13T03:58:11+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-04-13T01:50:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=59ef388128936ca846a96052938a14131067d3d2'/>
<id>59ef388128936ca846a96052938a14131067d3d2</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Curses: the mouse now scrolls two lines per event in the popup window</title>
<updated>2025-04-13T03:58:11+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-04-13T01:49:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=1208193feb641c7515c389cafe38e0e8463941df'/>
<id>1208193feb641c7515c389cafe38e0e8463941df</id>
<content type='text'>
This is hardcoded, but in line with the current defaults from
fnkeys.tes.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is hardcoded, but in line with the current defaults from
fnkeys.tes.
</pre>
</div>
</content>
</entry>
<entry>
<title>PDCurses/Win: more or less fixed mouse support</title>
<updated>2025-04-13T03:56:56+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-04-13T01:37:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=8cc704b897f33d6150156c77202a29222b9ee667'/>
<id>8cc704b897f33d6150156c77202a29222b9ee667</id>
<content type='text'>
* Both the WinGUI and Wincon variants have their own idiosyncrasies:
  * WinGUI ignores `mouseinterval(0)` and may report BUTTONX_CLICKED
    for very quick clicks.
    Therefore we now emulate separate PRESSED/RELEASED events.
  * Wincon does not report BUTTONX_RELEASED at all.
    Therefore we still enable click detection, so that fnkeys.tes will
    work at least partially.
    Therefore we also enable REPORT_MOUSE_POSITION, so that
    right-click-dragging will work.
    This should still be fixed in PDCurses upstream, though.
* See also https://github.com/Bill-Gray/PDCursesMod/issues/330
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Both the WinGUI and Wincon variants have their own idiosyncrasies:
  * WinGUI ignores `mouseinterval(0)` and may report BUTTONX_CLICKED
    for very quick clicks.
    Therefore we now emulate separate PRESSED/RELEASED events.
  * Wincon does not report BUTTONX_RELEASED at all.
    Therefore we still enable click detection, so that fnkeys.tes will
    work at least partially.
    Therefore we also enable REPORT_MOUSE_POSITION, so that
    right-click-dragging will work.
    This should still be fixed in PDCurses upstream, though.
* See also https://github.com/Bill-Gray/PDCursesMod/issues/330
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed undoing bitfields on Windows</title>
<updated>2025-04-12T22:33:43+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-04-12T21:40:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=628c73d984fd7663607cc3fd9368f809855906fd'/>
<id>628c73d984fd7663607cc3fd9368f809855906fd</id>
<content type='text'>
* It turns out that `bool` (_Bool) in bitfields may cause
  padding to the next 32-bit word.
  This was only observed on MinGW.
  I am not entirely sure why, although the C standard does
  not guarantee much with regard to bitfield memory layout
  and there are 64-bit available due to passing anyway.
  Actually, they could also be layed out in a different order.
* I am now consistently using guint instead of `bool` in bitfields
  to prevent any potential surprises.
* The way that guint was aliased with bitfield structs
  for undoing teco_machine_main_t and teco_machine_qregspec_t flags
  was therefore insecure.
  It was not guaranteed that the __flags field really "captures"
  all of the bit field.
  Even with `guint v : 1` fields, this was not guaranteed.
  We would have required a static assertion for robustness.
  Alternatively, we could have declared a `gsize __flags` variable
  as well. This __should__ be safe since gsize should always be
  pointer sized and correspond to the platform's alignment.
  However, it's also not 100% guaranteed.
  Using classic ANSI C enums with bit operations to encode multiple
  fields and flags into a single integer also doesn't look very
  attractive.
* Instead, we now define scalar types with their own teco_undo_push()
  shortcuts for the bitfield structs.
  This is in one way simpler and much more robust, but on the other
  hand complicates access to the flag variables.
* It's a good question whether a `struct __attribute__((packed))` bitfield
  with guint fields would be a reliable replacement for flag enums, that
  are communicated with the "outside" (TECO) world.
  I am not going to risk it until GCC gives any guarantees, though.
  For the time being, bitfields are only used internally where
  the concrete memory layout (bit positions) is not crucial.
* This fixes the test suite and therefore probably CI and nightly
  builds on Windows.
* Test case: Rub out `@I//` or `@Xq` until before the `@`.
  The parser doesn't know that `@` is still set and allows
  all sorts of commands where `@` should be forbidden.
* It's unknown how long this has been broken on Windows - quite
  possibly since v2.0.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* It turns out that `bool` (_Bool) in bitfields may cause
  padding to the next 32-bit word.
  This was only observed on MinGW.
  I am not entirely sure why, although the C standard does
  not guarantee much with regard to bitfield memory layout
  and there are 64-bit available due to passing anyway.
  Actually, they could also be layed out in a different order.
* I am now consistently using guint instead of `bool` in bitfields
  to prevent any potential surprises.
* The way that guint was aliased with bitfield structs
  for undoing teco_machine_main_t and teco_machine_qregspec_t flags
  was therefore insecure.
  It was not guaranteed that the __flags field really "captures"
  all of the bit field.
  Even with `guint v : 1` fields, this was not guaranteed.
  We would have required a static assertion for robustness.
  Alternatively, we could have declared a `gsize __flags` variable
  as well. This __should__ be safe since gsize should always be
  pointer sized and correspond to the platform's alignment.
  However, it's also not 100% guaranteed.
  Using classic ANSI C enums with bit operations to encode multiple
  fields and flags into a single integer also doesn't look very
  attractive.
* Instead, we now define scalar types with their own teco_undo_push()
  shortcuts for the bitfield structs.
  This is in one way simpler and much more robust, but on the other
  hand complicates access to the flag variables.
* It's a good question whether a `struct __attribute__((packed))` bitfield
  with guint fields would be a reliable replacement for flag enums, that
  are communicated with the "outside" (TECO) world.
  I am not going to risk it until GCC gives any guarantees, though.
  For the time being, bitfields are only used internally where
  the concrete memory layout (bit positions) is not crucial.
* This fixes the test suite and therefore probably CI and nightly
  builds on Windows.
* Test case: Rub out `@I//` or `@Xq` until before the `@`.
  The parser doesn't know that `@` is still set and allows
  all sorts of commands where `@` should be forbidden.
* It's unknown how long this has been broken on Windows - quite
  possibly since v2.0.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed formatting of the smallest possible integer</title>
<updated>2025-04-10T00:16:18+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-04-09T23:00:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=c462509adfd68e8b849b8a6713360fb4f9026578'/>
<id>c462509adfd68e8b849b8a6713360fb4f9026578</id>
<content type='text'>
* In other words, fixed `-9223372036854775808\` on --with-teco-integer=64
  (which is the default).
* The reason is that ABS(G_MININT64) == G_MININT64 since -G_MININT64 == G_MININT64.
  It is therefore important not to call ABS() on arbitrary teco_int_t's.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* In other words, fixed `-9223372036854775808\` on --with-teco-integer=64
  (which is the default).
* The reason is that ABS(G_MININT64) == G_MININT64 since -G_MININT64 == G_MININT64.
  It is therefore important not to call ABS() on arbitrary teco_int_t's.
</pre>
</div>
</content>
</entry>
</feed>
