emacs-bidi
[Top][All Lists]
Advanced

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

Re: [emacs-bidi] mirroring of glyphs


From: Yair Friedman (Jerusalem)
Subject: Re: [emacs-bidi] mirroring of glyphs
Date: Wed, 21 Nov 2001 09:55:26 +0200
User-agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1

"Eli Zaretskii" <address@hidden> writes:

>> From: "Yair Friedman (Jerusalem)" <address@hidden>
>> Date: Tue, 20 Nov 2001 14:56:19 +0200
>> 
>> Eli Zaretskii <address@hidden> writes:
>> 
>> > I'd expect LRO...PDF to also work, but I agree that LRM is a better 
>> > choice.
>> 
>> I don't believe that humans have much use for all bidi codes except for
>> LRM and RLM.
>
> They are needed on rare occasions, when you have nested utterances,
> like "i said `HE SAID ``she said'' ...' ..." type of phrase.  People
> rarely talk that way, but it's possible in theory.

Yes, but still most users would use LRM/RLM to get the wanted visual
results.  I expect to get the other bidi marks only from
machine-generated source.

>> > I think the Hebrew input method should insert LRMs and RLMs 
>> > automatically in cases like this one, if we can reasonably detect them.
>> 
>> Keyboard language change either by toggle-input-method command or by
>> <language-change> event might be a good candidate for this, we need to
>> wait for the next input character at that position to know if auto
>> LRM/RLM is needed.
>
> You cannot rely on language-change events, I think, since the input
> method needs to DTRT even if you move the cursor into the middle of
> text you didn't type, and then start typing.

But sometime the user does want the text to look like the output of the
UAX#9 consider:
 "START DATE: 01-JAN-2000." which is displayed as 
".2000-NAJ-01 :ETAD TRATS"
The syntax is same as my previous example, but the semantics goes with
UAX#9 this time. 

So I do think that the only time we can safely insert LRM/RLM is when the
user changed the keyboard language to insert non-strong character.
Why would the user do that in the first place?

> I think the only way to work reasonably well in such cases is to look
> at preceding and following characters, and implement some of Ehud's
> wisdom to fix UAX#9 lossage.

The following characters might not exist (yet), and generally inserting
bidi characters beyond the users back is a risky business.




reply via email to

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