From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: bidi-display-reordering is now non-nil by default Date: Sun, 31 Jul 2011 03:01:37 -0400 Message-ID: References: <834o23cfo3.fsf@gnu.org> <20110731.082122.325564649.wl@gnu.org> <20110731.084435.229758248.wl@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1312095707 3590 80.91.229.12 (31 Jul 2011 07:01:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 31 Jul 2011 07:01:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: Werner LEMBERG Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 31 09:01:44 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 1QnQ1v-00039C-Fd for ged-emacs-devel@m.gmane.org; Sun, 31 Jul 2011 09:01:43 +0200 Original-Received: from localhost ([::1]:54439 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnQ1u-0003Nb-84 for ged-emacs-devel@m.gmane.org; Sun, 31 Jul 2011 03:01:42 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:37771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnQ1r-0003NV-Kz for emacs-devel@gnu.org; Sun, 31 Jul 2011 03:01:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QnQ1q-0003KN-Jd for emacs-devel@gnu.org; Sun, 31 Jul 2011 03:01:39 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:55317) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnQ1q-0003Jv-FR for emacs-devel@gnu.org; Sun, 31 Jul 2011 03:01:38 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1QnQ1p-0003TD-TY; Sun, 31 Jul 2011 03:01:38 -0400 In-reply-to: <20110731.084435.229758248.wl@gnu.org> (message from Werner LEMBERG on Sun, 31 Jul 2011 08:44:35 +0200 (CEST)) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:142546 Archived-At: > Date: Sun, 31 Jul 2011 08:44:35 +0200 (CEST) > Cc: emacs-devel@gnu.org > From: Werner LEMBERG > > > Emacs is searching for the beginning of the paragraph, but this > > whole buffer is one huge paragraph. The manual explains the > > significance of the paragraph direction for the bidirectional > > display, in case you are interested in the details. > > Thanks. Does a limit exist (say, 100kByte) as a maximum value for a > paragraph length after that bidi-paragraph-direction is automatically > set to right-to-left (if not overridden specifically) to circumvent > this problem? You mean left-to-right, not right-to-left, yes? Setting the base paragraph direction in that buffer to right-to-left will make the display barely legible. There's no such feature currently, no. It could be easily added, but I'm not sure such a heuristics is justified; it certainly can Do The Wrong Thing in some cases, e.g., I could imagine a similar use case with some mail summary buffer, but with the message numbers spelled in Arabic digits and most of the Subject lines in Arabic or Farsi. In that case, the correct direction is actually right-to-left. As another example, I have a large text file with the entire Bible in Hebrew, which is again one huge paragraph -- but its direction should be right-to-left. The design of determining the base paragraph direction dynamically as part of redisplay is based on the assumption that most buffers either have small enough paragraphs to not cause any significant slowdown, or else are specialized buffers whose correct base direction is 100% predictable in advance. If you (or someone else) can see use cases that break this assumption, please describe those use cases.