From unknown Thu Jun 19 14:27:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#22429: Force character to be recognized as LTR inside RTL paragraph Resent-From: "Filipe Moreira" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 21 Jan 2016 21:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 22429 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 22429@debbugs.gnu.org X-Debbugs-Original-To: Received: via spool by submit@debbugs.gnu.org id=B.145341088124142 (code B ref -1); Thu, 21 Jan 2016 21:15:02 +0000 Received: (at submit) by debbugs.gnu.org; 21 Jan 2016 21:14:41 +0000 Received: from localhost ([127.0.0.1]:56807 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aMMYv-0006HB-Sg for submit@debbugs.gnu.org; Thu, 21 Jan 2016 16:14:41 -0500 Received: from eggs.gnu.org ([208.118.235.92]:36743) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aMMYt-0006Gz-TP for submit@debbugs.gnu.org; Thu, 21 Jan 2016 16:14:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMMYn-00012I-LA for submit@debbugs.gnu.org; Thu, 21 Jan 2016 16:14:30 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_IMAGE_ONLY_32,HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:36733) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMMYn-00012E-Hl for submit@debbugs.gnu.org; Thu, 21 Jan 2016 16:14:29 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55947) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMMYm-0001VU-HV for bug-gnu-emacs@gnu.org; Thu, 21 Jan 2016 16:14:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMMYi-000107-3o for bug-gnu-emacs@gnu.org; Thu, 21 Jan 2016 16:14:28 -0500 Received: from mail-qg0-x22f.google.com ([2607:f8b0:400d:c04::22f]:35152) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMMYh-000103-UJ for bug-gnu-emacs@gnu.org; Thu, 21 Jan 2016 16:14:24 -0500 Received: by mail-qg0-x22f.google.com with SMTP id o11so42592026qge.2 for ; Thu, 21 Jan 2016 13:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:message-id:date:content-type:from:mime-version:to; bh=+yVTgPBXO+1ZojpVopBsMPnCA1wYUkCcQxoHIBMhgJQ=; b=kQoU3YdMUW5/mh77o2Sxs9J0SPxatdt85BJiQVWor2c9Nzo2nGGPhgXUcecjFJP8Vy a0JDsQA8ODAFrI4oqj5DKL1Pv34JNfyUopnIk8tlCOXdfBrd1frQBZFn4QL53AD93NdB 31OPdrCkUIszIo74kgh3HXw9rS2zG3ub3BPkUEVkax4xGOieO6zwfMzMZtiX586kc5FF 84nvEs0sCmzPMhjKIEsYJv8mRUFS6V4AX4Jr2mICXmog2uyMyVJ2LD34KnGxnL7uONSr 5X/QcnrPmr5OVRoeub1EANiEvpEGqsniLbOYeS8ku9C9Eh0Ecr7SBgAxc/lsSugy/EqS ByHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:message-id:date:content-type:from :mime-version:to; bh=+yVTgPBXO+1ZojpVopBsMPnCA1wYUkCcQxoHIBMhgJQ=; b=RovEVeENIlUqlmTNk19R0y3WC+YTI6gYgwmzGoVPYxRKVOx8VF3ScZ7ISEgtlUqIO4 Q3CeU3Zqmgj+y5TpATcF4px4EwFrNkpiCXGZSawQ5vxjf2mx67q6q1c8TPS95J4KiAIH RHbhQxqcLGIpwHsjMPdjJ79f6cfyoKXre6JyeYz8rvWiS0Q5yRZO9Dyobhw+NQedlHh6 oiABq2B1m25AgQl9HKWZ3zp7eJgf3cPbMwqjWwZ9yB5V2dEQt5xl2JJD9KfnxByEG7Bp GQ93uI+4hSt6aP3IB9cOH1fM65gTehpz1V6h/u+SqbYWaY6Lqiqpf6P04NorHQ5Bmhcz QXAA== X-Gm-Message-State: ALoCoQnghTPJNJm+ixLB8OVUSGelPUk8Vl8A9ZLiWzqzMtN2MyAOlbtX5skzIk4F/YKse4zc5u8aUsrcaVGBuGISg87YFNmfjw== X-Received: by 10.140.86.85 with SMTP id o79mr54308929qgd.3.1453410863487; Thu, 21 Jan 2016 13:14:23 -0800 (PST) Received: from localhost (ec2-54-163-97-98.compute-1.amazonaws.com. [54.163.97.98]) by smtp.gmail.com with ESMTPSA id 100sm1372230qgi.17.2016.01.21.13.14.22 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 13:14:23 -0800 (PST) Message-ID: <56a13f4844c61b5100000006@polymail.io> Date: Thu, 21 Jan 2016 13:14:22 -0800 Content-Type: multipart/mixed; boundary=8a363907398c5809660afd51fa38600ef0337790cbc23ab02db277700413 From: "Filipe Moreira" X-Mailer: Polymail X-Polymail-Id: 56a13f4844c61b5100000006 X-Polymail-Pg: Do things that dont scale Mime-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --8a363907398c5809660afd51fa38600ef0337790cbc23ab02db277700413 Content-Type: multipart/alternative; boundary=335800c350fa7b01fb0159f3c44728cd7c1813ce0d383e4c976a152c4f37 --335800c350fa7b01fb0159f3c44728cd7c1813ce0d383e4c976a152c4f37 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi everyone, I=E2=80=99m using Emacs as a LaTeX editor, with the AUCTeX mode. One docume= nt I=E2=80=99m authoring is written in English with some paragraphs in Hebr= ew or Greek.=C2=A0 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. = =E2=80=98\=E2=80=99) character used by LaTeX to signal its commands. Inside= a RTL paragraph I ideally want to force Emacs to always interpret the slas= h character, as well as the open and close brackets (i.e. {}) as LTR.=C2=A0 This is not what happens at the moment. Here I have a visual representation= of the problem:=C2=A0 http://emacs.stackexchange.com/questions/19696/handling-left-to-right-insid= e-right-to-left-paragraphs-using-emacs-and-auctex . Is it possible to whitelist some characters that should always be interpret= ed as LTR? Thanks Filipe Moreira --=C2=A0 Freelance Web Developer(Ruby & Javascript) http://coderelax.com/ --335800c350fa7b01fb0159f3c44728cd7c1813ce0d383e4c976a152c4f37 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGltZyBzdHlsZT0iYm9yZGVyOiBub25lOyBiYWNrZ3JvdW5kOm5vbmU7IiBzcmM9Imh0dHBzOi8v d2Vsb3ZlcGcucG9seW1haWwuaW8vdjEvei9hL0t5M2J5Wk9SaG05X0xsR18vQVlVWllNeFVGR1hY V3FET1oyV3F2aFJYMWJXc3VxYjBfTmp4Vi1scEZROEdNRFBPZXFhX0lRa1VkZ05jbTZROW1fZF93 OGxCQnlaX1lfZzg2dklBVHFhbFJCUVNKdzNleVVScjQ3ZHZsVHZVOWYzc3Nyd2cucG5nIiBhbHQ9 IiIgd2lkdGg9IjBweCIgaGVpZ2h0PSIwcHgiIGJvcmRlcj0iMCIgLz48aGVhZD48L2hlYWQ+PGJv ZHkgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl OyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+SGkgZXZlcnlvbmUsPGRp dj48YnI+PC9kaXY+PGRpdj5J4oCZbSB1c2luZyBFbWFjcyBhcyBhIExhVGVYIGVkaXRvciwgd2l0 aCB0aGUgQVVDVGVYIG1vZGUuIE9uZSBkb2N1bWVudCBJ4oCZbSBhdXRob3JpbmcgaXMgd3JpdHRl biBpbiBFbmdsaXNoIHdpdGggc29tZSBwYXJhZ3JhcGhzIGluIEhlYnJldyBvciBHcmVlay4mbmJz cDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZSBpc3N1ZSBJIGhhdmUgaXMgd2l0aCBtaXhp bmcgc29tZSBuZXV0cmFsIGNoYXJhY3RlcnMgdGhhdCBuZWVkIHRvIGJlIExUUiwgaW5zaWRlIGEg cGFyYWdyYXBoIHdoaWNoIGlzIFJUTC4gQW4gZXhhbXBsZSBvZiB0aGlzIGlzIHRoZSBzbGFzaCAo aS5lLiDigJhc4oCZKSBjaGFyYWN0ZXIgdXNlZCBieSBMYVRlWCB0byBzaWduYWwgaXRzIGNvbW1h bmRzLiBJbnNpZGUgYSBSVEwgcGFyYWdyYXBoIEkgaWRlYWxseSB3YW50IHRvIGZvcmNlIEVtYWNz IHRvIGFsd2F5cyBpbnRlcnByZXQgdGhlIHNsYXNoIGNoYXJhY3RlciwgYXMgd2VsbCBhcyB0aGUg b3BlbiBhbmQgY2xvc2UgYnJhY2tldHMgKGkuZS4ge30pIGFzIExUUi4mbmJzcDs8L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PlRoaXMgaXMgbm90IHdoYXQgaGFwcGVucyBhdCB0aGUgbW9tZW50LiBI ZXJlIEkgaGF2ZSBhIHZpc3VhbCByZXByZXNlbnRhdGlvbiBvZiB0aGUgcHJvYmxlbTombmJzcDs8 YSBocmVmPSJodHRwOi8vZW1hY3Muc3RhY2tleGNoYW5nZS5jb20vcXVlc3Rpb25zLzE5Njk2L2hh bmRsaW5nLWxlZnQtdG8tcmlnaHQtaW5zaWRlLXJpZ2h0LXRvLWxlZnQtcGFyYWdyYXBocy11c2lu Zy1lbWFjcy1hbmQtYXVjdGV4Ij5odHRwOi8vZW1hY3Muc3RhY2tleGNoYW5nZS5jb20vcXVlc3Rp b25zLzE5Njk2L2hhbmRsaW5nLWxlZnQtdG8tcmlnaHQtaW5zaWRlLXJpZ2h0LXRvLWxlZnQtcGFy YWdyYXBocy11c2luZy1lbWFjcy1hbmQtYXVjdGV4PC9hPi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2PklzIGl0IHBvc3NpYmxlIHRvIHdoaXRlbGlzdCBzb21lIGNoYXJhY3RlcnMgdGhhdCBzaG91 bGQgYWx3YXlzIGJlIGludGVycHJldGVkIGFzIExUUj88L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2 PlRoYW5rczxicj48YnI+PGRpdiBpZD0icHNpZ25hdHVyZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiBy Z2IoMzUsIDMxLCAzMik7IGZvbnQtZmFtaWx5OiBOeWxhcy1Qcm8sIEhlbHZldGljYSwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxNXB4OyBsaW5lLWhlaWdodDogMjFweDsgd2lkb3dzOiAxOyBiYWNr Z3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5GaWxpcGUgTW9yZWlyYTwvc3Bhbj48 YnIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IC13ZWJraXQtdXNlci1zZWxlY3Q6IGlu aGVyaXQ7IGNvbG9yOiByZ2IoMzUsIDMxLCAzMik7IGZvbnQtZmFtaWx5OiBOeWxhcy1Qcm8sIEhl bHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyBsaW5lLWhlaWdodDogMjFweDsg d2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48c3BhbiBz dHlsZT0iY29sb3I6IHJnYigzNSwgMzEsIDMyKTsgZm9udC1mYW1pbHk6IE55bGFzLVBybywgSGVs dmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IGxpbmUtaGVpZ2h0OiAyMXB4OyB3 aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPi0tJm5ic3A7 PC9zcGFuPjxiciBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgLXdlYmtpdC11c2VyLXNl bGVjdDogaW5oZXJpdDsgY29sb3I6IHJnYigzNSwgMzEsIDMyKTsgZm9udC1mYW1pbHk6IE55bGFz LVBybywgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE1cHg7IGxpbmUtaGVpZ2h0 OiAyMXB4OyB3aWRvd3M6IDE7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsi PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDM1LCAzMSwgMzIpOyBmb250LWZhbWlseTogTnlsYXMt UHJvLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTVweDsgbGluZS1oZWlnaHQ6 IDIxcHg7IHdpZG93czogMTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+ RnJlZWxhbmNlIFdlYiBEZXZlbG9wZXIoUnVieSAmYW1wOyBKYXZhc2NyaXB0KTwvc3Bhbj48YnIg c3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IC13ZWJraXQtdXNlci1zZWxlY3Q6IGluaGVy aXQ7IGNvbG9yOiByZ2IoMzUsIDMxLCAzMik7IGZvbnQtZmFtaWx5OiBOeWxhcy1Qcm8sIEhlbHZl dGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4OyBsaW5lLWhlaWdodDogMjFweDsgd2lk b3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48YSBocmVmPSJo dHRwOi8vY29kZXJlbGF4LmNvbS8iIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyAtd2Vi a2l0LXVzZXItc2VsZWN0OiBpbmhlcml0OyBjb2xvcjogcmdiKDY1LCAxNTUsIDI0OSk7IGZvbnQt ZmFtaWx5OiBOeWxhcy1Qcm8sIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNXB4 OyBsaW5lLWhlaWdodDogMjFweDsgd2lkb3dzOiAxOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1 LCAyNTUsIDI1NSk7Ij5jb2RlcmVsYXguY29tPC9hPjwvZGl2PjwvZGl2PjwvYm9keT4= --335800c350fa7b01fb0159f3c44728cd7c1813ce0d383e4c976a152c4f37-- --8a363907398c5809660afd51fa38600ef0337790cbc23ab02db277700413-- From unknown Thu Jun 19 14:27:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#22429: Force character to be recognized as LTR inside RTL paragraph Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Jan 2016 08:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22429 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Filipe Moreira" Cc: 22429@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 22429-submit@debbugs.gnu.org id=B22429.145345008030695 (code B ref 22429); Fri, 22 Jan 2016 08:08:01 +0000 Received: (at 22429) by debbugs.gnu.org; 22 Jan 2016 08:08:00 +0000 Received: from localhost ([127.0.0.1]:56939 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aMWlE-0007z0-4q for submit@debbugs.gnu.org; Fri, 22 Jan 2016 03:08:00 -0500 Received: from eggs.gnu.org ([208.118.235.92]:59499) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aMWlC-0007ym-Q1 for 22429@debbugs.gnu.org; Fri, 22 Jan 2016 03:07:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMWl4-0004SD-EA for 22429@debbugs.gnu.org; Fri, 22 Jan 2016 03:07:53 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33778) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMWl4-0004S9-Ar; Fri, 22 Jan 2016 03:07:50 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4923 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aMWl3-0001xY-N4; Fri, 22 Jan 2016 03:07:50 -0500 Date: Fri, 22 Jan 2016 10:08:06 +0200 Message-Id: <83mvry6nq1.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <56a13f4844c61b5100000006@polymail.io> (famoreira@gmail.com) References: <56a13f4844c61b5100000006@polymail.io> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Thu, 21 Jan 2016 13:14:22 -0800 > From: "Filipe Moreira" > > 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. 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} 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} I don't think there's a bug to fix here, so I'm going to close this bug report. Any objections? From unknown Thu Jun 19 14:27:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#22429: Force character to be recognized as LTR inside RTL paragraph Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Jan 2016 08:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22429 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: famoreira@gmail.com Cc: 22429@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 22429-submit@debbugs.gnu.org id=B22429.145345104832177 (code B ref 22429); Fri, 22 Jan 2016 08:25:02 +0000 Received: (at 22429) by debbugs.gnu.org; 22 Jan 2016 08:24:08 +0000 Received: from localhost ([127.0.0.1]:56957 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aMX0p-0008Mv-Un for submit@debbugs.gnu.org; Fri, 22 Jan 2016 03:24:08 -0500 Received: from eggs.gnu.org ([208.118.235.92]:34919) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aMX0o-0008MT-8e for 22429@debbugs.gnu.org; Fri, 22 Jan 2016 03:24:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMX0g-0008Nx-3o for 22429@debbugs.gnu.org; Fri, 22 Jan 2016 03:24:01 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34054) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMX0g-0008Nr-0O; Fri, 22 Jan 2016 03:23:58 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4948 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aMX0f-0003wl-CS; Fri, 22 Jan 2016 03:23:57 -0500 Date: Fri, 22 Jan 2016 10:24:14 +0200 Message-Id: <83k2n26mz5.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <83mvry6nq1.fsf@gnu.org> (message from Eli Zaretskii on Fri, 22 Jan 2016 10:08:06 +0200) References: <56a13f4844c61b5100000006@polymail.io> <83mvry6nq1.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Fri, 22 Jan 2016 10:08:06 +0200 > From: Eli Zaretskii > Cc: 22429@debbugs.gnu.org > > 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. Actually, LRM should also work, you just need to put it on both sides of the footnote, like below: \begin{hebrew} \pstart בְּרֵאשִׁ֖ית‎\footnoteA{This is a Hebrew related footnote}‎ בָּרָ֣א אֱלֹהִ֑ים אֵ֥ת הַשָּׁמַ֖יִם וְאֵ֥ת הָאָֽרֶץ׃ \pend \end{hebrew} From unknown Thu Jun 19 14:27:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#22429: Force character to be recognized as LTR inside RTL paragraph In-Reply-To: <56a13f4844c61b5100000006@polymail.io> Resent-From: Andy Moreton Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Jan 2016 09:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22429 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 22429@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.14534551335843 (code B ref -1); Fri, 22 Jan 2016 09:33:02 +0000 Received: (at submit) by debbugs.gnu.org; 22 Jan 2016 09:32:13 +0000 Received: from localhost ([127.0.0.1]:56985 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aMY4j-0001W9-Dm for submit@debbugs.gnu.org; Fri, 22 Jan 2016 04:32:13 -0500 Received: from eggs.gnu.org ([208.118.235.92]:49969) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aMY4h-0001Vx-CC for submit@debbugs.gnu.org; Fri, 22 Jan 2016 04:32:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMY4b-000841-Ch for submit@debbugs.gnu.org; Fri, 22 Jan 2016 04:32:06 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:46052) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMY4b-00083w-9w for submit@debbugs.gnu.org; Fri, 22 Jan 2016 04:32:05 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMY4a-0004Rg-H7 for bug-gnu-emacs@gnu.org; Fri, 22 Jan 2016 04:32:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMY4X-000830-Be for bug-gnu-emacs@gnu.org; Fri, 22 Jan 2016 04:32:04 -0500 Received: from plane.gmane.org ([80.91.229.3]:41105) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMY4X-00080d-2i for bug-gnu-emacs@gnu.org; Fri, 22 Jan 2016 04:32:01 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aMY4P-000136-Bg for bug-gnu-emacs@gnu.org; Fri, 22 Jan 2016 10:31:53 +0100 Received: from 82-69-64-228.dsl.in-addr.zen.co.uk ([82.69.64.228]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Jan 2016 10:31:53 +0100 Received: from andrewjmoreton by 82-69-64-228.dsl.in-addr.zen.co.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Jan 2016 10:31:53 +0100 X-Injected-Via-Gmane: http://gmane.org/ From: Andy Moreton Date: Fri, 22 Jan 2016 09:31:39 +0000 Lines: 33 Message-ID: <86h9i6ot8k.fsf@gmail.com> References: <56a13f4844c61b5100000006@polymail.io> <83mvry6nq1.fsf@gnu.org> <83k2n26mz5.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 82-69-64-228.dsl.in-addr.zen.co.uk User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (windows-nt) Cancel-Lock: sha1:PIeCfHoNj3A7nR6v1x+QasKsE7k= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.8 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.8 (---) On Fri 22 Jan 2016, Eli Zaretskii wrote: >> Date: Fri, 22 Jan 2016 10:08:06 +0200 >> From: Eli Zaretskii >> Cc: 22429@debbugs.gnu.org >> >> 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. > > Actually, LRM should also work, you just need to put it on both sides > of the footnote, like below: > > \begin{hebrew} > \pstart > > בְּרֵאשִׁ֖ית‎\footnoteA{This is a Hebrew related footnote}‎ בָּרָ֣א אֱלֹהִ֑ים אֵ֥ת הַשָּׁמַ֖יִם וְאֵ֥ת הָאָֽרֶץ׃ > > \pend > \end{hebrew} While reading this message, I noticed odd behaviour of cursor motion with and (i.e. right-char and left-char). I would expect repeated to move in logical order until the end of the buffer, but it gets stuck on the newline after "\pstart". Likewise repeated from the end gets stuck at the newline before "\pend". Saving this text in a file "foo.txt" showed the same behaviour (using the latest emacs-25 branch with "emacs -Q"). Is this expected ? AndyM From unknown Thu Jun 19 14:27:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#22429: Force character to be recognized as LTR inside RTL paragraph Resent-From: Filipe Moreira Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Jan 2016 11:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22429 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 22429@debbugs.gnu.org Received: via spool by 22429-submit@debbugs.gnu.org id=B22429.145346373320534 (code B ref 22429); Fri, 22 Jan 2016 11:56:02 +0000 Received: (at 22429) by debbugs.gnu.org; 22 Jan 2016 11:55:33 +0000 Received: from localhost ([127.0.0.1]:57050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aMaJQ-0005L8-LN for submit@debbugs.gnu.org; Fri, 22 Jan 2016 06:55:33 -0500 Received: from mail-qg0-f46.google.com ([209.85.192.46]:36122) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aMaJO-0005Kv-Iu for 22429@debbugs.gnu.org; Fri, 22 Jan 2016 06:55:31 -0500 Received: by mail-qg0-f46.google.com with SMTP id e32so55366174qgf.3 for <22429@debbugs.gnu.org>; Fri, 22 Jan 2016 03:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2uGq9osdZ7amVyQHQHZRk4DcvdrYO1K4EjKVNTjacz8=; b=hpValq2Tpidh5oIh6trMISNpHHJZws6FVYnhC+m1FuPQVnR2CrVE2OCzj7kOAbA+yQ RGDwmdVI4y7/3DhQLUI28XaG2ZZnwO4E1FK8rfJ2n8dy3A96A9bFg+awKbXN1KL6rlsg detI+W5Vl00/zNky3I80M7TuONsnTkLj4uy+wXcKBFzeYtcsT8Q1o60ZFdLqjTk8gAk/ 5OLL8hLSr2tCY3OMOk3f+ocan4n9f7bID4OivMcBDZJ0EFKSk5rAJMXtWmhWq0NR/toB SfH9Zl7DPwIXJ8cNp4c3eDNTALcnZ8ROvcWRegbmsCOh1o/fSYq/QoS4bqm7nwN2wjQp vJxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2uGq9osdZ7amVyQHQHZRk4DcvdrYO1K4EjKVNTjacz8=; b=Y0vWbnQNZAE8Gn/c7WazJXdqvPJ1xy2fQaN7/r4+NZP7z+IDKGPdCpIZ6gJv28PTpz 1YwH2XdaE/9g6A0sZvH9YVQhYSeyHsVnosbYt+kACvYxHi/eBW1pd1Jjk/2/vkiCFQCY ZWc7vA5gKlV0hpDTseE3IKctsqOtxUnAZcFuiJu+RMZ8KtOBM7afilUhauqBt8L8u3fW pyhVBIBH6Umo/onVdOp7/reqm9uCdpXDCdD7MiXzz4AIMAsx7gPzSVe5WrTRri1jGxtf EEzJ6Umhi7bw/Cj3+/SmLF5Sm8nIxc6e7UFzJH5NUADvkhDTWe0PmSD0N4I9ghX3kHy2 4jAg== X-Gm-Message-State: AG10YOSGniWr+HIOiQNvSxGBvaypGLWX1vYkctgMMqvmEQ0xr/VU90Lex5K8TawdXllBodU6th6O0/IroV1eSA== X-Received: by 10.140.18.136 with SMTP id 8mr2930560qgf.64.1453463724755; Fri, 22 Jan 2016 03:55:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.135.199 with HTTP; Fri, 22 Jan 2016 03:54:45 -0800 (PST) In-Reply-To: <83mvry6nq1.fsf@gnu.org> References: <56a13f4844c61b5100000006@polymail.io> <83mvry6nq1.fsf@gnu.org> From: Filipe Moreira Date: Fri, 22 Jan 2016 11:54:45 +0000 Message-ID: Content-Type: multipart/alternative; boundary=001a113546420215fb0529eae586 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a113546420215fb0529eae586 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Eli, Thank for taking the time to look into this On Fri, Jan 22, 2016 at 8:08 AM, Eli Zaretskii wrote: > > Date: Thu, 21 Jan 2016 13:14:22 -0800 > > From: "Filipe Moreira" > > > > I=E2=80=99m using Emacs as a LaTeX editor, with the AUCTeX mode. One do= cument I=E2=80=99m > > 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. > =E2=80=98\=E2=80=99) > > 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-ins= ide-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 > > =D7=91=D6=BC=D6=B0=D7=A8=D6=B5=D7=90=D7=A9=D7=81=D6=B4=D6=96=D7=99=D7=AA= =E2=80=AA\footnoteA{This is a Hebrew related footnote}=E2=80=AC =D7=91=D6= =BC=D6=B8=D7=A8=D6=B8=D6=A3=D7=90 > =D7=90=D6=B1=D7=9C=D6=B9=D7=94=D6=B4=D6=91=D7=99=D7=9D =D7=90=D6=B5=D6=A5= =D7=AA =D7=94=D6=B7=D7=A9=D6=BC=D7=81=D6=B8=D7=9E=D6=B7=D6=96=D7=99=D6=B4= =D7=9D =D7=95=D6=B0=D7=90=D6=B5=D6=A5=D7=AA =D7=94=D6=B8=D7=90=D6=B8=D6=BD= =D7=A8=D6=B6=D7=A5=D7=83 > > \pend > \end{hebrew} > In this example the direction of the surrounding Hebrew text has been changed. The word =D7=91=D6=BC=D6=B0=D7=A8=D6=B5=D7=90=D7=A9=D7=81=D6=B4=D6= =96=D7=99=D7=AA should come before (i.e. on the right) of the word =D7=91=D6=BC=D6=B8=D7=A8=D6=B8=D6=A3=D7=90. 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-insid= e-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 > > =D7=91=D6=BC=D6=B0=D7=A8=D6=B5=D7=90=D7=A9=D7=81=D6=B4=D6=96=D7=99=D7=AA > > \footnoteA{This is a Hebrew related footnote} > > =D7=91=D6=BC=D6=B8=D7=A8=D6=B8=D6=A3=D7=90 =D7=90=D6=B1=D7=9C=D6=B9=D7=94= =D6=B4=D6=91=D7=99=D7=9D =D7=90=D6=B5=D6=A5=D7=AA =D7=94=D6=B7=D7=A9=D6=BC= =D7=81=D6=B8=D7=9E=D6=B7=D6=96=D7=99=D6=B4=D7=9D =D7=95=D6=B0=D7=90=D6=B5= =D6=A5=D7=AA =D7=94=D6=B8=D7=90=D6=B8=D6=BD=D7=A8=D6=B6=D7=A5=D7=83 > > \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? --001a113546420215fb0529eae586 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Eli,

