2011/10/11 Eli Zaretskii <e...@gnu.org>: >> Date: Tue, 11 Oct 2011 13:39:36 +0900 >> From: "Martin J. Dürst" <due...@it.aoyama.ac.jp> >> CC: libo....@gmail.com, unicode@unicode.org >> >> > Sorry, I don't follow you. There's no such "line-folding" in the >> > Emacs implementation of the UBA. A line that doesn't fit the window >> > width is reordered as a whole. Conceptually, reordering is done >> > before breaking a long line into continuation lines. >> >> This is exactly what I meant. In Emacs, reordering is done before >> breaking a long line into smaller segments to fit into the width of the >> display window. > > Okay, then what we have is a simple misunderstanding. Thanks for > clearing it up. > >> I called this "line-folding", you call it continuation lines. > > Well, "continuation lines" _is_ the Emacs terminology ;-) > >> But in the bidi algorithm itself, line breaking (be it automatic due to >> a layout algorithm or explicit due to LS or something similar) is >> applied *before* reordering. This is very important, because otherwise, >> content that is logically earlier may appear on later lines, which would >> be very confusing for readers. > > I know, but implementing this in the Emacs display engine means > terrible complications, so I opted not to do that, at least for the > first version of it.
Then your implementation is completely couterintutive: imagine what will happen if you press enter in a RTL context a line that is continued below, but all lines parts of a LTR paragraph or document: all RTL characters in the line after this position (including possily all the continuation lines below) would suddenly move upward before the position where you pressed Enter to insert a forced linebreak, and all RTL characters before that position (including on previous continued lines) would swap down... You need to make a distinction between breaks introduced only visually by automatic linewraps before continuation lines, and true line/paragraph separators that are encoded in the edited text. They behave very differently. If you cannot do that, then disable all linewraps and accept an edit mode where long paragraphs wil scroll horizontally. The UBA does not see where you'll insert linewraps as they are (usually) not encoded (the exception being the LINE SEPARATOR which is used to indicate the position of a forced linewrap, but not the end of the paragraph, so it will still blocks the reordering, but NOT the contextual directionality and the margin side on which the paragraph will be aligned) This means that you need to break lines in two separate steps: first between paragraphs or forced line breaks, then a second after determining the the direction of all characters and then remplacing their possible mirroring to infer the position of inserted linewraps (i.e. the virtual position where there could be a LINE SEPARATOR producing the same effect; most often where there are whitespaces or SHY). Reordering will still occur only after this step, and remains limited to a line not to a full paragraph.
