From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.bugs Subject: bug#9571: 24.0.50; user option to turn off bidi, please Date: Sat, 24 Sep 2011 13:30:41 -0400 Message-ID: References: <8362kjsjsk.fsf@gnu.org> <83ty83qq3e.fsf@gnu.org> <83ehz7qbts.fsf@gnu.org> <834o02t4tg.fsf@gnu.org> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: dough.gmane.org 1316885500 7653 80.91.229.12 (24 Sep 2011 17:31:40 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 24 Sep 2011 17:31:40 +0000 (UTC) Cc: 9571@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 24 19:31:35 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R7W4c-0002SD-N9 for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Sep 2011 19:31:34 +0200 Original-Received: from localhost ([::1]:46202 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7W4c-0004rL-5d for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Sep 2011 13:31:34 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:50592) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7W4Y-0004pi-OL for bug-gnu-emacs@gnu.org; Sat, 24 Sep 2011 13:31:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R7W4X-0003PG-Ef for bug-gnu-emacs@gnu.org; Sat, 24 Sep 2011 13:31:30 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56344) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R7W4X-0003PC-9Q for bug-gnu-emacs@gnu.org; Sat, 24 Sep 2011 13:31:29 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1R7W54-0005Fe-0k for bug-gnu-emacs@gnu.org; Sat, 24 Sep 2011 13:32:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Richard Stallman Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 24 Sep 2011 17:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9571 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 9571-submit@debbugs.gnu.org id=B9571.131688548120128 (code B ref 9571); Sat, 24 Sep 2011 17:32:01 +0000 Original-Received: (at 9571) by debbugs.gnu.org; 24 Sep 2011 17:31:21 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R7W4O-0005Ea-J7 for submit@debbugs.gnu.org; Sat, 24 Sep 2011 13:31:20 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R7W4J-0005EN-QK for 9571@debbugs.gnu.org; Sat, 24 Sep 2011 13:31:17 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1R7W3l-0001aI-5u; Sat, 24 Sep 2011 13:30:41 -0400 In-reply-to: <834o02t4tg.fsf@gnu.org> (message from Eli Zaretskii on Sat, 24 Sep 2011 17:04:11 +0300) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 24 Sep 2011 13:32:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:51786 Archived-At: The way I understand this request is: make it so that the result of reordering is the text in its original logical (i.e. buffer or string) order. The code that is involved in reordering, largely in bidi.c and xdisp.c, will still work as it normally does. Exactly. Again, I don't think this is what the original proponents of the option wanted, because implementing what you suggest will not bypass any of the code in the new display. IOW, I think it's an entirely different feature. Maybe you're right. I didn't follow the whole discussion. I am not sure why they particularly want to bypass code in the new display; that seems like an internal implementation detail, and I don't see why a user would care how the job gets done as long as the output is what he wants. But simply overwriting default_type with STRONG_L isn't right, either. That's because as long as we run the code in bidi.c unaltered, there are some characters whose bidirectional properties are still needed for the code to work: newlines, paragraph separators, line separators, and a few others. Ok, my proposed patch won't do the job. But wouldn't a slightly more complicated patch in the same place do the job? The method of replacing the unicode property table seems to have several drawbacks: 1. Creating the modified table is more work. 2. It is a big data structure, so having another one would be a waste. 3. It feels wrong to alter the information describing the characters. This is a matter of choosing a different way to display some characters, not a matter of redefining what they mean. I think an easy implementation in bidi_get_type is to have an if statement choose between the existing switch statement and a new switch statement. The new switch statement would return different values that would avoid reordering and give the Emacs 23 behavior. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use free telephony http://directory.fsf.org/category/tel/