Thank for taking the time to lo= ok 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=E2=80=99m using Emacs as a LaTeX editor, with the AUCTeX mode. One d= ocument I=E2=80=99m
> authoring is written in English with some paragraphs in Hebrew or Gree= k.
>
> The issue I have is with mixing some neutral characters that need to b= e LTR,
> inside a paragraph which is RTL. An example of this is the slash (i.e.= =E2=80=98\=E2=80=99)
> character used by LaTeX to signal its commands. Inside a RTL paragraph= I
> ideally want to force Emacs to always interpret the slash character, a= s well as
> the open and close brackets (i.e. {}) as LTR.
>
> This is not what happens at the moment. Here I have a visual represent= ation of
> the problem:
> http://emacs.stackexchange.com/questions/19696= /handling-left-to-right-inside-right-to-left-paragraphs-using-emacs-and-auc= tex.
>
> Is it possible to whitelist some characters that should always be inte= rpreted
> as LTR?

The directionality of characters is determined by their bidirectional
class property as defined by the Unicode Character Database.=C2=A0 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.=C2=A0 So tha= t 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.=C2=A0 So this is not recommended.

<= div>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 se= tting.
=C2=A0

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.=C2=A0 Not sure if LaTeX will DTRT with directional control characters, but if it doesn't, that's a bug/misfeature in LaTeX.

