GNU bug report logs - #22429
Force character to be recognized as LTR inside RTL paragraph

Previous Next

Package: emacs;

Reported by: "Filipe Moreira" <famoreira <at> gmail.com>

Date: Thu, 21 Jan 2016 21:15:02 UTC

Severity: normal

Tags: notabug

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #26 received at 22429 <at> debbugs.gnu.org (full text, mbox):

From: Filipe Moreira <famoreira <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22429 <at> debbugs.gnu.org
Subject: Re: bug#22429: Force character to be recognized as LTR inside RTL
 paragraph
Date: Fri, 22 Jan 2016 15:15:51 +0000
[Message part 1 (text/plain, inline)]
On Fri, Jan 22, 2016 at 2:01 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Filipe Moreira <famoreira <at> gmail.com>
> > Date: Fri, 22 Jan 2016 11:54:45 +0000
> > Cc: 22429 <at> debbugs.gnu.org
> >
> >     Emacs being Emacs, you can programmatically change the bidirectional
> >     class of every character, but that change has global effect: it will
> >     affect the directionality of that character everywhere in the Emacs
> >     session. So this is not recommended.
> >
> > Also this is not recommended, I would be willing to have the bidi class
> > property of some characters set to left-to-right, like the example of
> the slash
> > character.
>
> Can you tell why?  There are ways to produce the display you expect
> without changing the character properties; I described 3 such ways.
> If you change the properties, the text will only display correctly on
> your system, any other user who displays your text, either in Emacs or
> in other editor that supports bidirectional display, will see the text
> in the same jumbled order you wanted to avoid.  So I see very little
> sense in such changes.
>
> > Can you point somewhere regarding this? I saw the
> > get-char-code-property function but could not find anyway to
> > actually change the setting.
>
> You want put-char-code-property.  Again, I very much recommend not to
> do that.
>
> >     \begin{hebrew}
> >     \pstart
> >
> >     בְּרֵאשִׁ֖ית‪\footnoteA{This is a Hebrew related footnote}‬ בָּרָ֣א
> אֱלֹהִ֑ים אֵ֥ת הַשָּׁמַ֖יִם וְאֵ֥ת
> >     הָאָֽרֶץ׃
> >
> >     \pend
> >     \end{hebrew}
> >
> >
> > In this example the direction of the surrounding Hebrew text has been
> changed.
> > The word בְּרֵאשִׁ֖ית should come before (i.e. on the right) of the word
> בָּרָ֣א. So
> > while the footnote command is correctly shown as LTR the Hebrew text has
> been
> > changed. I don't think is is the expected. See the updated image
> > (
> http://emacs.stackexchange.com/questions/19696/handling-left-to-right-inside-right-to-left-paragraphs-using-emacs-and-auctex
> )
> > that shows TextEdit correct handling of this.
>
> What version of Emacs do you have?  The above renders correctly for
> me, both in Emacs 24.5 and in the development version.  The word
> בְּרֵאשִׁ֖ית is shown to the right of the footnote, and all the rest is
> shown to the left of it.  Maybe you have an older Emacs which somehow
> has a bug?
>

I have just tested wrapping the footnote command within LTM (on both ends)
in a clean Emacs 24.5.1 (started with -Q) and it worked! This wasn't
working on my normal environment so I will need to investigate why that is.


>
> > Is there any change of having a way to set the unicode bidirectionally
> of a
> > character within each separate mode? Could this be considered a feature?
>
> I think it would be a misfeature, for the reasons explained above.
> It's the same as using a private font to display some character in a
> different shape -- you are the only one who will enjoy that shape.
>
> However, nothing prevents a mode from using put-char-code-property in
> some ingenious ways to do what you want.
>

I appreciate your help. This is all new to me and I've already learned a
lot from you and others regarding this. Thank you for making Emacs so
great.
[Message part 2 (text/html, inline)]

This bug report was last modified 9 years and 119 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.