Hi Keita, Ikumi Keita <ik...@ikumi.que.jp> 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 _______________________________________________ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel