Michael Gerz wrote:
Abdelrazak Younes schrieb:
Michael Gerz wrote:
Abdelrazak Younes schrieb:
Michael Gerz wrote:
Abdelrazak Younes schrieb:
I don't understand, why the space in the first line should be
deleted?
<deleted space> means a space that was marked as deleted.
Use the attached lyx file. Press return after "hello". The leading
spaces are marked as deleted but the screen is not updated.
Well, I still don't understand because the screen seems fine here,
see attached.
No, the screen is not fine: the second space should be marked as
deleted!
Why is that? Before I hit "Enter", the second space was not deleted;
was should it be deleted after?
The semantics of stripLeadingSpaces() is, well, to strip _all_ leading
spaces. Since the second space is a leading space, too, it is marked as
deleted in CT mode. stripLeadingSpaces() works as intended but the
screen is not updated afterwards.
Right now, stripLeadingSpaces() returns the number of _physically_
deleted spaces. I can change this to return the number of physically and
logically characters.
Yes, I guess we should do that.
This may help but may also prevent some
optimizations in DEPM.
I also don't understand why we return false at the end of
deleteEmptyParMech() even if stripLeadingSpaces returns !0.
I've change that and now the crash is gone because going up with the
arrow key will trigger the DEPM and the metrics will then be updated.
Still, I guess my commit only cures the symptom because the second
paragraph is still wrong. At least it's now wrong in the paragraph
contents also. If you want the space to be deleted as soon as the new
paragraph is created, we need to call stripLeadingSpaces() on the new
paragraph also, and we don't do that in DEPM.
Ah, and we
should clarify/document the meaning of the return value of
deleteEmptyParMech...
Yes.
Abdel.
What do you think? I am a bit lost without your assistance...
Michael