Re: [AUCTeX-devel] support for xemacs

[Arash Esbati]

Hi Keita,

Ikumi Keita <address@hidden> writes:

>> Probably we should seriously discuss if we still want to support
>> XEmacs.
>
> Regarding support for xemacs, I recently noticed that the function
> `replace-regexp-in-string', which is not available in xemacs, is used at
> several places of AUCTeX.  The output of `grep -Er
> replace-regexp-in-string .' is:
> ----------------------------------------------------------------------
> ./style/empheq.el:      (setq match (replace-regexp-in-string "[ \t\n\r%]*" ""

`replace-regexp-in-string' is used, and I see an unnecessary `*' there.

> ./style/graphicx.el:     ;; We don't have `replace-regexp-in-string' in all 
> (X)Emacs versions:

It is only in the comment; the style provides a work-around and does not
use `replace-regexp-in-string'.

> ./style/tcolorbox.el:   (push (replace-regexp-in-string "[ %\n\r\t]" "" (car 
> x)) libs))

`replace-regexp-in-string' is used.

> ./style/paracol.el:        ;; (replace-regexp-in-string (regexp-quote "*") "" 
> env)

It is only in the comment, the function is not used.

> ./style/xcolor.el:               (replace-regexp-in-string "[ %\n\r\t]" "" 
> (nth 2 colset))

`replace-regexp-in-string' is used.

> ./latex.el:      (LaTeX-add-bibliographies (replace-regexp-in-string
> ./tex.el:                (file-error (replace-regexp-in-string "^file://" "" 
> file))))

`replace-regexp-in-string' is used (wasn't me though).

You caught me here, it was mostly me using `replace-regexp-in-string'
:-)

> ----------------------------------------------------------------------
> Although I haven't confirmed yet, it is almost certain that these
> functionality cause error when used on xemacs.
>
> However, according to the above doc string, `replace-in-string' is
> slightly different from `replace-regexp-in-string' apart from the order
> of the arguments.  (For example, the latter accepts function for the new
> string argument while the former does not.)  If the current (or future)
> AUCTeX uses such functionality, compatibility function approach breaks.
>
> What should we do?

Personally, I have a preference to fix these couple of cases and other
known compat-issues with some `if' constructs, release a new AUCTeX and
mark it as the last one which supports XEmacs and focus on supporting
Emacs.  This might sound harsh, but the future of XEmacs seems to be
uncertain.  If in some years XEmacs is alive and kicking again, we could
see how we can support it again and make incompatible functions work
again.

But for the time being, I don't want to do without many features
provided by Emacs and not by XEmacs (see above).  The same thing applies
to older versions of Emacs: I think we should support Emacs>=24 as we
are trying to move users towards ELPA.

Just my 2 cents here.

Best, Arash