Michael Gerz wrote:
Hi,
I rethought the logic of stripLeadingSpaces() and came to the conclusion
that it is not a good idea to remove the spaces in change tracking mode:
imagine that your co-author inserts a par break that you don't like. If
you revert his par break (revert = reject change, not undo!), you would
like to see the spaces restored.
I changed stripLeadingSpaces accordingly (see attached patch) but
unfortunately I ran into two problems that look like painting/update
problems.
By switching CT on and off, create a one-line document that looks like
this:
hello<deleted space><space>world
Now, in CT mode, press return after "hello". The expected output is:
hello
<deleted space><deleted space>world
I don't understand, why the space in the first line should be deleted?
Two <deleted space> does not sound right anyway.
However, this is what I get on screen:
hello
<deleted space><space>world
I don't understand exactly what I am supposed to do get this behaviour.
When I hit return I have the same thing on the second line than what was
in the first line after "hello".
In other words, the deletion of the second space is not shown on screen.
Maybe dEPM is triggered? You probably have to modify this method to take
into account TrackChange.
Even worse, if I move the cursor up (to first line) and down (back to
second line), LyX crashes!
I manage to reproduce that. Do you remember the Peter's fix in
numberOfHfills() that got reverted at the end. This is exactly what
happens here.
I can't imagine that my fix is responsible for this crash. Abdel, do you
have any idea of what goes wrong?
I think that you have to distinguish the document model from what is on
screen. On screen, the row representation does not care if one char is a
<space> or a <deleted space>, seven chars are seven chars.
I guess this is the problem and you have to skip deleted char in
numberOfHfills() or something like that.
Abdel.
