From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: bidi-display-reordering is now non-nil by default Date: Mon, 15 Aug 2011 12:46:09 +0200 Organization: Organization?!? Message-ID: <87r54nymtq.fsf@fencepost.gnu.org> References: <4E48D309.6050503@acdlabs.ru> <83hb5jujjs.fsf@gnu.org> <874o1j10zv.fsf@fencepost.gnu.org> <83fwl3ugak.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1313405196 19635 80.91.229.12 (15 Aug 2011 10:46:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 15 Aug 2011 10:46:36 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 15 12:46:32 2011 Return-path: Envelope-to: ged-emacs-devel@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 1Qsugh-00035P-Lr for ged-emacs-devel@m.gmane.org; Mon, 15 Aug 2011 12:46:31 +0200 Original-Received: from localhost ([::1]:39873 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qsugh-0006hG-7t for ged-emacs-devel@m.gmane.org; Mon, 15 Aug 2011 06:46:31 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:44878) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qsugf-0006hB-0t for emacs-devel@gnu.org; Mon, 15 Aug 2011 06:46:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qsuge-00089w-0T for emacs-devel@gnu.org; Mon, 15 Aug 2011 06:46:28 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:50722) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qsugd-00089s-LG for emacs-devel@gnu.org; Mon, 15 Aug 2011 06:46:27 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Qsugc-00031s-CO for emacs-devel@gnu.org; Mon, 15 Aug 2011 12:46:26 +0200 Original-Received: from p508ed573.dip.t-dialin.net ([80.142.213.115]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Aug 2011 12:46:26 +0200 Original-Received: from dak by p508ed573.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Aug 2011 12:46:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 35 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: p508ed573.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:9yHED94SwBbzSHm7MbJiA/FYYm4= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:143233 Archived-At: Eli Zaretskii writes: >> From: David Kastrup > >> Emacs should really avoid formatting things with L2R marks that are not >> actually required. > > You are welcome to code a function that determines when it is actually > required. One problem with doing so with 100% accuracy is that the > outcome depends on the text that follows the string in question, and > sometimes even on text that precedes it. These are not always known, > and in fact the text that follows will normally be unknown. Your stance is that it is ok to pepper text prepared by Emacs (and the Emacs sources all across the board) with LRM characters as long as it has a moderate chance of getting closer to 100% accuracy _when_ Hebrew characters move into the payload. But you don't get that accuracy anyway since it _only_ works for those areas that are explicitly prepared for it, and external maintainers of modes will not change all their code on the theoretic assumption that somebody might get ugly results when injecting Hebrew. We have been that down the "everybody will adapt if forced to properly" road already with multibyte characters in 20.2 or so, when (forward-char) was different from (goto-char (1+ (point))). That approach failed and was replaced with a different, less efficient solution. Any solution that requires code review and adaptation everywhere in code that works fine without R2L content is not going to work. Blind activism is not going to solve the problem you perceive. -- David Kastrup