Re: port x-symbol to GNU emacs 24.

[Tassilo Horn]

Tassilo Horn <address@hidden> 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" . ?α) ("\\beta"
> . ?β)), 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 ‘\alpha’ to be displayed as ‘α’.

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.