[Top][All Lists]

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

Re: [emacs-bidi] Re: merge emacs-bidi into the main tree

From: Kenichi Handa
Subject: Re: [emacs-bidi] Re: merge emacs-bidi into the main tree
Date: Tue, 12 Aug 2003 16:18:12 +0900 (JST)
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.2.92 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI)

In article <address@hidden>, "Eli Zaretskii" <address@hidden> writes:
>>  In brief, what I did in emacs-bidi are:
>>  (1) change xdisp.c to call get_next_display_element_visually
>>    and set_iterator_to_next_visually instead of
>>    get_next_display_element and set_iterator_to_next.
>>  (2) make a new file bidi.c that implements
>>    get_next_display_element_visually and
>>    set_iterator_to_next_visually.
>>  (3) make a new file bidi.el that implements simple
>>    bidi-reordering function that is called from
>>    get_next_display_element_visually to create a cache in
>>    (struct it).
>>  (4) change xterm.c to display glyphs flushing to right when
>>    orientation-reversed is non-nil.
>>  My current plan is to replace (2) and (3) with Eli's code.

> It's not gonna be that simple ;-)

> (To save future work, some crucial information about the characters
> over which we scan is cached inside the bidi_it struct, to facilitate
> processing later when we need to go back to those characters and
> generate the glyph matrix elements from them.  So, in the above
> example, going back from 'D' to 'A' boils down to delivering
> information already cached during the forward scan.)

Then, it seems that what you've done is not that different
from the current emacs-bidi.  In most cases, we anyway move
the iterator all over "abcdABCDefg".  Your code caches only
some crucial information, so get_next_display_element will
need some work at C B A e f g.  My code caches all
information given by get_next_display_element, so
get_next_display_element will work fast at C B A e f g.

In both cases, set_iterator_to_next (your code) and
set_iterator_to_next_visually (my code) moves IT_CHARPOS
(*it) non-linearly.

So, I still think incorporating your code is not that difficult.

> (There still needs to be more code in the terminal-specific parts of
> Emacs, that displays the glyphs either starting at the left or the
> right margin of the screen/window, depending on the current
> paragraph's base direction; the latter gets decided by subroutines of
> bidi_get_next_char_visually and is stored in the bidi_it structure.  I
> believe this code, at least for the X terminals, already largely
> exists in m17n.org's emacs-bidi.)

Yes.  "(4) change xterm.c" does that.

Ken'ichi HANDA

reply via email to

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