[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: Tue, 16 Aug 2011 11:40:28 +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: Tue, 16 Aug 2011 09:54:18 +0200
>> Andreas Schwab <address@hidden> writes:
>> > Eli Zaretskii <address@hidden> writes:
>> >
>> >> Translated into Emacs-speak, this means we need a variable that, when
>> >> bound to some special value, instructs the reordering engine to treat
>> >> certain characters as segment separators.
>> >
>> > They already exist: comment-start and comment-end, for example.
>> I am having a somewhat hard time imagining it as a good thing if Emacs
>> displays source code that does no longer correspond to a reasonably
>> straightforward manner of printing the file.  reordering source into
>> something that "makes more sense" seems quite more invasive than mere
>> font-locking.
> Please explain what you mean by "no longer corresponds".  If a comment
> or a string in a source file use R2L scripts, how would you like Emacs
> to display them?

With the normal bidi algorithm.

> As for printing, don't modern printers and associated software already
> reorder text when they print?

According to the normal bidi algorithm, but hardly by recognizing and
treating comment fields on their own.

> If not, we may be able to use Emacs facilities to DTRT here.

If "the right thing" is different from the rest of the world, working
with the text is tied into Emacs.

>> I am not fond of the idea of writing code that gets unreadable unless
>> you read it back with Emacs, or even a specific version of Emacs or
>> specific settings.
> ??? The discussion was about _displaying_, no one suggested writing
> anything to the file.  The idea was to use _existing_ characters or
> strings that delimit the relevant portions of source as a cue for
> reordering those delimited parts in some way that makes them readable.

If the byte stream in the file represents an unreadable result, then
Emacs should better facilitate creating a byte stream representing a
readable result (for example, by semiautomatically inserting direction
marks when the result would otherwise start looking bad) instead of
presenting a more readable result that does not corresponding to the
file contents in a straightforward manner.

When used as a mere file viewer, there is something to be said for using
higher level information than the bidi algorithm in order to give a
rendition that is better than the original.

But if Emacs is used as an editor, a writing tool, it should help to
write readable source, and presenting a more readable letter order than
the bidi algorithm or a printer or a browser could come up with is
misleading the writer.

David Kastrup

reply via email to

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