[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[AUCTeX-devel] support for xemacs

From: Ikumi Keita
Subject: [AUCTeX-devel] support for xemacs
Date: Sun, 19 Feb 2017 22:44:48 +0900

Hi all,

> 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%]*" ""
./style/graphicx.el:     ;; We don't have `replace-regexp-in-string' in all 
(X)Emacs versions:
./style/tcolorbox.el:   (push (replace-regexp-in-string "[ %\n\r\t]" "" (car 
x)) libs))
./style/paracol.el:        ;; (replace-regexp-in-string (regexp-quote "*") "" 
./style/xcolor.el:               (replace-regexp-in-string "[ %\n\r\t]" "" (nth 
2 colset))
./latex.el:      (LaTeX-add-bibliographies (replace-regexp-in-string
./tex.el:                (file-error (replace-regexp-in-string "^file://" "" 
Although I haven't confirmed yet, it is almost certain that these
functionality cause error when used on xemacs.

XEmacs has a similar function `replace-in-string' on both 21.4 and
21.5.  I quote the output of C-h f replace-in-string RET:
(replace-in-string STR REGEXP NEWTEXT &optional LITERAL)

Replace all matches in STR for REGEXP with NEWTEXT string,
 and returns the new string.
Optional LITERAL non-nil means do a literal replacement.
Otherwise treat `\' in NEWTEXT as special:
  `\&' in NEWTEXT means substitute original matched text.
  `\N' means substitute what matched the Nth `\(...\)'.
       If Nth parens didn't match, substitute nothing.
  `\\' means insert one `\'.
  `\u' means upcase the next character.
  `\l' means downcase the next character.
  `\U' means begin upcasing all following characters.
  `\L' means begin downcasing all following characters.
  `\E' means terminate the effect of any `\U' or `\L'.
Thus defining a compatibility function, with suitable permutation of
the arguments, seems to be a solution for most cases.

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?

Ikumi Keita

reply via email to

[Prev in Thread] Current Thread [Next in Thread]