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



Reply via email to