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

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Precisely and explicitly, I think that using lossy conversions is not
 > a good idea, if there are practical alternatives.  Just visiting a
 > file, then saving it without changes should produce the a byte stream
 > that is identical to the original one.  I hope you agree with that.

I don't.  Not in the context of Unicode.  It should produce a sequence
of characters identical to the original one.  However, the user may
have excellent reasons for doing, say, normalization, and therefore
the sequence of bytes may be different.  Applications should be robust
to that, and I'm not terribly sympathetic to ones that aren't.

I do grant that it will often be what the user wants, especially Emacs
users, since Emacs can provide a byte-level view of the file if the
user wants that.  On the other hand, I see no reason why a
text-property-based implementation should be lossy.  Handling that
kind of thing is done all the time in serialization functions.

Regarding handling the splitting and joining of regions:

 > I mean ugly on the implementation level.  This splitting (and the
 > corresponding joining) need to be implemented,

I don't understand.  If `put-text-property' and friends don't get that
right already, more than bidi is in trouble, I should think.  What's
special about bidi?

 > So I made some decisions (and published them here almost 2 years
 > ago, btw), and implemented them.  Having used them for some time, I
 > can say that they are quite satisfactory, but that's me.

Yes, that is you.  But you're right, you have something that works for
you, more, you have no reason to believe that there's any crippling
bug in the design so it "should" work for most people who need it, and
it's time to get it out the door.