GNU bug report logs - #79935
[PATCH] Fix navigation to errors in narrowed buffers

Previous Next

To reply to this bug, email your comments to 79935 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: bug-auctex <at> gnu.org
Subject: [PATCH] Fix navigation to errors in narrowed buffers
Date: Tue, 02 Dec 2025 06:24:49 +0100

[Message part 1 (text/plain, inline)]

Hi all,

I noticed that error navigation (via 'C-c `') does not work correctly in
narrowed buffers.

The main issue is that in a buffer where the current restriction omits N
lines at the top, 'C-c `' moves to N lines beyond where it should, due
to the difference between relative and absolute line numbers.

A secondary issue is that 'C-c `' does not navigate to errors outside
the current restriction.

The patch addresses both in the expected way.  For the secondary issue,
it made sense to widen when jumping to errors outside the current
restriction because this behavior mirrors that of similar commands in
Emacs (e.g., grep + next-error).

Any feedback welcome.

Thanks, best,

Paul

[0001-Fix-navigation-to-errors-in-narrowed-buffers.patch (text/x-patch, attachment)]

Message #8 received at 79935 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: 79935 <at> debbugs.gnu.org
Subject: Re: bug#79935: [PATCH] Fix navigation to errors in narrowed buffers
Date: Wed, 03 Dec 2025 10:05:06 +0100

Hi Paul,

"Paul D. Nelson" <ultrono <at> gmail.com> writes:

> I noticed that error navigation (via 'C-c `') does not work correctly in
> narrowed buffers.
>
> The main issue is that in a buffer where the current restriction omits N
> lines at the top, 'C-c `' moves to N lines beyond where it should, due
> to the difference between relative and absolute line numbers.
>
> A secondary issue is that 'C-c `' does not navigate to errors outside
> the current restriction.
>
> The patch addresses both in the expected way.  For the secondary issue,
> it made sense to widen when jumping to errors outside the current
> restriction because this behavior mirrors that of similar commands in
> Emacs (e.g., grep + next-error).
>
> Any feedback welcome.

Thanks, I think your suggestion makes sense.  I have only one comment
below.

> From ddab8605baefada76c52d8cc89718901fea4e213 Mon Sep 17 00:00:00 2001
> From: Paul Nelson <ultrono <at> gmail.com>
> Date: Tue, 2 Dec 2025 06:06:53 +0100
> Subject: [PATCH] Fix navigation to errors in narrowed buffers
>
> * tex.el (TeX-find-display-help): When searching for errors,
> widen temporarily.  If the error lies outside the current
> restriction, then widen to make the error visible before
> navigating to it.
> ---
>  tex.el | 55 +++++++++++++++++++++++++++++++++++--------------------
>  1 file changed, 35 insertions(+), 20 deletions(-)
>
> diff --git a/tex.el b/tex.el
> index 7c14a135..8560a1fb 100644
> --- a/tex.el
> +++ b/tex.el
> @@ -9788,26 +9788,41 @@ value is not used here."
>            (setq-local TeX-command-buffer command-buffer)
>  
>            ;; Find the location of the error or warning.
> -          (when TeX-translate-location-line
> -            (goto-char (point-min))
> -            (forward-line (+ TeX-translate-location-offset
> -                             TeX-translate-location-line -1))
> -            (cond
> -             ;; Error.
> -             ((equal type 'error)
> -              (if (not (string= TeX-translate-location-string " "))
> -                  (search-forward TeX-translate-location-string nil t)))
> -             ;; Warning or bad box.
> -             (t
> -              (beginning-of-line 0)
> -              (setq start (point))
> -              (goto-char (point-min))
> -              (forward-line (+ TeX-translate-location-offset
> -                               line-end -1))
> -              (end-of-line)
> -              (when TeX-translate-location-string
> -                (search-backward TeX-translate-location-string start t)
> -                (search-forward TeX-translate-location-string nil t))))))
> +          (let ((narrowed (buffer-narrowed-p))
> +                (visible-start (point-min))
> +                (visible-end (point-max))
> +                target-pos)
> +            (when TeX-translate-location-line
> +              (save-restriction
> +                (widen)
> +                (goto-char (point-min))
> +                (forward-line (+ TeX-translate-location-offset
> +                                 TeX-translate-location-line -1))
> +                (cond
> +                 ;; Error.
> +                 ((equal type 'error)
> +                  (if (not (string= TeX-translate-location-string " "))
> +                      (search-forward TeX-translate-location-string nil t)))
> +                 ;; Warning or bad box.
> +                 (t
> +                  (beginning-of-line 0)
> +                  (setq start (point))
> +                  (goto-char (point-min))
> +                  (forward-line (+ TeX-translate-location-offset
> +                                   line-end -1))
> +                  (end-of-line)
> +                  (when TeX-translate-location-string
> +                    (search-backward TeX-translate-location-string start t)
> +                    (search-forward TeX-translate-location-string nil t))))

Can we rewrite the (cond ...) part to:

  (if (equal type 'error)
      ;; Error.
      (unless (string= TeX-translate-location-string " ")
        (search-forward TeX-translate-location-string nil t))
    ;; Warning or bad box.
    (beginning-of-line 0)
    (setq start (point))
    (goto-char (point-min))
    (forward-line (+ TeX-translate-location-offset
                     line-end -1))
    (end-of-line)
    (when TeX-translate-location-string
      (search-backward TeX-translate-location-string start t)
      (search-forward TeX-translate-location-string nil t)))

I think it is much easier to read.  WDYT?

Best, Arash

Message #11 received at 79935 <at> debbugs.gnu.org (full text, mbox):

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Arash Esbati <arash <at> gnu.org>
Cc: 79935 <at> debbugs.gnu.org
Subject: Re: bug#79935: [PATCH] Fix navigation to errors in narrowed buffers
Date: Wed, 03 Dec 2025 10:32:59 +0100

[Message part 1 (text/plain, inline)]

Hi Arash,

> Thanks, I think your suggestion makes sense.  I have only one comment
> below.
>
> ...
>
> Can we rewrite the (cond ...) part to:
>
> ...
>
> I think it is much easier to read.  WDYT?

Agreed.

I noticed a few other places where it seemed the readability of the
affected code could be improved (see attached).  Look OK to you?

Thanks, best,

Paul

[0001-Fix-navigation-to-errors-in-narrowed-buffers.patch (text/x-patch, attachment)]

Message #14 received at 79935 <at> debbugs.gnu.org (full text, mbox):

From: Arash Esbati <arash <at> gnu.org>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: 79935 <at> debbugs.gnu.org
Subject: Re: bug#79935: [PATCH] Fix navigation to errors in narrowed buffers
Date: Wed, 03 Dec 2025 12:02:03 +0100

Hi Paul,

"Paul D. Nelson" <ultrono <at> gmail.com> writes:

> I noticed a few other places where it seemed the readability of the
> affected code could be improved (see attached).  Look OK to you?

Thanks for considering, LGTM.

Best, Arash

Message #19 received at 79935-done <at> debbugs.gnu.org (full text, mbox):

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Arash Esbati <arash <at> gnu.org>
Cc: 79935-done <at> debbugs.gnu.org
Subject: Re: bug#79935: [PATCH] Fix navigation to errors in narrowed buffers
Date: Wed, 03 Dec 2025 15:04:46 +0100

Thanks Arash, installed.  Paul

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.