emacs-devel
[Top][All Lists]
Advanced

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

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


From: Eli Zaretskii
Subject: Re: bidi-display-reordering is now non-nil by default
Date: Thu, 18 Aug 2011 10:23:09 +0300

> From: Lars Magne Ingebrigtsen <address@hidden>
> Date: Thu, 18 Aug 2011 01:14:40 +0200
> 
> I've now done this for the "from" part of the summary lines as a test.
> As you can see from the attachment, my Hebrew-ish name gets chopped and
> LRM-eyd correctly, as far as I can see, so it seems like a workable
> approach:
> 
> !  [   5: Lars Magne שלום Ingebri‎] This is a test

It looks okay, but that's not the real test, because it will render
correctly even without the LRM.  The real test is to have your "from"
_end_ with strong R characters, and have the next field in the summary
begin with weak characters, like digits.  For example, remove the
"Ingebrigtsen" part, and start the Subject with "123".  Then try that
with and without the LRM.

> However, this feels like an extremely leaky, er, abstraction.  I think
> it would be better if all y'all can find a solution that doesn't require
> these extreme low-level hacks just to get text rendered properly.  I
> kinda doubt that all package maintainers will expend the hackery time
> needed to twiddle these knobs.

I'd appreciate ideas.  We currently have these:

  . Use LRM at the end of the field

  . Use TABs between fields

  . Replace each field with a display string whose value is the field
    text, with the disadvantage that cursor motion across the field
    and editing of the fields' text will need to be explicitly coded

  . Add a feature where a small set of characters can be requested by
    the Lisp application to behave like segment separator (TAB), then
    use those to separate fields, with the caveat that those separator
    characters should never appear as part of fields themselves

> But for Emacs 24, that's probably not realistic?

Depends on the idea, I guess.




reply via email to

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