<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/src/move-commands.c, branch v2.5.2</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<entry>
<title>updated copyright to 2026</title>
<updated>2026-01-01T06:59:49+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-01-01T06:59:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=c2feb2a6f71fc9adb20226fb3c2260c236e974e0'/>
<id>c2feb2a6f71fc9adb20226fb3c2260c236e974e0</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>teco_string_t is now passed by value like a scalar if the callee isn't expected to modify it</title>
<updated>2025-12-28T19:57:31+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2025-12-28T15:23:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=ea0a23645f03a42252ab1ce8df45ae4076ebae75'/>
<id>ea0a23645f03a42252ab1ce8df45ae4076ebae75</id>
<content type='text'>
* When passing a struct that should not be modified, I usually use a const pointer.
* Strings however are small 2-word objects and they are often now already passed via separate
  `gchar*` and gsize parameters. So it is consistent to pass teco_string_t by value as well.
  A teco_string_t will usually fit into registers just like a pointer.
* It's now obvious which function just _uses_ and which function _modifies_ a string.
  There is also no chance to pass a NULL pointer to those functions.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* When passing a struct that should not be modified, I usually use a const pointer.
* Strings however are small 2-word objects and they are often now already passed via separate
  `gchar*` and gsize parameters. So it is consistent to pass teco_string_t by value as well.
  A teco_string_t will usually fit into registers just like a pointer.
* It's now obvious which function just _uses_ and which function _modifies_ a string.
  There is also no chance to pass a NULL pointer to those functions.
</pre>
</div>
</content>
</entry>
<entry>
<title>properly document some functions in expressions.c and simplified code</title>
<updated>2025-07-26T13:48:56+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-07-26T13:30:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=0ea082b74414696a7800455a437656fca2886f6d'/>
<id>0ea082b74414696a7800455a437656fca2886f6d</id>
<content type='text'>
* Practically all calls to teco_expressions_args() must be preceded by teco_expressions_eval().
* In code paths where we know that teco_expressions_args() &gt; 0, it is safe
  to call teco_expressions_pop_num(0) instead of teco_expressions_pop_num_calc().
  This is both easier and faster.
* teco_expressions_pop_num_calc() is for simple applications where you just want to get
  a command argument with default (implied) values.
  Since it includes teco_expressions_eval(), we can avoid superfluous calls.
* -EC...$ turned out to be broken and is fixed now.
  A test case has been added.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Practically all calls to teco_expressions_args() must be preceded by teco_expressions_eval().
* In code paths where we know that teco_expressions_args() &gt; 0, it is safe
  to call teco_expressions_pop_num(0) instead of teco_expressions_pop_num_calc().
  This is both easier and faster.
* teco_expressions_pop_num_calc() is for simple applications where you just want to get
  a command argument with default (implied) values.
  Since it includes teco_expressions_eval(), we can avoid superfluous calls.
* -EC...$ turned out to be broken and is fixed now.
  A test case has been added.
</pre>
</div>
</content>
</entry>
<entry>
<title>revised command topics</title>
<updated>2025-07-18T13:37:13+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-07-18T13:37:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=2c236869333dd20b77109fe7e9bb4ace30c0f774'/>
<id>2c236869333dd20b77109fe7e9bb4ace30c0f774</id>
<content type='text'>
* Added some keywords.
* Consistently added command variants with all modifiers.
  In principle including modifiers in the topics is unnecessary -
  you can always strip the modifiers and look up the raw command.
  However, looking up a command with modifiers can speed up the process
  (compare looking up ?S&lt;TAB&gt; vs ?::S&lt;TAB&gt;
* The `@` modifier is listed only for commands without string arguments.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Added some keywords.
* Consistently added command variants with all modifiers.
  In principle including modifiers in the topics is unnecessary -
  you can always strip the modifiers and look up the raw command.
  However, looking up a command with modifiers can speed up the process
  (compare looking up ?S&lt;TAB&gt; vs ?::S&lt;TAB&gt;
* The `@` modifier is listed only for commands without string arguments.
</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>added `@W`, `@P`, `@V` and `@Y` command variants</title>
<updated>2025-03-29T12:29:34+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-03-29T12:15:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=ca0d7656b606703f1b5b52e59f0b46ca0038477e'/>
<id>ca0d7656b606703f1b5b52e59f0b46ca0038477e</id>
<content type='text'>
* They swap the default order of skipping characters.
  For positive arguments: first non-word chars, then word chars.
* This is especially useful after executing the non-at-modified versions.
  For instance, at the beginning of a word, `@W` jumps to its end.
  `@V` would delete the remainder of the word.
* Since they have to evaluate the at-modifier, which has syntactic
  significance, the command implementations can no longer use
  transition tables, so they are in the switch-statements instead.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* They swap the default order of skipping characters.
  For positive arguments: first non-word chars, then word chars.
* This is especially useful after executing the non-at-modified versions.
  For instance, at the beginning of a word, `@W` jumps to its end.
  `@V` would delete the remainder of the word.
* Since they have to evaluate the at-modifier, which has syntactic
  significance, the command implementations can no longer use
  transition tables, so they are in the switch-statements instead.
</pre>
</div>
</content>
</entry>
<entry>
<title>added `P` command as a reverse form of `W`</title>
<updated>2025-03-22T12:19:53+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-03-22T12:19:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=ab35f6618bc8beb4543cbc7c62332f82d7d5699c'/>
<id>ab35f6618bc8beb4543cbc7c62332f82d7d5699c</id>
<content type='text'>
* All the movement commands have shortcuts for their negative forms:
  `R` instead of `-C`, `B` instead of `-L`.
  Therefore there was always the need for a `-W` shortcut as well.
* `P` is a good choice because it is a file IO command in TECO-11,
  that does not make sense supporting.
  In Video TECO it toggles between display windows (ie. split screens)
  and I do not plan to support multiple windows in SciTECO.
* Added to the cheat sheet.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* All the movement commands have shortcuts for their negative forms:
  `R` instead of `-C`, `B` instead of `-L`.
  Therefore there was always the need for a `-W` shortcut as well.
* `P` is a good choice because it is a file IO command in TECO-11,
  that does not make sense supporting.
  In Video TECO it toggles between display windows (ie. split screens)
  and I do not plan to support multiple windows in SciTECO.
* Added to the cheat sheet.
</pre>
</div>
</content>
</entry>
<entry>
<title>factored out all cursor movement and deletion commands into the new compilation unit move-commands.c</title>
<updated>2025-03-22T12:00:51+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-03-22T11:58:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=fe69fdb29f994db3bbcaffcb202856618b03b9b0'/>
<id>fe69fdb29f994db3bbcaffcb202856618b03b9b0</id>
<content type='text'>
* This made sense to include both `W` and `V`, so we also included `D` and `K`.
  `^Q` is included since it converts between lines and glyphs.
* These are all single-letter commands, so they aren't complete parser states
  but callbacks to be referenced in teco_machine_main_transition_t.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* This made sense to include both `W` and `V`, so we also included `D` and `K`.
  `^Q` is included since it converts between lines and glyphs.
* These are all single-letter commands, so they aren't complete parser states
  but callbacks to be referenced in teco_machine_main_transition_t.
</pre>
</div>
</content>
</entry>
</feed>
