[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r105429: New function `string-mar

From: Eli Zaretskii
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r105429: New function `string-mark-left-to-right' for handling LRMs.
Date: Fri, 12 Aug 2011 10:21:16 +0300

> From: Chong Yidong <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Thu, 11 Aug 2011 15:01:16 -0400
> OK, so basically we have to scan the entire string like this, right?


Btw, is there a way to regex-search for a character by its bidi
category?  That would make the code more elegant, and probably quite
faster as well.

>   (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))
Make that '(R AL RLO), since the RLO character overrides the
bidirectional properties of all the following characters with R.

> > 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 didn't mean the display of the buffer name itself; that is a
separate issue, as discussed here:


I meant the buffer menu layout: with the current bzr tip, the buffer
size was displayed to the left of the buffer name, whereas the
previous code displayed it to the right of the name, as with buffer
names without R2L characters.

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

That's one of the problems that are not yet solved in Emacs: how to
display code with comments and strings in R2L languages without
messing up the display and without giving up the reordering of the
strings and comments.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]