[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bidi-display-reordering is now non-nil by default

From: David Kastrup
Subject: Re: bidi-display-reordering is now non-nil by default
Date: Sun, 31 Jul 2011 11:15:24 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Date: Sun, 31 Jul 2011 09:59:17 +0200
>> Cc: address@hidden
> 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.

So we are apparently searching for the paragraph beginning of a
humongous paragraph for each keystroke.

>> 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?

I was not suggesting detecting them.  I was suggesting that modes
creating buffers where paragraphs are not a usable concept disable
paragraph detection.  Manually.  That's another bottomless pit, but at
least it approaches the problem from an angle that is not bidi-related
and might make sense on versions (including XEmacs) that don't bother
about bidi at all and consequently don't support

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]