Re: Re: merge emacs-bidi into the main tree
Kenichi Handa <[email protected]>
| Newsgroups | gmane.emacs.bidi,gmane.emacs.devel |
|---|---|
| Message-ID | <[email protected]> |
In article <[email protected]>, "Eli Zaretskii" <[email protected]> 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 [email protected]