GNU bug report logs - #40919
27.0.91; next-error-select-buffer does not always behave as documented

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 40919 <at> debbugs.gnu.org, tspiteri <at> ieee.org
Subject: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented
Date: Wed, 20 May 2020 01:21:35 +0300

>> Another variant would be
>> to add an optional choice to the existing option that allows to restore
>> the old behavior and doesn't affect the current behavior in any way.
>
> FWIW, I'd consider that more of a documentation change.
>
> More importantly, and certainly only for Emacs 28, Juri could you remind me
> what we'll be losing by removing the case no. 2 from
> next-error-find-buffer?

It is used to handle such cases when navigating one next-error list
visits a buffer that contains another next-error list - visiting
such buffer should not switch the navigation, it should continue
the initial navigation.

But I'm not proud of the case no. 2, so you can drop it :)

Or better move it to a separate function and provide this function
as an option in next-error-find-buffer-function.

> The ability to switch to an arbitrary Grep buffer and start using it with
> 'M-x next-error'? E.g. if there are several of them. That's more of
> a backward compatibility concern, right? Or do you have scenarios in
> mind where this will really save on keystrokes?

The ability to visit an arbitrary Grep buffer and use 'next-error' in it
to switch navigation should always work as the most reliable and implicit
way to switch navigation.  This is the case no. 3 in next-error-find-buffer.

> On another note, perhaps we could add a message to next-error-select-buffer
> that would be shown if we suspect this command will not have the expected
> result for the user.

Or maybe ask the user using the minibuffer to resolve ambiguity.

Previous Next

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