[Top][All Lists]

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

Re: [AUCTeX-devel] TeX-next-error

From: David Kastrup
Subject: Re: [AUCTeX-devel] TeX-next-error
Date: Tue, 11 Dec 2018 20:39:09 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

> Is there a particular reason why AUCTeX doesn't make use of
> next-error-function and remaps `next-error` via the keymap instead?

I don't really remember.  It may have something to do with XEmacs
compatibility which no longer is something we are bothered with.  Though
I think keybinding and implementation and functionality of
TeX-next-error are much older than next-error-function, so the remap may
just have been an afterthought for a closer connection to the semantics
of next-error and no further work was invested after it worked.

git blame shows

cb75d25f1 (Ralf Angeli                    2005-05-28 16:21:47 +0000 4998)     
;; Remap bindings of `next-error'
6cb1e7deb (Mosè Giordano                  2017-12-17 01:34:21 +0100 4999)     
(define-key map [remap next-error] 'TeX-next-error)
cb75d25f1 (Ralf Angeli                    2005-05-28 16:21:47 +0000 5000)     
;; Remap bindings of `previous-error'
6cb1e7deb (Mosè Giordano                  2017-12-17 01:34:21 +0100 5001)     
(define-key map [remap previous-error] 'TeX-previous-error)

commit cb75d25f1d21b84e0f99477e6cd96bd7657d683b
Author: Ralf Angeli <address@hidden>
Date:   Sat May 28 16:21:47 2005 +0000

    (TeX-mode-map): Remap bindings of `next-error' and
    `previous-error' to `TeX-next-error' and `TeX-previous-error'

commit 6cb1e7deb69a199949926f4a2b33c2bb6b250c13
Author: Mosè Giordano <address@hidden>
Date:   Sun Dec 17 01:34:21 2017 +0100

    Remove XEmacs compatibility code in tex.el
    * tex.el (TeX-source-correlate-gnuserv-p):
    (TeX-search-syntax-table): Remove code for compatibility with XEmacs.

So XEmacs compatibility has been there initially and may have played
into the concept of what was done (possibly trying to keep the system
dependency confined to as small a space as possible).  And the original
code is from 2005.

Looking at the age of next-error-function, I see
commit 50f007fb09bc893294d0229e339e770e16a22f2b
Author: Kim F. Storm <address@hidden>
Date:   Wed Apr 21 21:36:15 2004 +0000

    From: Teodor Zlatanov  <address@hidden>
    (next-error-last-buffer, next-error-function):
    New variables for the next-error framework.
    (next-error-buffer-p): New function.
    (next-error-find-buffer): Generalize compilation-find-buffer.
    (next-error, previous-error, first-error, next-error-no-select)
    (previous-error-no-select): Move from compile.el.

and in 2005 we certainly would not have wanted to depend on code
introduced as recently as 2004.

So the answer is very likely "historical".

David Kastrup

reply via email to

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