port x-symbol to GNU emacs 24.

port x-symbol to GNU emacs 24.

[Uwe Brauer]

Hello

The latest version of the x-symbol package is from 2003, but it still
provides useful features, especially for editing LaTeX files, I have not
seen in any other packages. Originally developed only for Xemacs, the
latest versions contain a GNU emacs specific file, x-symbol-emacs.el.
Moreover I do remember that it run under GNU emacs 21, although I forgot
the details.


Be it as it may, I tried to run x-symbol now under GNU emacs 24.4:
Byte compilation did not cause any problems but when I tried to load
the package I run into a series of problems, which I could only solve
partially.

   - the function make-local-hook is not defined, I just copied its (xemacs)
     definition into x-symbol-emacs.el (I attach its definition  at the end
     of the message and it seems to work.

 - x-symbol-set-face-font: Wrong type argument: listp,
   "-adobe-helvetica-medium-r-normal-*-14-*-*-*-*-*-iso8859-1"
  although I had debug-on-error t, I did not obtain more details about
   the error.
  
   The definition of x-symbol-set-face-font is as follows 

(defun x-symbol-set-face-font (face font charsets default)
  (let ((fontset (concat "fontset-" (symbol-name face))))
    (unless (query-fontset fontset)
      ;; We assume that the first time around we're using latin-8859-1
      (new-fontset fontset
		   (x-complement-fontset-spec (make-vector 14 "*")
					      (list (cons 'ascii font)))))
    (dolist (charset charsets)
      (when charset (set-fontset-font fontset charset font)))
    (set-face-font face fontset)))

But it seems GNU emacs 24.4 now treats fonts differently. Anybody has
a suggestion how to modify this function so that it is compatible with
24.4??

The next two errors are more serious.


 - eval-buffer: Symbol's function definition is void: remove-specifier
   [2 times] `Type C-x 1 to delete the help window, C-M-v to scroll help.

 - eval-buffer: Symbol's function definition is void: map-extents
   [2 times] `Type C-x 1 to delete the help window, C-M-v to scroll help.

Now both functions are built-in functions defined in C and I don't
know how to continue. Any changes of defining an alias for a similar function from
GNU emacs???

I really wounder how x-symbol could have worked with GNU emacs 21.


`map-extents' is a built-in function
  -- loaded from "/home/oub/xemacs-mercury/xemacs/src/extents.c"
(map-extents FUNCTION &optional OBJECT FROM TO MAPARG FLAGS PROPERTY VALUE)

`remove-specifier' is a built-in function
  -- loaded from "/home/oub/xemacs-mercury/xemacs/src/specifier.c"
(remove-specifier SPECIFIER &optional LOCALE TAG-SET EXACT-P)


Thanks and regards 


Uwe Brauer 

Definition fo make-local-hook


(defun make-local-hook (hook)
The return value is HOOK.

You never need to call this function now that `add-hook' does it for you
if its LOCAL argument is non-nil.

When a hook is local, its local and global values
work in concert: running the hook actually runs all the hook
functions listed in *either* the local value *or* the global value
of the hook variable.

This function works by making `t' a member of the buffer-local value,
which acts as a flag to run the hook functions in the default value as
well.  This works for all normal hooks, but does not work for most
non-normal hooks yet.  We will be changing the callers of non-normal
hooks so that they can handle localness; this has to be done one by
one.

This function does nothing if HOOK is already local in the current
buffer.

Do not use `make-local-variable' to make a hook variable buffer-local."
  (if (local-variable-p hook (current-buffer)) ; XEmacs
      nil
    (or (boundp hook) (set hook nil))
    (make-local-variable hook)
    (set hook (list t)))
  hook)

Re: port x-symbol to GNU emacs 24.

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Fri, 14 Aug 2015 14:43:30 +0000
> Cc: XEmacs Beta Discussion <xemacs-beta@xemacs.org>
> 
> The latest version of the x-symbol package is from 2003, but it still
> provides useful features, especially for editing LaTeX files, I have not
> seen in any other packages.

What features are those you don't see elsewhere in Emacs?  (I'm
specifically asking about GNU Emacs, not XEmacs.)

>  - eval-buffer: Symbol's function definition is void: remove-specifier
>    [2 times] `Type C-x 1 to delete the help window, C-M-v to scroll help.
> 
>  - eval-buffer: Symbol's function definition is void: map-extents
>    [2 times] `Type C-x 1 to delete the help window, C-M-v to scroll help.
> 
> Now both functions are built-in functions defined in C and I don't
> know how to continue. Any changes of defining an alias for a similar function from
> GNU emacs???

GNU Emacs doesn't have extents and specifiers.

My suggestion is to use the equivalent features provided by GNU
Emacs.  If you tell which features you miss, people here could advise
you about the replacements, either in core or in add-on packages.

Re: port x-symbol to GNU emacs 24.

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 226 bytes --]


   > What features are those you don't see elsewhere in Emacs?  (I'm
   > specifically asking about GNU Emacs, not XEmacs.)

I think a picture says more than 1000 words, here is a screenshot. (I
hope it will not be blocked).

[-- Attachment #2: x-symbol-xemacs.png --]
[-- Type: image/png, Size: 56259 bytes --]

[-- Attachment #3: Type: text/plain, Size: 644 bytes --]



   > GNU Emacs doesn't have extents and specifiers.

But what would provide a similar feature? I hoped somebody on the list
could tell me.

   > My suggestion is to use the equivalent features provided by GNU
   > Emacs.  If you tell which features you miss, people here could advise
   > you about the replacements, either in core or in add-on packages.

Ok, so I have to dig more into the code or hope that somebody in
xemacs-beta could point me out what is the GNU emacs equivalent to those
functions. I still wonder how x-symbol could have worked under GNU
emacs 21, given that extents and specifiers did not exist neither for
emacs 21.

Re: port x-symbol to GNU emacs 24.

[David Kastrup]

Uwe Brauer <oub@mat.ucm.es> writes:

>    > What features are those you don't see elsewhere in Emacs?  (I'm
>    > specifically asking about GNU Emacs, not XEmacs.)
>
> I think a picture says more than 1000 words, here is a screenshot. (I
> hope it will not be blocked).

Actually, it doesn't.  This screenshot is not dissimilar what you'll get
from using AUCTeX, preview-latex and TeX-fold-mode.

The main "not elsewhere" category I see are XEmacs' extensive input
modes (grid which is sort of a buffer-based menu, keyboard input methods
quite better sorted and convenient than what Quail offers and with
better feedback).  Its buffer reencoding is a rather mixed blessing, but
it works with more than just TeX modes.

-- 
David Kastrup

Re: port x-symbol to GNU emacs 24.

[Uwe Brauer]

>>>>> "David" == David Kastrup <dak@gnu.org> writes:

   > Uwe Brauer <oub@mat.ucm.es> writes:
   >> > What features are those you don't see elsewhere in Emacs?  (I'm
   >> > specifically asking about GNU Emacs, not XEmacs.)
   >> 
   >> I think a picture says more than 1000 words, here is a screenshot. (I
   >> hope it will not be blocked).

   > Actually, it doesn't.  This screenshot is not dissimilar what you'll get
   > from using AUCTeX, preview-latex and TeX-fold-mode.

Well, preview-latex is actually better concerning math formula. It is
equivalent for the included graphics as far GNU emacs is concerned but
preview-latex is inferior concerning the graphics in Xemacs, don't know
why.


However the disadvantage of approach used by preview-latex is that you
have run latex on the document/buffer, while for x-symbol you don't. If
you modify a formula using preview-latex you have at least rerun the
environment, while again in x-symbol you don't have to. Of course
x-symbol is not very helpful if the formula contains fractions or
matrices etc. In short both packages serve different purposes.

   > The main "not elsewhere" category I see are XEmacs' extensive input
   > modes (grid which is sort of a buffer-based menu, keyboard input methods
   > quite better sorted and convenient than what Quail offers and with
   > better feedback).

But this feature I use rather seldom, since I am very much used to cdlatex.

   > Its buffer reencoding is a rather mixed blessing, but
   > it works with more than just TeX modes.

Well sometimes I actually hate the reencoding, but on the other hand I
usually receive a lot of latex documents in spanish with a mixture of
coding, utf8 latin-1 or TeX constructs such as 'a \'a {\' a} etc etc.
X-symbol deals with them in rather coherent way.

Re: port x-symbol to GNU emacs 24.

[Tassilo Horn]

Uwe Brauer <oub@mat.ucm.es> writes:

>    > What features are those you don't see elsewhere in Emacs?  (I'm
>    > specifically asking about GNU Emacs, not XEmacs.)
>
> I think a picture says more than 1000 words, here is a screenshot. (I
> hope it will not be blocked).

Well, I guess you could use Emacs' built-in `prettify-symbols-mode' in
order to display TeX macros using some unicode characters (or
preview-latex of course).

>    > GNU Emacs doesn't have extents and specifiers.
>
> But what would provide a similar feature?  I hoped somebody on the
> list could tell me.

Emacs' overlays serve the same purpose as XEmacs' extents, and I think
there is or has been some 3rd-party package providing a unified API for
overlays and extents.

But I have no clue what specifiers are...

>    > My suggestion is to use the equivalent features provided by GNU
>    > Emacs.  If you tell which features you miss, people here could
>    > advise you about the replacements, either in core or in add-on
>    > packages.
>
> Ok, so I have to dig more into the code or hope that somebody in
> xemacs-beta could point me out what is the GNU emacs equivalent to
> those functions. I still wonder how x-symbol could have worked under
> GNU emacs 21, given that extents and specifiers did not exist neither
> for emacs 21.

I just downloaded x-symbol 4.5.1, and in its x-symbol-emacs.el there are
several aliases defined for things that error for you.  For example,
`map-extents' is made an alias for `cl-map-overlays'.  So you have to
load that first.

Well, eventually when loading x-symbol.el I also got an
wrong-number-of-arguments error but that's probably an incompatibility
which is easy to fix.

Bye,
Tassilo

Re: port x-symbol to GNU emacs 24.

[Stefan Monnier]

> Emacs' overlays serve the same purpose as XEmacs' extents, and I think
> there is or has been some 3rd-party package providing a unified API for
> overlays and extents.

Indeed there is: it's overlay.el (which adds Emacs's API to XEmacs and
hence doesn't help here).

> But I have no clue what specifiers are...

Presumably this code was not run in Emacs-21, so you'll have to figure
out why (maybe some `fboundp' which returned t in Emacs-21 but doesn't
any more?).

> I just downloaded x-symbol 4.5.1, and in its x-symbol-emacs.el there are
> several aliases defined for things that error for you.  For example,
> `map-extents' is made an alias for `cl-map-overlays'.

Was renamed to cl--map-overlays back in the cl-lib overhaul.

David wrote:
> The main "not elsewhere" category I see are XEmacs' extensive input
> modes (grid which is sort of a buffer-based menu, keyboard input methods
> quite better sorted and convenient than what Quail offers and with
> better feedback).  Its buffer reencoding is a rather mixed blessing, but
> it works with more than just TeX modes.

I never found the buffer-reencoding very convincing/convenient and even
less so nowadays, but indeed I sometimes miss the various input methods
of X-Symbol.  Ideally, those should be extracted into their own package.


        Stefan

Re: port x-symbol to GNU emacs 24.

[Uwe Brauer]

>>>>> "Tassilo" == Tassilo Horn <tsdh@gnu.org> writes:

   > Uwe Brauer <oub@mat.ucm.es> writes:
   >> > What features are those you don't see elsewhere in Emacs?  (I'm
   >> > specifically asking about GNU Emacs, not XEmacs.)
   >> 
   >> I think a picture says more than 1000 words, here is a screenshot. (I
   >> hope it will not be blocked).

   > Well, I guess you could use Emacs' built-in `prettify-symbols-mode' in
   > order to display TeX macros using some unicode characters (or
   > preview-latex of course).
I just switched `prettify-symbols-mode' on in a latex buffer but nothing
happens to \int or \alpha


   >> > GNU Emacs doesn't have extents and specifiers.
   >> 
   >> But what would provide a similar feature?  I hoped somebody on the
   >> list could tell me.

   > Emacs' overlays serve the same purpose as XEmacs' extents, and I think
   > there is or has been some 3rd-party package providing a unified API for
   > overlays and extents.

   > But I have no clue what specifiers are...

   >> > My suggestion is to use the equivalent features provided by GNU
   >> > Emacs.  If you tell which features you miss, people here could
   >> > advise you about the replacements, either in core or in add-on
   >> > packages.
   >> 
   >> Ok, so I have to dig more into the code or hope that somebody in
   >> xemacs-beta could point me out what is the GNU emacs equivalent to
   >> those functions. I still wonder how x-symbol could have worked under
   >> GNU emacs 21, given that extents and specifiers did not exist neither
   >> for emacs 21.

   > I just downloaded x-symbol 4.5.1, and in its x-symbol-emacs.el there are
   > several aliases defined for things that error for you.  For example,
   > `map-extents' is made an alias for `cl-map-overlays'.  So you have to
   > load that first.

I thought that as well, I had a (require 'x-symbol-emacs) in my init
file, but it seemed not to have worked. I will give it again a try.
   > Well, eventually when loading x-symbol.el I also got an
   > wrong-number-of-arguments error but that's probably an incompatibility
   > which is easy to fix.

Do you mean the

 - x-symbol-set-face-font: Wrong type argument: listp,
   "-adobe-helvetica-medium-r-normal-*-14-*-*-*-*-*-iso8859-1"

error? I hoped this is a wrong-number-of-arguments error but I don't
know how to fix it.

I will try again to load x-symbol-emacs manually and then will see.
Thanks

Uwe 

Re: port x-symbol to GNU emacs 24.

[Tassilo Horn]

Uwe Brauer <oub@mat.ucm.es> writes:

>    > Well, I guess you could use Emacs' built-in
>    > `prettify-symbols-mode' in order to display TeX macros using some
>    > unicode characters (or preview-latex of course).
> I just switched `prettify-symbols-mode' on in a latex buffer but
> nothing happens to \int or \alpha

You have to define the symbols in `prettify-symbols-alist', e.g., define
some `ub/prettify-symbols-alist-latex' as

  (("\\\\alpha" . ?𝛼)
   ("\\\\beta"  . ?𝛽)
   ...)

and then do

  (setq prettify-symbols-alist ub/prettify-symbols-alist-latex)

in TeX-mode-hook.

Bye,
Tassilo

Re: port x-symbol to GNU emacs 24.

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Mon, 17 Aug 2015 09:29:28 +0200
> 
> Uwe Brauer <oub@mat.ucm.es> writes:
> 
> >    > Well, I guess you could use Emacs' built-in
> >    > `prettify-symbols-mode' in order to display TeX macros using some
> >    > unicode characters (or preview-latex of course).
> > I just switched `prettify-symbols-mode' on in a latex buffer but
> > nothing happens to \int or \alpha
> 
> You have to define the symbols in `prettify-symbols-alist'

Indeed, and I think it should be a good idea to populate that alist
with some non-trivial content to begin with.  Any takers?

Re: port x-symbol to GNU emacs 24.

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tassilo Horn <tsdh@gnu.org>
>> Date: Mon, 17 Aug 2015 09:29:28 +0200
>> 
>> Uwe Brauer <oub@mat.ucm.es> writes:
>> 
>> >    > Well, I guess you could use Emacs' built-in
>> >    > `prettify-symbols-mode' in order to display TeX macros using some
>> >    > unicode characters (or preview-latex of course).
>> > I just switched `prettify-symbols-mode' on in a latex buffer but
>> > nothing happens to \int or \alpha
>> 
>> You have to define the symbols in `prettify-symbols-alist'
>
> Indeed, and I think it should be a good idea to populate that alist
> with some non-trivial content to begin with.  Any takers?

Siphon off what can be taken from the TeX input method of Quail?  That
should provide a healthy dose of Unicode/TeX relations in Emacs-readable
form.

-- 
David Kastrup

Re: port x-symbol to GNU emacs 24.

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Tassilo Horn <tsdh@gnu.org>,  emacs-devel@gnu.org
> Date: Mon, 17 Aug 2015 17:20:31 +0200
> 
> >> > I just switched `prettify-symbols-mode' on in a latex buffer but
> >> > nothing happens to \int or \alpha
> >> 
> >> You have to define the symbols in `prettify-symbols-alist'
> >
> > Indeed, and I think it should be a good idea to populate that alist
> > with some non-trivial content to begin with.  Any takers?
> 
> Siphon off what can be taken from the TeX input method of Quail?

That's a good starting point, yes.

Re: port x-symbol to GNU emacs 24.

[Tassilo Horn]

David Kastrup <dak@gnu.org> writes:

>>> >    > Well, I guess you could use Emacs' built-in
>>> >    > `prettify-symbols-mode' in order to display TeX macros using some
>>> >    > unicode characters (or preview-latex of course).
>>> > I just switched `prettify-symbols-mode' on in a latex buffer but
>>> > nothing happens to \int or \alpha
>>> 
>>> You have to define the symbols in `prettify-symbols-alist'
>>
>> Indeed, and I think it should be a good idea to populate that alist
>> with some non-trivial content to begin with.  Any takers?
>
> Siphon off what can be taken from the TeX input method of Quail?  That
> should provide a healthy dose of Unicode/TeX relations in
> Emacs-readable form.

I just started to define a `prettify-symbols-alist--TeX' by checking
what Quail provides.  However, there is a problem in that (la)tex-mode
and their AUCTeX counterparts don't give \ symbol syntax.  Therefore, an
entry like ("\\alpha" . ?α) will never match.  And omitting the
backslash isn't possible because then we'd have many false positives for
entries like ("in" . ?∈).

Any ideas how to cope with that situation?  Simply giving \ symbol
syntax will break at least AUCTeX (and isn't correct anyhow).

Bye,
Tassilo

Re: port x-symbol to GNU emacs 24.

[Stefan Monnier]

> I just started to define a `prettify-symbols-alist--TeX' by checking
> what Quail provides.

Hmm... the name sounds suspect.  It should have "tex" in the prefix, not
in the suffix.

> However, there is a problem in that (la)tex-mode and their AUCTeX
> counterparts don't give \ symbol syntax.  Therefore, an entry like
> ("\\alpha" . ?α) will never match.  And omitting the backslash isn't
> possible because then we'd have many false positives for entries like
> ("in" . ?∈).

prettify-symbols-alist does currently handle non-symbol chars.
Whether it handles this specific case, I'm not completely sure (tho I'm
pretty sure it'll mishandle "\alpha2", in any case).  But we should make
prettify-symbols-alist handle the needs of TeX, so feel free to suggest
extensions to prettify-symbols-alist if that's needed.


        Stefan

Re: port x-symbol to GNU emacs 24.

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I just started to define a `prettify-symbols-alist--TeX' by checking
>> what Quail provides.
>
> Hmm... the name sounds suspect.  It should have "tex" in the prefix,
> not in the suffix.

No problem, I can change that.  I guess it should then go into
tex-mode.el?

>> However, there is a problem in that (la)tex-mode and their AUCTeX
>> counterparts don't give \ symbol syntax.  Therefore, an entry like
>> ("\\alpha" . ?α) will never match.  And omitting the backslash isn't
>> possible because then we'd have many false positives for entries like
>> ("in" . ?∈).
>
> prettify-symbols-alist does currently handle non-symbol chars.
> Whether it handles this specific case, I'm not completely sure (tho
> I'm pretty sure it'll mishandle "\alpha2", in any case).  But we
> should make prettify-symbols-alist handle the needs of TeX, so feel
> free to suggest extensions to prettify-symbols-alist if that's needed.

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...

Bye,
Tassilo

Re: port x-symbol to GNU emacs 24.

[Tassilo Horn]

Tassilo Horn <tsdh@gnu.org> 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.

Re: port x-symbol to GNU emacs 24.

[Tassilo Horn]

Hi again,

I finally found out what's the culprit.  AUCTeX' font-latex uses
syntactic font-lock for the tex math construct $ ... $, i.e., for
fontification purposes it gives $ string-syntax and then uses a custom
`font-lock-syntactic-face-function' to assign either string, comment, or
math face.

So basically, the value of

(defvar font-latex-syntax-alist
  ;; Use word syntax for @ because we use \> for matching macros and
  ;; we don't want \foo@bar to be found if we search for \foo.
  '((?\( . ".") (?\) . ".") (?$ . "\"") (?@ . "w"))
  "List of specifiers for the syntax alist of `font-lock-defaults'.")

is used as SYNTAX-ALIST in `font-lock-defaults'.

I have no clue why parens get punctuation syntax, though.  I checked the
VC history, and back in the old times there was a comment

  ;; Parentheses () disabled because they should not delimit fontification
  ;; in LaTeX text.

whatever that means.  But that's the reason why \(\alpha\) is not
prettified but \( \alpha\) is: there mustn't be a character with
punctuation syntax before the symbol to be prettified.  (I think that's
probably sensible in C-like languages but not in TeX or Lisp.)

Is there a way that I can use a custom SYNTAX-ALIST only for syntactic
but not search-based fontification?

Bye,
Tassilo

Re: port x-symbol to GNU emacs 24.

[Stefan Monnier]

>> prettify-symbols-alist does currently handle non-symbol chars.
>> Whether it handles this specific case, I'm not completely sure (tho
>> I'm pretty sure it'll mishandle "\alpha2", in any case).  But we
>> should make prettify-symbols-alist handle the needs of TeX, so feel
>> free to suggest extensions to prettify-symbols-alist if that's needed.
> 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.

Indeed.  And if we want to handle \alpha2 correctly, I think we'll need
to extend prettify-symbols-mode somehow to let latex-mode teach
prettify-symbols-mode how to properly recognize whether a given \alpha
should be composed or not.

In some earlier prettify-symbols code (the one used in haskell-mode),
I extended the alist so that each element can have a predicate checking
whether this occurrence should be composed (this is used in Haskell for
the "." which can either be the function-composition infix operator, or
the usual separator used within identifiers as in List.map).

We should probably extend prettify-symbols-alist similarly,
but in the case of TeX, I think setting a predicate for every entry is
inconvenient, and we should instead set a "global" predicate which is
applied to every entry (and is used instead of the default code which
checks the syntax-class of surrounding characters).


        Stefan

Re: port x-symbol to GNU emacs 24.

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> prettify-symbols-alist does currently handle non-symbol chars.
>>> Whether it handles this specific case, I'm not completely sure (tho
>>> I'm pretty sure it'll mishandle "\alpha2", in any case).  But we
>>> should make prettify-symbols-alist handle the needs of TeX, so feel
>>> free to suggest extensions to prettify-symbols-alist if that's needed.
>> 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.
>
> Indeed.  And if we want to handle \alpha2 correctly, I think we'll
> need to extend prettify-symbols-mode somehow to let latex-mode teach
> prettify-symbols-mode how to properly recognize whether a given \alpha
> should be composed or not.

It doesn't compose \alpha2 so that's already handled correctly, no?  But
at the same time, it also doesn't compose .\alpha where . could be any
character with punctuation syntax.  And at least that's not right for
tex.

> In some earlier prettify-symbols code (the one used in haskell-mode),
> I extended the alist so that each element can have a predicate
> checking whether this occurrence should be composed (this is used in
> Haskell for the "." which can either be the function-composition infix
> operator, or the usual separator used within identifiers as in
> List.map).
>
> We should probably extend prettify-symbols-alist similarly, but in the
> case of TeX, I think setting a predicate for every entry is
> inconvenient, and we should instead set a "global" predicate which is
> applied to every entry (and is used instead of the default code which
> checks the syntax-class of surrounding characters).

Yes, that sounds like a good solution for making \alpha work when a
punctuation character preceedes it.

Bye,
Tassilo

Re: port x-symbol to GNU emacs 24.

[Stefan Monnier]

> It doesn't compose \alpha2 so that's already handled correctly, no?

No, IMHO, it should appear as α2.


        Stefan

Re: port x-symbol to GNU emacs 24.

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> It doesn't compose \alpha2 so that's already handled correctly, no?
>
> No, IMHO, it should appear as α2.

In theory, yes.  Unless the document uses expl3 or the user plays with
catcodes and then this could be one valid single macro.  So I'd rather
rely on having some non-word character in between.

Bye,
Tassilo

Re: port x-symbol to GNU emacs 24.

[David Kastrup]

Tassilo Horn <tsdh@gnu.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> It doesn't compose \alpha2 so that's already handled correctly, no?
>>
>> No, IMHO, it should appear as α2.
>
> In theory, yes.  Unless the document uses expl3 or the user plays with
> catcodes and then this could be one valid single macro.  So I'd rather
> rely on having some non-word character in between.

There is quite a lot of math around that does not bother with spurious
spaces.

-- 
David Kastrup

Re: port x-symbol to GNU emacs 24.

[Tassilo Horn]

David Kastrup <dak@gnu.org> writes:

>>>> It doesn't compose \alpha2 so that's already handled correctly, no?
>>>
>>> No, IMHO, it should appear as α2.
>>
>> In theory, yes.  Unless the document uses expl3 or the user plays with
>> catcodes and then this could be one valid single macro.  So I'd rather
>> rely on having some non-word character in between.
>
> There is quite a lot of math around that does not bother with spurious
> spaces.

Yes, right.  So now \alpha2 is indeed displayed as α2 with
prettify-symbols-mode.

Do you have any idea how to get $\alpha$ working also with AUCTeX's
font-latex.el where $ are treated as string quotes?

Bye,
Tassilo

Re: port x-symbol to GNU emacs 24.

[David Kastrup]

Tassilo Horn <tsdh@gnu.org> writes:

> David Kastrup <dak@gnu.org> writes:
>
>>>>> It doesn't compose \alpha2 so that's already handled correctly, no?
>>>>
>>>> No, IMHO, it should appear as α2.
>>>
>>> In theory, yes.  Unless the document uses expl3 or the user plays with
>>> catcodes and then this could be one valid single macro.  So I'd rather
>>> rely on having some non-word character in between.
>>
>> There is quite a lot of math around that does not bother with spurious
>> spaces.
>
> Yes, right.  So now \alpha2 is indeed displayed as α2 with
> prettify-symbols-mode.
>
> Do you have any idea how to get $\alpha$ working also with AUCTeX's
> font-latex.el where $ are treated as string quotes?

No, font-latex and font lock in general is out of my depth.

-- 
David Kastrup

Re: port x-symbol to GNU emacs 24.

[Tassilo Horn]

David Kastrup <dak@gnu.org> writes:

>>> There is quite a lot of math around that does not bother with
>>> spurious spaces.
>>
>> Yes, right.  So now \alpha2 is indeed displayed as α2 with
>> prettify-symbols-mode.
>>
>> Do you have any idea how to get $\alpha$ working also with AUCTeX's
>> font-latex.el where $ are treated as string quotes?
>
> No, font-latex and font lock in general is out of my depth.

Ok, no problem.

Bye,
Tassilo

Generalizing prettify-symbols-mode (was: port x-symbol to GNU emacs 24.)

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Indeed.  And if we want to handle \alpha2 correctly, I think we'll
> need to extend prettify-symbols-mode somehow to let latex-mode teach
> prettify-symbols-mode how to properly recognize whether a given \alpha
> should be composed or not.
>
> In some earlier prettify-symbols code (the one used in haskell-mode),
> I extended the alist so that each element can have a predicate
> checking whether this occurrence should be composed (this is used in
> Haskell for the "." which can either be the function-composition infix
> operator, or the usual separator used within identifiers as in
> List.map).
>
> We should probably extend prettify-symbols-alist similarly, but in the
> case of TeX, I think setting a predicate for every entry is
> inconvenient, and we should instead set a "global" predicate which is
> applied to every entry (and is used instead of the default code which
> checks the syntax-class of surrounding characters).

Is the below what you are suggesting?  That's the "global" (aka
mode/buffer specific predicate) version.  I don't think we need to
extend `prettify-symbols-alist'.  If the composition-predicate is
different for some symbols, then the new
`prettify-symbols-compose-predicate' can do that distinction, too.

And in the (IMHO unlikely) case that a user wants to add symbols which
require a different special-casing, he can just define his own
compose-predicate handling his own symbols and delegating to the default
predicate for that mode in the other cases.

--8<---------------cut here---------------start------------->8---
References: prettify-symbols
Author:     Tassilo Horn <tsdh@gnu.org>
AuthorDate: Thu Aug 20 09:58:28 2015 +0200
Commit:     Tassilo Horn <tsdh@gnu.org>
CommitDate: Thu Aug 20 10:03:46 2015 +0200

    Generalize prettify-symbols to arbitrary modes
    
    * lisp/progmodes/prog-mode.el
    (prettify-symbols-default-compose-p): New function.
    (prettify-symbols-compose-predicate): New variable with default
    value #'prettify-symbols-default-compose-p.
    (prettify-symbols--compose-symbol): Use
    prettify-symbols-compose-predicate.

1 parent commit, 2 merged branches, 1 containing branch
 Parent     | d0079c9 In `widget-color--choose-action' quit *Color* window instead of deleting it
 Merged     | master prettify-symbols
 Containing | prettify-symbols
 Follows    | emacs-24.5-rc3-fixed (5619)

1 file changed, 28 insertions(+), 14 deletions(-)
 lisp/progmodes/prog-mode.el | 42 ++++++++++++++++++++++++++++--------------

modified   lisp/progmodes/prog-mode.el
@@ -133,26 +133,40 @@ Each element looks like (SYMBOL . CHARACTER), where the symbol
 matching SYMBOL (a string, not a regexp) will be shown as
 CHARACTER instead.")
 
-(defun prettify-symbols--compose-symbol (alist)
-  "Compose a sequence of characters into a symbol.
-Regexp match data 0 points to the chars."
+(defun prettify-symbols-default-compose-p ()
+  "The default `prettify-symbols-compose-predicate'.
+Suitable for most programming languages such as C or Lisp."
   ;; Check that the chars should really be composed into a symbol.
   (let* ((start (match-beginning 0))
 	 (end (match-end 0))
 	 (syntaxes-beg (if (memq (char-syntax (char-after start)) '(?w ?_))
                            '(?w ?_) '(?. ?\\)))
 	 (syntaxes-end (if (memq (char-syntax (char-before end)) '(?w ?_))
-		       '(?w ?_) '(?. ?\\)))
-	 match)
-    (if (or (memq (char-syntax (or (char-before start) ?\s)) syntaxes-beg)
-	    (memq (char-syntax (or (char-after end) ?\s)) syntaxes-end)
-            ;; syntax-ppss could modify the match data (bug#14595)
-            (progn (setq match (match-string 0)) (nth 8 (syntax-ppss))))
-	;; No composition for you.  Let's actually remove any composition
-	;; we may have added earlier and which is now incorrect.
-	(remove-text-properties start end '(composition))
-      ;; That's a symbol alright, so add the composition.
-      (compose-region start end (cdr (assoc match alist)))))
+                           '(?w ?_) '(?. ?\\))))
+    (not (or (memq (char-syntax (or (char-before start) ?\s)) syntaxes-beg)
+             (memq (char-syntax (or (char-after end) ?\s)) syntaxes-end)
+             (nth 8 (syntax-ppss))))))
+
+(defvar-local prettify-symbols-compose-predicate #'prettify-symbols-default-compose-p
+  "A predicate deciding if the currently matched symbol is to be composed.
+The predicate has no arguments and is called by font-lock in the
+context where the regexp match data 0 points to an occurrence of
+a symbol in `prettify-symbols-alist'.")
+
+(defun prettify-symbols--compose-symbol (alist)
+  "Compose a sequence of characters into a symbol.
+Regexp match data 0 points to the chars."
+  ;; Check that the chars should really be composed into a symbol.
+  (let ((start (match-beginning 0))
+        (end (match-end 0))
+        (match (match-string 0)))
+    (if (funcall prettify-symbols-compose-predicate)
+        ;; That's a symbol alright, so add the composition.
+        (compose-region start end (cdr (assoc match alist)))
+      ;; No composition for you.  Let's actually remove any
+      ;; composition we may have added earlier and which is now
+      ;; incorrect.
+      (remove-text-properties start end '(composition))))
   ;; Return nil because we're not adding any face property.
   nil)
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo

Re: Generalizing prettify-symbols-mode

[Stefan Monnier]

> Is the below what you are suggesting?

Pretty much, yes.  See nitpicks below.

>     (prettify-symbols-compose-predicate): New variable with default
>     value #'prettify-symbols-default-compose-p.

You don't need to state its default value here.

>     (prettify-symbols--compose-symbol): Use
>     prettify-symbols-compose-predicate.

I like to say "Use it" after reordering the entries so that the "used"
thingy is the one mentioned in the previous entry.

> +(defvar-local prettify-symbols-compose-predicate #'prettify-symbols-default-compose-p
> +  "A predicate deciding if the currently matched symbol is to be composed.
> +The predicate has no arguments and is called by font-lock in the
> +context where the regexp match data 0 points to an occurrence of
> +a symbol in `prettify-symbols-alist'.")

The fact that it uses font-lock should not be documented.  We may want
to change that in the future.

> +  (let ((start (match-beginning 0))
> +        (end (match-end 0))
> +        (match (match-string 0)))
> +    (if (funcall prettify-symbols-compose-predicate)

The predicate will probably need to extract the boundary positions and
the string as well, so I think we might as well pass start, end, and
match to prettify-symbols-compose-predicate.  That also means that
prettify-symbols-compose-predicate doesn't need the match-data any more,
which I think is a good side-effect (tho not an important one).  E.g. it
could be useful if we ever end up using a different search strategy
where we either don't use a regexp, or use regexp where the
matched string is not in "subgroup 0".


        Stefan

Re: Generalizing prettify-symbols-mode

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Is the below what you are suggesting?
>
> Pretty much, yes.  See nitpicks below.

Ok, I've pushed it after changing the things you've suggested.

Bye,
Tassilo

Re: Generalizing prettify-symbols-mode

[Tassilo Horn]

Tassilo Horn <tsdh@gnu.org> writes:

>>> Is the below what you are suggesting?
>>
>> Pretty much, yes.  See nitpicks below.
>
> Ok, I've pushed it after changing the things you've suggested.

Ok, I've also pushed a change to tex-mode.el which adds a custom
`prettify-symbols-compose-predicate'.  It's quite likely that there are
still some cornercases but it handles at least the \alpha2 case as you
suggested.

Bye,
Tassilo

Re: Generalizing prettify-symbols-mode

[Stefan Monnier]

> Ok, I've also pushed a change to tex-mode.el which adds a custom
> `prettify-symbols-compose-predicate'.  It's quite likely that there are
> still some cornercases but it handles at least the \alpha2 case as you
> suggested.

Cool, thanks,


        Stefan

Re: port x-symbol to GNU emacs 24.

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]


> Uwe Brauer <oub@mat.ucm.es> writes:

> But I have no clue what specifiers are...


> I just downloaded x-symbol 4.5.1, and in its x-symbol-emacs.el there are
> several aliases defined for things that error for you.  For example,
> `map-extents' is made an alias for `cl-map-overlays'.  So you have to
> load that first.

They are used in the file x-symbol-site.el
(remove-specifier (get (get-face 'isearch) 'font))
(set-face-foreground 'isearch "white" nil '(mono))
(set-face-background 'isearch "black" nil '(mono))
(remove-specifier (get (get-face 'highlight) 'font))
(set-face-underline-p 'highlight t nil '(mono))

Frankly in a context in which it does not look to important for me.

> Well, eventually when loading x-symbol.el I also got an
> wrong-number-of-arguments error but that's probably an incompatibility
> which is easy to fix.


I made some progress, the biggest problem is the error concerning this
problem, but this time the backtrace seems a bit better.
Any comment?


[-- Attachment #2: bug-symbol.txt --]
[-- Type: text/plain, Size: 4561 bytes --]

Debugger entered--Lisp error: (wrong-type-argument listp "-adobe-helvetica-medium-r-normal-*-14-*-*-*-*-*-iso8859-1")
  x-complement-fontset-spec(["*" "*" "*" "*" "*" "*" "*" "*" "*" "*" "*" "*" "*" "*"] ((ascii . "-adobe-helvetica-medium-r-normal-*-14-*-*-*-*-*-iso8859-1")))
  x-symbol-set-face-font(x-symbol-face "-adobe-helvetica-medium-r-normal-*-14-*-*-*-*-*-iso8859-1" (nil latin-iso8859-1) t)
  x-symbol-make-cset(((("iso8859-1" . iso-8859-1) 159 -3750) nil latin-iso8859-1) (("-adobe-helvetica%s-medium-r-normal-*-%d-*-*-*-*-*-iso8859-1") ("-adobe-helvetica%s-medium-r-normal-*-%d-*-*-*-*-*-iso8859-1") ("-adobe-helvetica%s-medium-r-normal-*-%d-*-*-*-*-*-iso8859-1")))
  x-symbol-init-cset(((("iso8859-1" . iso-8859-1) 159 -3750) nil latin-iso8859-1) ("-adobe-helvetica%s-medium-r-normal-*-%d-*-*-*-*-*-iso8859-1") ((nobreakspace 160 (white) nil nil (" ")) (exclamdown 161 (punctuation) nil nil ("!")) (cent 162 (currency "c") nil nil ("C|" "|C")) (sterling 163 (currency "L") nil nil ("L-" "-L")) (currency 164 (currency "x") nil nil ("ox" "xo")) (yen 165 (currency "Y") nil nil ("Y=" "=Y")) (brokenbar 166 (line) nil nil ("!!")) (section 167 (symbol) nil nil ("SS")) (diaeresis 168 (diaeresis accent)) (copyright 169 (symbol "C") nil nil ("CO" "cO")) (ordfeminine 170 (symbol "a") (shift up) nil ("a_" "_a")) (guillemotleft 171 (quote open guillemotright) (direction west . guillemotright) nil (t "<<")) (notsign 172 (symbol) nil nil ("-,")) (hyphen 173 (line) (size sml) nil ("-")) (registered 174 (symbol "R") nil nil ("RO")) (macron 175 (line) (shift up) nil ("-")) (degree 176 (symbol "0") (shift up) nil ("o^" "^o")) (plusminus 177 (operator) (direction north) nil (t "+-" t "+_")) (twosuperior 178 (symbol "2") (shift up) nil ("2^" "^2")) (threesuperior 179 (symbol "3") (shift up) nil ("3^" "^3")) (acute 180 (acute accent)) (mu1 181 (greek1 "m" nil "mu")) (paragraph 182 (symbol "P") nil nil ("q|")) (periodcentered 183 (dots) (shift up) nil ("." ".^" t "^.")) (cedilla 184 (cedilla accent)) (onesuperior 185 (symbol "1") (shift up) nil ("1^" "^1")) (masculine 186 (symbol "o") (shift up) nil ("o_" "_o")) (guillemotright 187 (quote close guillemotleft) (direction east) nil (t ">>")) (onequarter 188 (symbol "1") nil nil ("1Q" "1/4")) (onehalf 189 (symbol "2") nil nil ("1H" "1/2")) (threequarters 190 (symbol "3") nil nil ("3Q" "3/4")) (questiondown 191 (punctuation) nil nil ("?")) (Agrave 192 (grave "A" agrave)) (Aacute 193 (acute "A" aacute)) (Acircumflex 194 (circumflex "A" acircumflex)) (Atilde 195 (tilde "A" atilde)) (Adiaeresis 196 (diaeresis "A" adiaeresis)) (Aring 197 (ring "A" aring)) (AE 198 (letter "AE" ae)) (Ccedilla 199 (cedilla "C" ccedilla)) (Egrave 200 (grave "E" egrave)) (Eacute 201 (acute "E" eacute)) (Ecircumflex 202 (circumflex "E" ecircumflex)) (Ediaeresis 203 (diaeresis "E" ediaeresis)) (Igrave 204 (grave "I" igrave)) (Iacute 205 (acute "I" iacute)) (Icircumflex 206 (circumflex "I" icircumflex)) (Idiaeresis 207 (diaeresis "I" idiaeresis)) (ETH 208 (slash "D" eth) nil 120) (Ntilde 209 (tilde "N" ntilde)) ...))
  byte-code("\b\204o\0\306 \210\307\x11\310 \204/\0\n\204\x16\0\311\312!\210\v\313=\204/\0\307\211\x14\x15\307\211\x16\x0e\x16\x0f\307\211\x16\x10\x16\x11\307\x16\x12\314\x0e\x13\f\x0e\x14#\210\314\x0e\x15\r\x0e\x16#\210\314\x0e\x17\x0e\x0e\x0e\x18#\210\314\x0e\x19\x0e\x0f\x0e\x1a#\210\314\x0e^[\x0e\x10\x0e\x1c#\210\315 \210\314\x0e\x1d\x0e\x11\x0e\x1e#\210\314\x0e\x1f\x0e\x12\x0e #\210\307\207" [noninteractive x-symbol-all-charsyms x-symbol-default-coding x-symbol-latin-force-use x-symbol-latin1-fonts x-symbol-latin2-fonts x-symbol-initialize nil console-type warn "X-Symbol: only limited support on a console" console-user x-symbol-init-cset x-symbol-init-latin-decoding x-symbol-latin3-fonts x-symbol-latin5-fonts x-symbol-latin9-fonts x-symbol-xsymb0-fonts x-symbol-xsymb1-fonts x-symbol-latin1-cset x-symbol-latin1-table x-symbol-latin2-cset x-symbol-latin2-table x-symbol-latin3-cset x-symbol-latin3-table x-symbol-latin5-cset x-symbol-latin5-table x-symbol-latin9-cset x-symbol-latin9-table x-symbol-xsymb0-cset x-symbol-xsymb0-table x-symbol-xsymb1-cset x-symbol-xsymb1-table] 5)
  require(x-symbol)
  byte-code("\300\301!\210\302\303!\207" [provide x-symbol-image require x-symbol] 2)
  require(x-symbol-image)
  eval-buffer(#<buffer  *load*> nil "/home/oub/ALLES/emacs/x-symbol_init.el" nil t)  ; Reading at buffer position 1259
  load-with-code-conversion("/home/oub/ALLES/emacs/x-symbol_init.el" "/home/oub/ALLES/emacs/x-symbol_init.el" nil nil)
  load("/home/oub/ALLES/emacs/x-symbol_init.el" nil nil t)
  load-file("~/ALLES/emacs/x-symbol_init.el")
  call-interactively(load-file nil nil)
  command-execute(load-file)

Re: port x-symbol to GNU emacs 24.

[Stephen J. Turnbull]

Uwe Brauer writes:

 > Ok, so I have to dig more into the code or hope that somebody in
 > xemacs-beta could point me out what is the GNU emacs equivalent to those
 > functions. I still wonder how x-symbol could have worked under GNU
 > emacs 21, given that extents and specifiers did not exist neither for
 > emacs 21.

AFAIK you're the only user left, and you've spent quite a bit of time,
both yours and others', on trying to keep this code working (which was
idiosyncratic when written, to say the least).  I'm giving up.  This
is my last post, ever, on x-symbol (except if necessary to veto
changes to XEmacs :-/ ).

Extents are a unification[1] of Emacs's overlays and text properties,
with a similar API.  Most likely you want to use the text property API
rather than the overlay API.

Specifiers are a unification and generalization of buffer-local and
frame-local variables[2], but with a rather different API that has to
be invoked explicitly to reference and mutate them, rather than being
a special type of variable that is referenced and mutated in the usual
way.  I suppose that you can probably ignore the specifier stuff,
however, and just use Customize to define the appropriate faces
(defface) which are selected for the x-symbol charset.

Another problem you'll run into in more recent GNU Emacs is that the
internal encoding (a UTF-8 extension) no longer has charsets in the
sense that Mule encoding did, as part of each character.  So you will
need to define a charset to hold the x-symbol characters (a Unicode
block, possibly in Unicode private space but perhaps outside of the
official range of Unicode scalars) using an API that is not relevant
to XEmacs, I suspect.

Note that it's probably possible to achieve what x-symbol does in 1/5
the code and without defining a new charset or glyphs by simply taking
advantage of the fact that most (all?) of those symbols are already in
Unicode.  I believe there are TeX add-ons that allow you to use them
instead of the traditional macros, as well, so you might not even need
to fiddle the display of the TeX file at all, and x-symbol would be
completely irrelevant.

Footnotes: 
[1]  IIRC, there's a corner case involving text properties that can't
be properly simulated using only extent properties, but it's otherwise
equivalent.

[2]  ISTR frame-locals have been deprecated or removed in recent Emacs?

Re: port x-symbol to GNU emacs 24.

[Uwe Brauer]

>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes:

   > Uwe Brauer writes:
   >> Ok, so I have to dig more into the code or hope that somebody in
   >> xemacs-beta could point me out what is the GNU emacs equivalent to those
   >> functions. I still wonder how x-symbol could have worked under GNU
   >> emacs 21, given that extents and specifiers did not exist neither for
   >> emacs 21.


   > Note that it's probably possible to achieve what x-symbol does in 1/5
   > the code and without defining a new charset or glyphs by simply taking
   > advantage of the fact that most (all?) of those symbols are already in
   > Unicode.  I believe there are TeX add-ons that allow you to use them
   > instead of the traditional macros, as well, so you might not even need
   > to fiddle the display of the TeX file at all, and x-symbol would be
   > completely irrelevant.

Do you have any reference, or is this just a guess?

Re: port x-symbol to GNU emacs 24.

[Stephen J. Turnbull]

Uwe Brauer writes:

 > Do you have any reference, or is this just a guess?

 >    > Note that it's probably possible to achieve what x-symbol does
 >    > in 1/5 the code and without defining a new charset or glyphs
 >    > by simply taking advantage of the fact that most (all?) of
 >    > those symbols are already in Unicode.

That's almost certainly true; I don't know what kind of math you do so
I can't be sure the symbols you need are in Unicode, but certainly all
the math symbols I can remember are in it (I admit I haven't memorized
the symbol tables in the TeXBook.)  So I think the odds are quite high
that you can rip out of x-symbol all of the charset code and glyph
definitions, and just use the macro/character swapping code and input
methods.

 >    > I believe there are TeX add-ons that allow you to use them
 >    > instead of the traditional macros, as well, so you might not
 >    > even need to fiddle the display of the TeX file at all, and
 >    > x-symbol would be completely irrelevant.

That's a guess, based on the fact that recent versions of xelatex
uglified documents derived from my older templates until I set the
parameter that enables the traditional double-APOSTROPHE,
double-GRAVE, and multiple-hyphen ligatures again.

It's certainly possible to do this, but since these are all going to
be multibyte characters you'd need to do some really obnoxious
gymnastics with active characters.

Re: port x-symbol to GNU emacs 24.

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Uwe Brauer writes:
>
>  > Do you have any reference, or is this just a guess?
>
>  >    > Note that it's probably possible to achieve what x-symbol does
>  >    > in 1/5 the code and without defining a new charset or glyphs
>  >    > by simply taking advantage of the fact that most (all?) of
>  >    > those symbols are already in Unicode.
>
> That's almost certainly true; I don't know what kind of math you do so
> I can't be sure the symbols you need are in Unicode, but certainly all
> the math symbols I can remember are in it (I admit I haven't memorized
> the symbol tables in the TeXBook.)  So I think the odds are quite high
> that you can rip out of x-symbol all of the charset code and glyph
> definitions, and just use the macro/character swapping code and input
> methods.

Well, X-Symbol was focused on providing math mainly for LaTeX, and the
STIX project's mission <URL:http://www.stixfonts.org/project.html>
states "All characters/glyphs have been incorporated into Unicode
representation or comparable representation and browsers include program
logic to fully utilize the STIX font set in the electronic
representation of scholarly scientific documents" can more succinctly be
expressed as "let Barbara Beeton dump all of AMSTeX into Unicode".

So indeed I should be surprised if the current state of Unicode did not
actually cover most of X-Symbol satisfactorily by now.

-- 
David Kastrup