From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.bidi,gmane.emacs.devel Subject: Re: merge emacs-bidi into the main tree Date: Tue, 12 Aug 2003 10:49:26 +0900 (JST) Sender: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Message-ID: <200308120149.KAA23819@etlken.m17n.org> References: <87lluax3ch.fsf@emacswiki.org> <7458-Sun03Aug2003224354+0300-eliz@elta.co.il> <87smoi9p64.fsf@emacswiki.org> <87he4x5v7x.fsf_-_@emacswiki.org> <86brv0wfyn.fsf@gerd.free-bsd.org> <6480-Fri08Aug2003180204+0300-eliz@elta.co.il> <8665l886vu.fsf@gerd.free-bsd.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1060653113 30669 80.91.224.253 (12 Aug 2003 01:51:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 12 Aug 2003 01:51:53 +0000 (UTC) Cc: gerd.moellmann@t-online.de, alex@emacswiki.org, emacs-bidi@gnu.org, developer@arabeyes.org, emacs-devel@gnu.org Original-X-From: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Tue Aug 12 03:51:51 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19mOKF-00026a-00 for ; Tue, 12 Aug 2003 03:51:51 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19mOJl-0008Lj-4f for gnu-emacs-bidi@m.gmane.org; Mon, 11 Aug 2003 21:51:21 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19mOJ6-0007vn-EY for emacs-bidi@gnu.org; Mon, 11 Aug 2003 21:50:40 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19mOIZ-0007O3-GC for emacs-bidi@gnu.org; Mon, 11 Aug 2003 21:50:38 -0400 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19mOI0-0006fe-Pv; Mon, 11 Aug 2003 21:49:33 -0400 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6p2/3.7W-20010518204228) with ESMTP id h7C1nRu27893; Tue, 12 Aug 2003 10:49:27 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.6/3.7W-20010823150639) with ESMTP id h7C1nQ904595; Tue, 12 Aug 2003 10:49:26 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id KAA23819; Tue, 12 Aug 2003 10:49:26 +0900 (JST) Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Mon, 11 Aug 2003 08:53:15 -0400) 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) X-BeenThere: emacs-bidi@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Discussion of Emacs support for multi-directional text. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-bidi-bounces+gnu-emacs-bidi=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.bidi:141 gmane.emacs.devel:15892 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:15892 Sorry for lazy responses on this thread. In article , Richard Stallman 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 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. --- Ken'ichi HANDA handa@m17n.org