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

Previous Next

Package: emacs;

Reported by: Trevor Spiteri <tspiteri <at> ieee.org>

Date: Tue, 28 Apr 2020 01:52:01 UTC

Severity: normal

Found in version 27.0.91

Fixed in version 27.1

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Trevor Spiteri <tspiteri <at> ieee.org>
Cc: 40919 <at> debbugs.gnu.org
Subject: bug#40919: 27.0.91; next-error-select-buffer does not always behave as documented
Date: Sun, 03 May 2020 02:38:10 +0300
>> But I'm still not sure if this is a preferable behavior for most users.
>> Maybe this needs a user option?
>
> I thought that the change was unintentional. If it's intentional that's
> another thing. If no one else complains then maybe most users prefer the
> new behavior. I've already added advice to compilation-start so it's not
> hard for me that I prefer the old behavior.

I think the problem occurs only because compilation/grep pop up their
output buffer in another window - this creates ambiguity whether to use
navigation from the current buffer or from another (new) buffer.

It seems there is no right answer suitable for all users.  So I propose
to add more options.

Eli, do you agree with adding more options to `next-error-find-buffer-function'
in emacs-27?

Currently it has one option that defines one of possible behaviors existed
in older versions.  Now we need to add other option for compatibility
with pre-27 versions.

Then users of emacs-27 could decide whether they want to keep
the old behavior or use the new.

I'm not sure about the default value: should it default to pre-27 behavior.




This bug report was last modified 5 years and 49 days ago.

Previous Next


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