From: Filipe Moreira <famoreira@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 22429@debbugs.gnu.org
Subject: bug#22429: Force character to be recognized as LTR inside RTL paragraph
Date: Fri, 22 Jan 2016 11:54:45 +0000 [thread overview]
Message-ID: <CAEOG97S2UJWrj=fx2OMDTG6pyzgjeF0NfejjYrLW6juJTF5RwQ@mail.gmail.com> (raw)
In-Reply-To: <83mvry6nq1.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 4194 bytes --]
Hi Eli,
Thank for taking the time to look into this
On Fri, Jan 22, 2016 at 8:08 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > Date: Thu, 21 Jan 2016 13:14:22 -0800
> > From: "Filipe Moreira" <famoreira@gmail.com>
> >
> > I’m using Emacs as a LaTeX editor, with the AUCTeX mode. One document I’m
> > authoring is written in English with some paragraphs in Hebrew or Greek.
> >
> > The issue I have is with mixing some neutral characters that need to be
> LTR,
> > inside a paragraph which is RTL. An example of this is the slash (i.e.
> ‘\’)
> > character used by LaTeX to signal its commands. Inside a RTL paragraph I
> > ideally want to force Emacs to always interpret the slash character, as
> well as
> > the open and close brackets (i.e. {}) as LTR.
> >
> > This is not what happens at the moment. Here I have a visual
> representation of
> > the problem:
> >
> http://emacs.stackexchange.com/questions/19696/handling-left-to-right-inside-right-to-left-paragraphs-using-emacs-and-auctex
> .
> >
> > Is it possible to whitelist some characters that should always be
> interpreted
> > as LTR?
>
> The directionality of characters is determined by their bidirectional
> class property as defined by the Unicode Character Database. Emacs
> uses those definitions in its implementation of the UBA, the Unicode
> Bidirectional Algorithm, when it lays out text for display.
> Punctuation characters, such as \, {, and } have "weak
> directionality": they take the directionality of the surrounding text,
> and if the directionality on either side is different, they default to
> the paragraph's base direction, which is RTL in your case. So that is
> what you see.
>
> 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 point somewhere regarding this? I saw the
get-char-code-property function but could not find anyway to actually
change the setting.
>
> The correct solution to these problems is to wrap the footnote block
> in the LRE..PDF or LRI..PDI control characters, so that the footnote
> is rendered independently of the surrounding bidirectional context.
> See the example below. Not sure if LaTeX will DTRT with directional
> control characters, but if it doesn't, that's a bug/misfeature in
> LaTeX.
>
> \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.
>
> Another possibility is to insert newlines between the footnote and the
> surrounding text, as shown below. Not sure if LaTeX will be happy
> with that, and I think it's uglier anyway.
>
> \begin{hebrew}
> \pstart
>
> בְּרֵאשִׁ֖ית
>
> \footnoteA{This is a Hebrew related footnote}
>
> בָּרָ֣א אֱלֹהִ֑ים אֵ֥ת הַשָּׁמַ֖יִם וְאֵ֥ת הָאָֽרֶץ׃
>
> \pend
> \end{hebrew}
>
Unfortunately for my use case this is not possible.
>
> I don't think there's a bug to fix here, so I'm going to close this
> bug report. Any objections?
>
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?
[-- Attachment #2: Type: text/html, Size: 5837 bytes --]
next prev parent reply other threads:[~2016-01-22 11:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-21 21:14 bug#22429: Force character to be recognized as LTR inside RTL paragraph Filipe Moreira
2016-01-22 8:08 ` Eli Zaretskii
2016-01-22 8:24 ` Eli Zaretskii
2016-01-22 9:31 ` Andy Moreton
2016-01-22 14:03 ` Eli Zaretskii
2016-01-22 11:54 ` Filipe Moreira [this message]
2016-01-22 14:01 ` Eli Zaretskii
2016-01-22 15:15 ` Filipe Moreira
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAEOG97S2UJWrj=fx2OMDTG6pyzgjeF0NfejjYrLW6juJTF5RwQ@mail.gmail.com' \
--to=famoreira@gmail.com \
--cc=22429@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).