This may simply be a request for 'confirmation' of expected behavior, or, alternatively, a request to find a workaround or a change in the way the program works. The issue described here arises when you do a Replace_Block() command, and the very first (single) character in the block is replaced by more than one character. The result (unexpected in my case) is that one or more of the replaced (new) characters end up *outside* (in front of the block marker). The reason I say "unexpected" is that I thought the text markers, distinguished from the 'stream' or 'column' block markers, were "sticky" and kept their relative positions -- of course, "relative" to what is the issue here, I guess. In the following example, in which I use text markers to delineate the block, the digit "0" (zero) and the digit "9" represent the locations of the text markers, and are not actually part of the text.
The following line is the sample text string against which the RB() command is run. The digits "0" and "9" represent Marker() set positions before the Replace Block (RB) commands are executed:
And the results after each corresponding RB command:
Oddly enough, the Marker(9) position remains unchanged during either RB operation, unlike the Marker(0) position.
What I'm after is:
With either set of RB commands, there is at least *one* character "outside" of the Marker "block." This character(s) are then lost to downstream operations. What I'm after is an absolute marker position such that all 'edits' (any change in characters, length, etc. caused by an RB -- or other -- operation, happens strictly within the confines of Marker(0) and Marker(9). This is comparable to thinking of the block as an 'inline' text register, I guess. I guess I could set the beginning marker to the character offset from the beginning of the file...
What I've done for now is 'reset' the Marker(0) position after the RB operations, as follows:
... but this seems 'un-elegant' somehow, so I think I must be missing something here?? ...hj