Here are some representations of some text with applied properties "1", "2" and
"3" and the effect of various substitute commands. All properties types used
to generate the following examples have 'start_incl' and 'end_incl' set.
|abcdefghijklm|',
0 The original text 111 222 333
1 s/a/xx/ => |xxbcdefghijklm|',
111 222 333
2 s/b/xx/ => |axxcdefghijklm|',
1111 222 333
3 s/bcd/xxx => |axxxefghijklm|', (1)
111 222 333
4 s/bcd/xxx => |axxxefghijklm|',
normal 0 axxx 222 333
5 s/bcd// => |aefghijklm|', (2)
222 333
6 s/abcde// => |fghijklm|', (3)
222 333
7 s/bcdefgh// => |aijklm|', (4)
333
8 s/cdef/xxx??yy => |abxxx??yyghijklm|',
111111 222 333
9 s/cdefghij/xxx??yy => |abxxx??yyklm|', (5)
11 222 333
Notes:
I think that one reasonable expectation is that the removal of 'bcd' would
also remove the property and then the 'xxx' would be inserted without any
property.
For comparison, example 4 produces the same text, but the 'xxx'
is not covered by property '1' (it is still there, zero length).
Use of proplist() shows that property '1' is still present, but zero
length. Note that it is not possible to add zero length properties.
Property '1' is still present, but zero length and moved to column 1.
Properties '1' and '2' are both zero length at column 2.
I cannot discern the rules that lead to both result (8) and (9).
After quite a bit of thought, I belive that the general rule should be that
substitution behaves like a delete operation (for the matching expression),
followed by an insert operation (for the substitution expression). This is easy
to explain and understand, and makes it easy to predict behaviour.
This would mean that for example (3) above, the result would be the same as for
example (4). This is one case where I anticipate some people might think that
Vim's current behaviour is preferable/more correct. There is currently
one property test that fails if (3) actually behaves like (4). This was added
for issue #4397, which is actually to do with backslashes in the substitution
expression.
I am working on a PR that implements the simple rule suggested, as part of
fixing a number of other related text property issues. The question of
behaviour (3) versus (4) is one thing I think it is important to consult on
before I submit the PR.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()