[Top][All Lists]

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

Re: merge emacs-bidi into the main tree

From: Kenichi Handa
Subject: Re: merge emacs-bidi into the main tree
Date: Tue, 12 Aug 2003 10:49:26 +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)

Sorry for lazy responses on this thread.

In article <address@hidden>, Richard Stallman <address@hidden> writes:
>     Handa-san should give the definitive answer, but I think it was
>     always, as long as Emacs was told that the buffer _could_ contain
>     right-to-left text.  This is because Emacs doesn't know whether there
>     actually is right-to-left text in the buffer, and cannot do so easily
>     without getting a significant performance hit (what would we do?
>     search the buffer for certain ranges of characters after each change
>     to buffer's text?).

> That is acceptable, in my opinion, because it means most users
> won't lose anything.

>     However, it doesn't seem right to me to have an Emacs that cannot
>     scroll fast enough just because I've set such a flag, assuming that
>     Gerd's intuition is correct.  IMHO, of course.

As to optimization, what I disabled are, as far as I remeber:

  o direct_output_xxx
  o partial update of a line.  A line is always updated fully.

The other optimizatios should be still effective even if the
buffer local variable `enable-bidi-display' or
`orientation-reversed' are non-nil.

So, for instance, just scrolling should not be delayed.

One strong objection point I remember is about caching
reordered glyphs in (struct it).

> It is a major, but supporting your language with slower scrolling is
> better than failing to support your language at all.

>     As Handa-san says he will try to use what I did, I think this is not
>     an issue anymore.  If what I wrote has any value, I'm sure it will be
>     merged with Emacs.

> That would be very good.  Handa-san, can you tell us more about what
> you plan to do with this code, and how much work you think it will be?

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

(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.

Ken'ichi HANDA

reply via email to

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