\begin{hebrew}
=C2=A0 \pstart

=D7=91=D6=BC=D6=B0=D7=A8=D6=B5=D7=90=D7=A9=D7=81=D6=B4=D6=96=D7=99=D7=AA=E2= =80=AA\footnoteA{This is a Hebrew related footnote}=E2=80=AC =D7=91=D6=BC= =D6=B8=D7=A8=D6=B8=D6=A3=D7=90 =D7=90=D6=B1=D7=9C=D6=B9=D7=94=D6=B4=D6=91= =D7=99=D7=9D =D7=90=D6=B5=D6=A5=D7=AA =D7=94=D6=B7=D7=A9=D6=BC=D7=81=D6=B8= =D7=9E=D6=B7=D6=96=D7=99=D6=B4=D7=9D =D7=95=D6=B0=D7=90=D6=B5=D6=A5=D7=AA = =D7=94=D6=B8=D7=90=D6=B8=D6=BD=D7=A8=D6=B6=D7=A5=D7=83

=C2=A0 \pend
\end{hebrew}

In this example the direct= ion of the surrounding Hebrew text has been changed. The word =D7=91=D6=BC= =D6=B0=D7=A8=D6=B5=D7=90=D7=A9=D7=81=D6=B4=D6=96=D7=99=D7=AA should come be= fore (i.e. on the right) of the word =D7=91=D6=BC=D6=B8=D7=A8=D6=B8=D6=A3= =D7=90. 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 update= d image (http= ://emacs.stackexchange.com/questions/19696/handling-left-to-right-inside-ri= ght-to-left-paragraphs-using-emacs-and-auctex) that shows TextEdit corr= ect handling of this.
=C2=A0

Another possibility is to insert newlines between the footnote and the
surrounding text, as shown below.=C2=A0 Not sure if LaTeX will be happy
with that, and I think it's uglier anyway.

\begin{hebrew}
=C2=A0 \pstart

=D7=91=D6=BC=D6=B0=D7=A8=D6=B5=D7=90=D7=A9=D7=81=D6=B4=D6=96=D7=99=D7=AA
\footnoteA{This is a Hebrew related footnote}

=D7=91=D6=BC=D6=B8=D7=A8=D6=B8=D6=A3=D7=90 =D7=90=D6=B1=D7=9C=D6=B9=D7=94= =D6=B4=D6=91=D7=99=D7=9D =D7=90=D6=B5=D6=A5=D7=AA =D7=94=D6=B7=D7=A9=D6=BC= =D7=81=D6=B8=D7=9E=D6=B7=D6=96=D7=99=D6=B4=D7=9D =D7=95=D6=B0=D7=90=D6=B5= =D6=A5=D7=AA =D7=94=D6=B8=D7=90=D6=B8=D6=BD=D7=A8=D6=B6=D7=A5=D7=83

=C2=A0 \pend
\end{hebrew}

Unfortunately for my use c= ase this is not possible.=C2=A0

I don't think there's a bug to fix here, so I'm going to close = this
bug report.=C2=A0 Any objections?

Is th= ere any change of having a way to set the unicode bidirectionally of =C2=A0= a character within each separate mode? Could this be considered a feature?<= /div>

--001a113546420215fb0529eae586-- From unknown Thu Jun 19 14:27:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#22429: Force character to be recognized as LTR inside RTL paragraph Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Jan 2016 14:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22429 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Filipe Moreira Cc: 22429@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 22429-submit@debbugs.gnu.org id=B22429.145347126512424 (code B ref 22429); Fri, 22 Jan 2016 14:02:01 +0000 Received: (at 22429) by debbugs.gnu.org; 22 Jan 2016 14:01:05 +0000 Received: from localhost ([127.0.0.1]:57182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aMcGu-0003EK-OJ for submit@debbugs.gnu.org; Fri, 22 Jan 2016 09:01:04 -0500 Received: from eggs.gnu.org ([208.118.235.92]:35485) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aMcGq-0003Di-Hr for 22429@debbugs.gnu.org; Fri, 22 Jan 2016 09:01:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMcGi-0005se-AY for 22429@debbugs.gnu.org; Fri, 22 Jan 2016 09:00:55 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50923) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMcGi-0005sZ-6Z; Fri, 22 Jan 2016 09:00:52 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1227 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aMcGh-0003Jd-E9; Fri, 22 Jan 2016 09:00:51 -0500 Date: Fri, 22 Jan 2016 16:01:07 +0200 Message-Id: <83a8nx7ly4.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Filipe Moreira on Fri, 22 Jan 2016 11:54:45 +0000) References: <56a13f4844c61b5100000006@polymail.io> <83mvry6nq1.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Filipe Moreira > Date: Fri, 22 Jan 2016 11:54:45 +0000 > Cc: 22429@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? > 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. From unknown Thu Jun 19 14:27:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#22429: Force character to be recognized as LTR inside RTL paragraph Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Jan 2016 14:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22429 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andy Moreton Cc: 22429@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 22429-submit@debbugs.gnu.org id=B22429.145347142212647 (code B ref 22429); Fri, 22 Jan 2016 14:04:02 +0000 Received: (at 22429) by debbugs.gnu.org; 22 Jan 2016 14:03:42 +0000 Received: from localhost ([127.0.0.1]:57186 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aMcJS-0003Hv-6N for submit@debbugs.gnu.org; Fri, 22 Jan 2016 09:03:42 -0500 Received: from eggs.gnu.org ([208.118.235.92]:36227) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aMcJR-0003Hi-3U for 22429@debbugs.gnu.org; Fri, 22 Jan 2016 09:03:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMcJI-0006MO-DE for 22429@debbugs.gnu.org; Fri, 22 Jan 2016 09:03:36 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50973) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMcJI-0006MK-93; Fri, 22 Jan 2016 09:03:32 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1228 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aMcJH-0006ig-63; Fri, 22 Jan 2016 09:03:31 -0500 Date: Fri, 22 Jan 2016 16:03:48 +0200 Message-Id: <838u3h7ltn.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <86h9i6ot8k.fsf@gmail.com> (message from Andy Moreton on Fri, 22 Jan 2016 09:31:39 +0000) References: <56a13f4844c61b5100000006@polymail.io> <83mvry6nq1.fsf@gnu.org> <83k2n26mz5.fsf@gnu.org> <86h9i6ot8k.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Andy Moreton > Date: Fri, 22 Jan 2016 09:31:39 +0000 > > While reading this message, I noticed odd behaviour of cursor motion > with and (i.e. right-char and left-char). > > I would expect repeated to move in logical order until the end > of the buffer, but it gets stuck on the newline after "\pstart". > Likewise repeated from the end gets stuck at the newline before > "\pend". > > Saving this text in a file "foo.txt" showed the same behaviour (using the > latest emacs-25 branch with "emacs -Q"). Is this expected ? Yes, expected. The paragraph direction changes when you enter a paragraph that has a different base direction, and the arrow keys are sensitive to the paragraph base direction. From unknown Thu Jun 19 14:27:10 2025 X-Loop: help-debbugs@gnu.org Subject: bug#22429: Force character to be recognized as LTR inside RTL paragraph Resent-From: Filipe Moreira Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Jan 2016 15:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22429 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 22429@debbugs.gnu.org Received: via spool by 22429-submit@debbugs.gnu.org id=B22429.145347580619910 (code B ref 22429); Fri, 22 Jan 2016 15:17:02 +0000 Received: (at 22429) by debbugs.gnu.org; 22 Jan 2016 15:16:46 +0000 Received: from localhost ([127.0.0.1]:57988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aMdS6-0005B0-8b for submit@debbugs.gnu.org; Fri, 22 Jan 2016 10:16:46 -0500 Received: from mail-qk0-f177.google.com ([209.85.220.177]:34682) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aMdS0-0005Aj-K7 for 22429@debbugs.gnu.org; Fri, 22 Jan 2016 10:16:40 -0500 Received: by mail-qk0-f177.google.com with SMTP id x1so29720801qkc.1 for <22429@debbugs.gnu.org>; Fri, 22 Jan 2016 07:16:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LS1m+H7VTGIfd9xgL0qawcjkuSpDTd/uoUH7femgMUc=; b=R47ki8w7LKs7lVfbatG2IVhluFJcfBeOrOE5Et3LvJ5LdKfcXpUjYbj3Zn/j5/mLO0 B9gspDO76M1DawA1UBSA6UDmQO2esRqbvpjeuLfz6/oy4FEpF0kE4lsbcX4xtlepRDpG F4EQdTiWslTlNLQ8f/DSsNZQNwWLFUOOPiAweZZpU0cEU97wHV4ugMaOqAnaY/ejve2X XbOhVUXvgqIpnY5C/CaXIIL4s6SjF02aM2XuhYQFhpsR4USF/NW6CYrdy2ydhyc6X5oE 3zKXeNFLgFIuvW9R5gVItVTJbUNcL8pcFK88eVfSmDKBIIC+2JQXYwM9qBhe+9xeHw2l ZZHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LS1m+H7VTGIfd9xgL0qawcjkuSpDTd/uoUH7femgMUc=; b=Nob8GWK49m4Gv3gbQ85fnANLY1wd3nUe+0Xacb7W4y9VmV4CEUHjZerbDLMIou6i4R 0JJ6UKE7Dd+Q9L+koaDwkixkmnoQpZlCKSS4gRpAzp3o414xRF7cHrsmkuvnFFisq9K0 nZbMz5p688n+ns4pqsLuRZ72ksts96XKi940g2f0edrwEDaCLYzEqUIgathWgCmVRt5o o9JwoxzlNY4V00X+g6loGHKSQyMuwkL2FnpfruoDJDD67aZSpFsiq6cjGaU/b2defduZ wgSugWFhJWgUWP1On9gAY01prPopHm1FN6jIvg3cKwJZcU9eVc6nVc9OZznpI976Cg6j 3f7A== X-Gm-Message-State: AG10YOT3JcGbJw4fgDv258+Z3nrYaAbxMjTzbHfnFFRyJPmwn4OZ0Tp9BFE7pckQeXA73BVDa1EPw79g7LVEnw== X-Received: by 10.55.53.208 with SMTP id c199mr4311743qka.109.1453475790975; Fri, 22 Jan 2016 07:16:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.135.199 with HTTP; Fri, 22 Jan 2016 07:15:51 -0800 (PST) In-Reply-To: <83a8nx7ly4.fsf@gnu.org> References: <56a13f4844c61b5100000006@polymail.io> <83mvry6nq1.fsf@gnu.org> <83a8nx7ly4.fsf@gnu.org> From: Filipe Moreira Date: Fri, 22 Jan 2016 15:15:51 +0000 Message-ID: Content-Type: multipart/alternative; boundary=001a11470ed235f96a0529edb40d X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11470ed235f96a0529edb40d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 22, 2016 at 2:01 PM, Eli Zaretskii wrote: > > From: Filipe Moreira > > Date: Fri, 22 Jan 2016 11:54:45 +0000 > > Cc: 22429@debbugs.gnu.org > > > > Emacs being Emacs, you can programmatically change the bidirectiona= l > > class of every character, but that change has global effect: it wil= l > > 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 > > > > =D7=91=D6=BC=D6=B0=D7=A8=D6=B5=D7=90=D7=A9=D7=81=D6=B4=D6=96=D7=99= =D7=AA=E2=80=AA\footnoteA{This is a Hebrew related footnote}=E2=80=AC =D7= =91=D6=BC=D6=B8=D7=A8=D6=B8=D6=A3=D7=90 > =D7=90=D6=B1=D7=9C=D6=B9=D7=94=D6=B4=D6=91=D7=99=D7=9D =D7=90=D6=B5=D6=A5= =D7=AA =D7=94=D6=B7=D7=A9=D6=BC=D7=81=D6=B8=D7=9E=D6=B7=D6=96=D7=99=D6=B4= =D7=9D =D7=95=D6=B0=D7=90=D6=B5=D6=A5=D7=AA > > =D7=94=D6=B8=D7=90=D6=B8=D6=BD=D7=A8=D6=B6=D7=A5=D7=83 > > > > \pend > > \end{hebrew} > > > > > > In this example the direction of the surrounding Hebrew text has been > changed. > > The word =D7=91=D6=BC=D6=B0=D7=A8=D6=B5=D7=90=D7=A9=D7=81=D6=B4=D6=96= =D7=99=D7=AA should come before (i.e. on the right) of the word > =D7=91=D6=BC=D6=B8=D7=A8=D6=B8=D6=A3=D7=90. So > > while the footnote command is correctly shown as LTR the Hebrew text ha= s > been > > changed. I don't think is is the expected. See the updated image > > ( > http://emacs.stackexchange.com/questions/19696/handling-left-to-right-ins= ide-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 > =D7=91=D6=BC=D6=B0=D7=A8=D6=B5=D7=90=D7=A9=D7=81=D6=B4=D6=96=D7=99=D7=AA = 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. --001a11470ed235f96a0529edb40d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jan 22, = 2016 at 2:01 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Filipe Moreira <famoreira@gmail.com>
> Date: Fri, 22 Jan 2016 11:54:45 +0000
> Cc: 22429@debbugs.gnu.org=
>
>=C2=A0 =C2=A0 =C2=A0Emacs being Emacs, you can programmatically change = the bidirectional
>=C2=A0 =C2=A0 =C2=A0class of every character, but that change has globa= l effect: it will
>=C2=A0 =C2=A0 =C2=A0affect the directionality of that character everywh= ere in the Emacs
>=C2=A0 =C2=A0 =C2=A0session. So this is not recommended.
>
> Also this is not recommended, I would be willing to have the bidi clas= s
> property of some characters set to left-to-right, like the example of = the slash
> character.

Can you tell why?=C2=A0 There are ways to produce the display you ex= pect
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.=C2=A0 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.=C2=A0 Again, I very much recommend = not to
do that.

>=C2=A0 =C2=A0 =C2=A0\begin{hebrew}
>=C2=A0 =C2=A0 =C2=A0\pstart
>
>=C2=A0 =C2=A0 =C2=A0=D7=91=D6=BC=D6=B0=D7=A8=D6=B5=D7=90=D7=A9=D7=81=D6= =B4=D6=96=D7=99=D7=AA=E2=80=AA\footnoteA{This is a Hebrew related footnote}= =E2=80=AC =D7=91=D6=BC=D6=B8=D7=A8=D6=B8=D6=A3=D7=90 =D7=90=D6=B1=D7=9C=D6= =B9=D7=94=D6=B4=D6=91=D7=99=D7=9D =D7=90=D6=B5=D6=A5=D7=AA =D7=94=D6=B7=D7= =A9=D6=BC=D7=81=D6=B8=D7=9E=D6=B7=D6=96=D7=99=D6=B4=D7=9D =D7=95=D6=B0=D7= =90=D6=B5=D6=A5=D7=AA
>=C2=A0 =C2=A0 =C2=A0=D7=94=D6=B8=D7=90=D6=B8=D6=BD=D7=A8=D6=B6=D7=A5=D7= =83
>
>=C2=A0 =C2=A0 =C2=A0\pend
>=C2=A0 =C2=A0 =C2=A0\end{hebrew}
>
>
> In this example the direction of the surrounding Hebrew text has been = changed.
> The word =D7=91=D6=BC=D6=B0=D7=A8=D6=B5=D7=90=D7=A9=D7=81=D6=B4=D6=96= =D7=99=D7=AA should come before (i.e. on the right) of the word =D7=91=D6= =BC=D6=B8=D7=A8=D6=B8=D6=A3=D7=90. So
> while the footnote command is correctly shown as LTR the Hebrew text h= as been
> changed. I don't think is is the expected. See the updated image > (http://emacs.stackexchange.com/questions/1969= 6/handling-left-to-right-inside-right-to-left-paragraphs-using-emacs-and-au= ctex)
> that shows TextEdit correct handling of this.

What version of Emacs do you have?=C2=A0 The above renders correctly= for
me, both in Emacs 24.5 and in the development version.=C2=A0 The word
=D7=91=D6=BC=D6=B0=D7=A8=D6=B5=D7=90=D7=A9=D7=81=D6=B4=D6=96=D7=99=D7=AA is= shown to the right of the footnote, and all the rest is
shown to the left of it.=C2=A0 Maybe you have an older Emacs which somehow<= br> has a bug?

I have just tested wrapping = the footnote command within LTM (on both ends) in a clean Emacs 24.5.1 (sta= rted with -Q) and it worked! This wasn't working on my normal environme= nt so I will need to investigate why that is.=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
> 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 featur= e?

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 learne= d a lot from you and others regarding this. Thank you for making Emacs so g= reat.=C2=A0

--001a11470ed235f96a0529edb40d-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 23 21:35:52 2016 Received: (at control) by debbugs.gnu.org; 24 Jan 2016 02:35:52 +0000 Received: from localhost ([127.0.0.1]:60921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNAWt-0008Mp-SQ for submit@debbugs.gnu.org; Sat, 23 Jan 2016 21:35:52 -0500 Received: from eggs.gnu.org ([208.118.235.92]:47700) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aNAWs-0008Mb-Qz for control@debbugs.gnu.org; Sat, 23 Jan 2016 21:35:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNAWn-0006fT-9K for control@debbugs.gnu.org; Sat, 23 Jan 2016 21:35:45 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33771) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNAWn-0006fO-5v for control@debbugs.gnu.org; Sat, 23 Jan 2016 21:35:45 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1aNAWm-0007B5-TI for control@debbugs.gnu.org; Sat, 23 Jan 2016 21:35:44 -0500 Subject: control message for bug 22429 To: X-Mailer: mail (GNU Mailutils 2.99.98) Message-Id: From: Glenn Morris Date: Sat, 23 Jan 2016 21:35:44 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) tag 22429 notabug close 22429