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 05:03:31 -0400 Message-ID: References: <20110731.082721.451360942.wl@gnu.org> <20110731.085115.40009301.wl@gnu.org> <877h6yanje.fsf@fencepost.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1312103023 7738 80.91.229.12 (31 Jul 2011 09:03:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 31 Jul 2011 09:03:43 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 31 11:03:37 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 1QnRvr-0006jo-Po for ged-emacs-devel@m.gmane.org; Sun, 31 Jul 2011 11:03:35 +0200 Original-Received: from localhost ([::1]:33791 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnRvq-0004yr-NU for ged-emacs-devel@m.gmane.org; Sun, 31 Jul 2011 05:03:34 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:35376) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnRvp-0004yj-42 for emacs-devel@gnu.org; Sun, 31 Jul 2011 05:03:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QnRvn-0006vg-T7 for emacs-devel@gnu.org; Sun, 31 Jul 2011 05:03:33 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:33348) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QnRvn-0006vc-Nf for emacs-devel@gnu.org; Sun, 31 Jul 2011 05:03:31 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1QnRvn-0003vA-HI; Sun, 31 Jul 2011 05:03:31 -0400 In-reply-to: <877h6yanje.fsf@fencepost.gnu.org> (message from David Kastrup on Sun, 31 Jul 2011 09:59:17 +0200) 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:142550 Archived-At: > From: David Kastrup > Date: Sun, 31 Jul 2011 09:59:17 +0200 > Cc: mew-int@mew.org I've removed the mew list from the CC, as this doesn't seem to be related to mew. > > Yes, the name is always `.mew-summary'. I've CCed the mew mailing > > list so that the author of mew gets informed. It should be > > straightforward to add a proper call to `bidi-paragraph-direction' > > within the next mew release. > > I think that is a bottomless pit. I consider it nonsensical to treat a > block of aligned lines as one large paragraph where one would need to > find out the paragraph direction of the whole. The paragraph direction is determined by the paragraph beginning, not by all of it. The first "strong directional" character in the paragraph, either a left-to-right character or a right-to-left character, will determine the base direction of that paragraph. E.g., a single Latin letter is all that's needed for determining that the paragraph direction is left-to-right. > It might be nice to have the same default paragraph direction in the > whole "paragraph" for alignment purposes Alignment is not the issue here; correct display as expected by users is. > but it is nonsensical to wait for the paragraph to complete. Emacs doesn't wait for the paragraph to complete, to determine its base direction. All it needs is its beginning; one character is enough. The use case that Werner reported was with point being near the end of a very large buffer that doesn't have paragraph breaks. When point was at the beginning of that same large buffer, cursor motion was responsive enough. That's because, when redisplay is called in the middle of a paragraph, and bidi-paragraph-direction is nil, Emacs searches back to the beginning of the paragraph to determine its direction, and in this case it would search back to the beginning of this very large buffer. > With a bit of luck, the alignment uses display properties (because > otherwise proportional fonts are raining on the parade), and in the > presence of a :space display property or what our aligning properties > were called Unless I misunderstand you, the display properties are irrelevant to the issue at hand, as is alignment in general. > I think that the paragraph direction should be determined > at the end of the first line, rather than the whole "paragraph". As explained above, it is determined at the first strong directional character, much sooner than the end of the first line. > It might also be reasonable to set the paragraph boundary detection > regexps to nil in buffers where no paragraphs will ever be found How to detect these buffers? If we can detect them reliably, we could probably always set their paragraph direction to left-to-right, which would be a better default than a locale-dependent one (see below). > and let bidi revert to a (locale-dependent?) default direction for > such buffers. Experience shows that some people who need the bidirectional display work in locales that have nothing to do with R2L scripts. So I think it would be a bad misfeature to do what you suggest (IIUC). At least we should consider better alternatives before we give up in this way.