Topic: Replacements within block end up outside of block. (1 of 2), Read 115 times
Conf: Basic editing, Block operations
From: Deleted User
Date: Friday, December 17, 1999 11:47 AM

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:

[CS:"Index Marker"]0[$nopage]9[/CS]

And the results after each corresponding RB command:
Goto_Pos(Marker(0))
RB('|?$nopage|?','\<$nopage\>',Marker(0),Marker(9),ALL+NOERR)
results in:
[CS:"Index Marker"]\<0$nopage\>9[/CS]

Goto_Pos(Marker(0))
RB('[','\<',Marker(0),Marker(9),ALL+NOERR)
Goto_Pos(Marker(0))
RB(']','\>',Marker(0),Marker(9),ALL+NOERR)
results in:
[CS:"Index Marker"]\0<$nopage\>9[/CS]

Oddly enough, the Marker(9) position remains unchanged during either RB operation, unlike the Marker(0) position.

What I'm after is:
[CS:"Index Marker"]0\<$nopage\>9[/CS]
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:

Search('<*CS:"*Index[^>]*>',REGEXP+REVERSE+ADVANCE)
Set_Marker(0,Cur_Pos)
Goto_Pos(Marker(0))

... but this seems 'un-elegant' somehow, so I think I must be missing something here?? ...hj

 


Topic: Re: Replacements within block end up outside of block. (2 of 2), Read 116 times
Conf: Basic editing, Block operations
From: Ted Green
Date: Tuesday, December 28, 1999 07:03 PM

If you have a marker on the "a" of "abc", and replace "abc" with "xyz",
(same length) then the marker will be on "x" as you would expect.

However, if you replace "abc" with "mnopqrst", (different length) then
VEDIT internally first deletes a block of characters and then inserts
a block. This causes the marker to slide. However since it didn't
slide as much as I would have expected, I can only say that this
happens in complex code that I haven't looked at in 10 years. I'm not
sure if/when it could be improved.

There are several other work-arounds. One is to use a numeric register
(a constant) for the block-begin marker instead of a true marker.
Another is to set the market at the preceding character and then use
"Marker(0)+1".

I'll add this to the suggestion list.