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

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Date: Tue, 16 Aug 2011 09:07:16 +0200
>> 
>> Eli Zaretskii <address@hidden> writes:
>> 
>> >> From: Chong Yidong <address@hidden>
>> >
>> >> since there is no near-term solution, how bout turning off bidi
>> >> display reordering for prog-mode buffers?
>> >
>> > What for?  No one complained about it yet, and leaving it on helps
>> > find bugs and inefficiencies in the bidi display engine.  So my vote
>> > is NAY.
>> 
>> Sounds like the plan is to make Emacs painful to use for everyone in
>> order to make it a priority for L2R users to solve R2L problems.
>
> If L2R users don't want bidirectional support any place near them,

You are putting words into my mouth.

> to the degree that they are unwilling to help make it better at the
> cost of some moderate effort, please tell so now.

Most users are _unable_ to help.  The pretest versions are for mostly
intended for those who _are_ likely able to help.  The betas and the
final releases, however, are also for everybody else.

We have refrained from enabling features like font-locking by default in
releases until the costs of using them for everyone were under control.

Nobody is arguing to remove R2L support.  The question is about what
defaults are sensible to put into a release.  You have yourself worked
rather hard to make sure that one can have performance comparable to
before by disabling bidi support altogether.

At the current point of time, I don't think that anybody suggests
bidi-display-reordering be set to nil in the release version: work is
good enough that this need not be an issue.

Your standard reaction for regressions encountered in connection with
discussions about both performance problems as well as more fine-grained
defaults is threats.  That is not productive.  I understand that you
have invested a large amount of work into R2L typesetting, and I
understand that it is vital for your personal resources (including your
motivation) that others join in the effort.

> I will then rip out everything I did, and will forbid the FSF to ever
> use that code in any version of Emacs they distribute.  That won't
> make up for the 2 years of efforts I invested in making this happen,
> but at least I will cut my losses and won't have to go through the
> ordeal of arguing with one David Kastrup anymore.

Which is silly since I am not even a developer of Emacs anymore.  I
handed back my commit rights years ago after a similar discussion with
you.

I am now unsubscribing from the Emacs developer list in order to save
you having to worry about my person.

But you really should think whether your way of dealing with technical
problems by ostracizing is doing yourself a favor, let alone anybody
else.

-- 
David Kastrup