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.
OK, IIUC, then you will have two deleted space then, right? Again, IIUC,
the paragraph contents should still contain the two spaces but
isDeleted(0) and (1) would return true, right?
If yes, then as I said, there is a problem even before the screen update
problem because while debugging I noticed that there was only _one_
leading space, not two.
I can change this to return the number of physically and
logically characters. This may help but may also prevent some
optimizations in DEPM.
I think that DEPM is indeed the culprit here and we have to teach it to
disregard deleted spaces (and deleted paragraphs for the matter).
I also don't understand why we return false at the end of
deleteEmptyParMech() even if stripLeadingSpaces returns !0. Ah, and we
should clarify/document the meaning of the return value of
deleteEmptyParMech...
What do you think? I am a bit lost without your assistance...
I have to study the code before answering you. Maybe what I said above
will help you.
Abdel.
