> Date: Fri, 5 Feb 2010 14:21:49 +0200 > From: "Ehud Karni" <[email protected]> > Cc: [email protected], [email protected], [email protected] > > On Thu, 04 Feb 2010 21:40:32 Eli Zaretskii wrote: > > > > Please! Newspapers don't have truncated and continued lines, they > > have newlines between every two lines. With newlines, the bidi > > display will show exactly what you (and every other Hebrew reader) > > expect. > > I think you got it wrong here. Newspaper article are written a whole > paragraph without new lines on a wide screen and then reflowed to > the column width. You can do it with any word processor, and change > the width when you print and get the same behavior.
Emacs's way of re-flowing is by inserting newlines. Continuation lines are not it, because they break the line in an arbitrary place, like the middle of a word. This is a no-no in any newspaper article. > I propose the following: use a virtual "right-margin-goal-column" (a > real one if given, and if not it is the screen width), do a virtual > `fill-paragraph' on the line, and do the bidi processing on the > result, BUT without inserting any real new-lines. I explained elsewhere why this does not solve the problem: the reordering code works below the glyph layout code, so it has no idea when it has reached the right-margin-goal-column. At least I don't know how to do that; ideas are welcome. The reordering code can do what you want if we somehow tell it at which _buffer_position_ to stop, as if it hits a newline or a paragraph separator. But buffer positions are not equivalent to display positions, due to display features like: . variable fonts and faces . glyphs that come from overlays, `display' properties, images, etc. . `wrap-prefix' and `line-prefix' variables . composite characters . tab expansion (probably forgot a few). Note that the last one affects text terminals as well, so even there you cannot simply count characters. > It has the shortcoming of not going exactly up to right edge (or left > edge for R2L paragraph), but it will have the benefit of not breaking > words and allowing normal reading for long line with embedding text of > the opposite direction. The problem is that, for the reasons I explain above and in a previous message in this thread, what you suggest will still end up overflowing the margin sometimes, and we are back with the same problem. (If I understood your suggestion, that is; if not, please point out where I'm wrong.) _______________________________________________ emacs-bidi mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-bidi
