Re: [Emacs-diffs] /srv/bzr/emacs/trunk r105429: New function `string-mark-left-to-right' for handling LRMs.

[Chong Yidong]

Eli Zaretskii <address@hidden> writes:

>> This algorithm (which the code implements) is wrong: the unwanted
>> reordering can happen even if the string does not end in a strong R
>> character.  It could end in a series of weak characters, if the strong
>> character preceding that is R, for example.

OK, so basically we have to scan the entire string like this, right?

  (let ((len (length str))
        (n 0)
        rtl-found)
    (while (and (not rtl-found) (< n len))
      (setq rtl-found (memq (get-char-code-property
                             (aref str n) 'bidi-class) '(R AL))
            n (1+ n)))
    (if rtl-found
        (concat str (propertize (string ?\x200e) 'invisible t))
      str)))

> And since buffer-menu.el was already modified to use this function, it
> is easy to see how this algorithm fails: make a buffer whose name is
> made of all R2L characters with the "<1>" tail appended, then type
> "C-x C-b" and watch the messed-up display.  The original code treated
> this case correctly.

Actually, it looks as though the <1> is not treated properly, even with
the old code.  If I do

    (rename-buffer (concat "السّلام عليكم"
                           "<1>"))

then the buffer is displayed as 1>[some Arabic text]>, both in the
mode-line and in the buffer menu.  I guess the code that appends the
"<n>" needs to use string-mark-left-to-right as well.

For extra hilarity, get rid of the newline in this code fragment and
watch as the redisplayed Emacs Lisp code turns into gibberish...