From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: port x-symbol to GNU emacs 24. Date: Wed, 19 Aug 2015 14:33:43 +0200 Message-ID: <87oai34fvc.fsf@gnu.org> References: <87oaia6ict.fsf@mat.ucm.es> <837foxor1t.fsf@gnu.org> <878u9d7vdg.fsf@mat.ucm.es> <87pp2pq2ht.fsf@gnu.org> <87wpwx68cn.fsf@mat.ucm.es> <87mvxqxtif.fsf@gnu.org> <838u9alzly.fsf@gnu.org> <874mjyaqm8.fsf@fencepost.gnu.org> <87d1yl2dq9.fsf@gnu.org> <87r3mz91h2.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1440006264 16735 80.91.229.3 (19 Aug 2015 17:44:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Aug 2015 17:44:24 +0000 (UTC) Cc: Eli Zaretskii , David Kastrup , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 19 19:44:10 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZS7P7-0001Jj-Rj for ged-emacs-devel@m.gmane.org; Wed, 19 Aug 2015 19:44:02 +0200 Original-Received: from localhost ([::1]:46197 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZS2ZZ-00025T-7T for ged-emacs-devel@m.gmane.org; Wed, 19 Aug 2015 08:34:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38801) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZS2Yw-0001y6-Ou for emacs-devel@gnu.org; Wed, 19 Aug 2015 08:33:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZS2Yt-0002GP-ET for emacs-devel@gnu.org; Wed, 19 Aug 2015 08:33:50 -0400 Original-Received: from out3-smtp.messagingengine.com ([66.111.4.27]:36896) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZS2Yt-0002G9-8N for emacs-devel@gnu.org; Wed, 19 Aug 2015 08:33:47 -0400 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id DEC6A203F4 for ; Wed, 19 Aug 2015 08:33:46 -0400 (EDT) Original-Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 19 Aug 2015 08:33:46 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=UJpnQRFrWOQQFF+ Y0bPj0xhRw/o=; b=dknbm50850TzpjrluWsZk4BjLKp8wiaAG1tynQIXv9xAIL2 pv4AodWER2JoIlJjQkcK/Q+dguDzvmEDE6amUp62761kjQA1Spd6hqRVctvKqZmM Fqo+AdaA4uJHsJHuV4zz37f9mV3KRmcd7jKNClMcufMmq/wDaTdsmPO6ypvg= X-Sasl-enc: +wDrTvHtKNkbA5etM0Fq5SLemgVgognrKMZDwuHAXDfg 1439987626 Original-Received: from thinkpad-t440p (unknown [2.160.238.117]) by mail.messagingengine.com (Postfix) with ESMTPA id 7E768680231; Wed, 19 Aug 2015 08:33:45 -0400 (EDT) Mail-Followup-To: Stefan Monnier , David Kastrup , Eli Zaretskii , emacs-devel@gnu.org In-Reply-To: <87r3mz91h2.fsf@gnu.org> (Tassilo Horn's message of "Wed, 19 Aug 2015 09:33:29 +0200") User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 66.111.4.27 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:188960 Archived-At: Tassilo Horn writes: > Well, it's actually not as simple as I've thought before. It does in > fact handle some non-symbol things but it depends on the syntax before > and after the matched thing. > > With `prettify-symbols-alist' set to just (("\\alpha" . ?=CE=B1) ("\\beta" > . ?=CE=B2)), that's what I get when using AUCTeX (yes means that the greek > letter is displayed, no means the literal tex macro is displayed): > > \alpha %% yes > \[\alpha\] %% yes > $\alpha$ %% no > $ \alpha$ %% no > $ \alpha $ %% no > \(\alpha\) %% no > \( \alpha\) %% yes > \( \alpha \) %% yes > \(\alpha\cdot\beta\) %% alpha: no, beta: yes > \( \alpha\cdot\beta\) %% alpha: yes, beta: yes > > With Emacs' built-in (la)tex-mode, all occurrences are displayed with > the greek letters, so it seems to be more or less an AUCTeX problem. > > The only syntax differences I could find between the standard > (la)tex-mode and AUCTeX's modes is that in the former, ?\\ has charquote > syntax whereas it has escape syntax in the latter. And $ has "math > syntax, matches $" in the former and only math syntax in the latter. > However, even after > > (modify-syntax-entry ?\\ "/") > (modify-syntax-entry ?$ "$$") > > in the AUCTeX buffer and disabling and re-enabling > `prettify-symbols-mode', the results stay the same as above... Ok, it seems like these char syntax differences are not the culprit. At least the control flow thru `prettify-symbols--compose-symbol' is the same no matter if the built-in (la)tex-modes or the AUCTeX ones are used. For all of the \alpha / \beta occurrences above, (compose-region start end (cdr (assoc match alist))) is called. So I defined this command to figure out what's going on: (defun th/pretty-compose-region (start end) (interactive "r") (let* ((str (buffer-substring-no-properties start end)) (char (cdr (assoc str prettify-symbols-alist)))) (if (null char) (message "Won't compose when there's no character defined.") (message "Composing %qs to be displayed as %qs." str (string char)) (compose-region start end char)))) Now in my example test.tex file with `prettify-symbols-mode' enabled, when I mark some \alpha still displayed literally in any of the samples above and invoke my command, it messages Composing =E2=80=98\alpha=E2=80=99 to be displayed as =E2=80=98=CE=B1=E2= =80=99. but the \alpha stays displayed as \alpha, and no composition text property is added. Why? To make things more mysterious: when I disable `prettify-symbols-mode', I can call my `th/pretty-compose-region' on any \alpha and \beta occurrence, and then it'll be displayed as greek letter! I thought that might be caused by `composition' being added to `font-lock-extra-managed-props' by `prettify-symbols-mode', but the behavior stays the same even when I remove it there. So all in all: `prettify-symbols-mode' calls `compose-region' for all occurrences of the tex macros I've defined in `prettify-symbols-alist' with the corresponding unicode character. The call always has the desired effect in the built-in (la)tex-mode and in fundamental-mode [1], but with AUCTeX modes the invocation of `compose-region' on some occurrences has no effect when `prettify-symbols-mode' is enabled. When I disable it, I can manually compose the occurrences that didn't work. When I set AUCTeX `TeX-install-font-lock' to `tex-font-setup' so that the standard font-lock rules are used instead of AUCTeX's font-latex.el, two more \alpha occurrences are displayed as the greek letter (the ones with YES!), but still not all. \alpha %% yes \[\alpha\] %% yes $\alpha$ %% no $ \alpha$ %% no $ \alpha $ %% no \(\alpha\) %% YES! \( \alpha\) %% yes \( \alpha \) %% yes \(\alpha\cdot\beta\) %% alpha: YES!, beta: yes \( \alpha\cdot\beta\) %% alpha: yes, beta: yes Well, the actual `font-lock-keywords' are not identical in the case of the built-in (la)tex-mode and AUCTeX with `tex-font-setup' and it's not really possible to figure out the differences given all those regexp-opt-ed regexps. Maybe in the AUCTeX version there's some additional font-lock that would interfer with the composition, i.e., immediately undos what the `compose-region' calls did? Or what else might be the culprit of rendering `compose-region' non-functional? Bye, Tassilo [1] With the exception of $\alpha$ because there the trailing $ is part of the word.