GNU bug report logs - #19070
25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer'

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Sun, 16 Nov 2014 16:40:02 UTC

Severity: wishlist

Found in version 25.0.50

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19070 in the body.
You can then email your comments to 19070 AT debbugs.gnu.org in the normal way.

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#19070; Package emacs. (Sun, 16 Nov 2014 16:40:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Drew Adams <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 16 Nov 2014 16:40:02 GMT) Full text and rfc822 format available.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.50; Provide a user option that filters the buffer list for
 `switch-to-next-buffer'
Date: Sun, 16 Nov 2014 08:38:32 -0800 (PST)
Enhancement request.

Provide a user option with a regexp value that filters the buffers (by
name) that are cycled through by `next-buffer' and `previous-buffer'.
Buffer names matching the regexp would be excluded.

The default value should not exclude any buffers.

Or the option could be a cons, with one part determining whether the
regexp is used to exclude or include and the other part being the
regexp.

In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
 of 2014-10-20 on LEG570
Bzr revision: 118168 rgm <at> gnu.org-20141020195941-icp42t8ttcnud09g
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking=yes,glyphs CPPFLAGS=-DGLYPH_DEBUG=1'




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19070; Package emacs. (Thu, 12 May 2022 01:36:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 19070 <at> debbugs.gnu.org
Subject: Re: bug#19070: 25.0.50; Provide a user option that filters the
 buffer list for `switch-to-next-buffer'
Date: Thu, 12 May 2022 03:35:32 +0200
Drew Adams <drew.adams <at> oracle.com> writes:

> Provide a user option with a regexp value that filters the buffers (by
> name) that are cycled through by `next-buffer' and `previous-buffer'.
> Buffer names matching the regexp would be excluded.

Emacs 27.1 added switch-to-prev-buffer-skip, but didn't include a simple
regexp form, and I agree that such a simple form is usually what people
want.  (I know you can achieve some of this stuff by making windows
dedicated, too, but that's another complication.)

> Or the option could be a cons, with one part determining whether the
> regexp is used to exclude or include and the other part being the
> regexp.

I see the charm, but for complex setups like that, I think using
dedicated windows would be the thing.

So I've now added switch-to-prev-buffer-skip-regexp to Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug marked as fixed in version 29.1, send any further explanations to 19070 <at> debbugs.gnu.org and Drew Adams <drew.adams <at> oracle.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Thu, 12 May 2022 01:36:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19070; Package emacs. (Thu, 12 May 2022 16:03:02 GMT) Full text and rfc822 format available.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "19070 <at> debbugs.gnu.org" <19070 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#19070: 25.0.50; Provide a user option that
 filters the buffer list for `switch-to-next-buffer'
Date: Thu, 12 May 2022 16:02:49 +0000
> > Provide a user option with a regexp value that filters the buffers (by
> > name) that are cycled through by `next-buffer' and `previous-buffer'.
> > Buffer names matching the regexp would be excluded.
> 
> Emacs 27.1 added switch-to-prev-buffer-skip, but didn't include a
> simple regexp form, and I agree that such a simple form is usually what people
> want.  (I know you can achieve some of this stuff by making windows
> dedicated, too, but that's another complication.)
> 
> > Or the option could be a cons, with one part determining whether the
> > regexp is used to exclude or include and the other part being the
> > regexp.
> 
> I see the charm, but for complex setups like that, I think using
> dedicated windows would be the thing.
> 
> So I've now added switch-to-prev-buffer-skip-regexp to Emacs 29.

Did you respect this part?

  The default value should not exclude any buffers.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19070; Package emacs. (Thu, 12 May 2022 16:48:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 19070 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#19070: 25.0.50;
 Provide a user option that filters the buffer list for
 `switch-to-next-buffer'
Date: Thu, 12 May 2022 19:47:26 +0300
> Cc: "19070 <at> debbugs.gnu.org" <19070 <at> debbugs.gnu.org>
> From: Drew Adams <drew.adams <at> oracle.com>
> Date: Thu, 12 May 2022 16:02:49 +0000
> 
> > So I've now added switch-to-prev-buffer-skip-regexp to Emacs 29.
> 
> Did you respect this part?
> 
>   The default value should not exclude any buffers.

Did you look at the change that was actually installed?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19070; Package emacs. (Thu, 12 May 2022 16:54:02 GMT) Full text and rfc822 format available.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "19070 <at> debbugs.gnu.org" <19070 <at> debbugs.gnu.org>,
 "larsi <at> gnus.org" <larsi <at> gnus.org>
Subject: RE: [External] : Re: bug#19070: 25.0.50; Provide a user option that
 filters the buffer list for `switch-to-next-buffer'
Date: Thu, 12 May 2022 16:53:18 +0000
> > > So I've now added switch-to-prev-buffer-skip-regexp to Emacs 29.
> >
> > Did you respect this part?
> >   The default value should not exclude any buffers.
> 
> Did you look at the change that was actually installed?

If communicated in the bug thread then I'd know the
answer to the question, and wouldn't need to ask.
It wasn't.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19070; Package emacs. (Thu, 12 May 2022 17:07:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 19070 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: [External] : Re: bug#19070: 25.0.50; Provide a user option that
 filters the buffer list for `switch-to-next-buffer'
Date: Thu, 12 May 2022 20:06:24 +0300
> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "larsi <at> gnus.org" <larsi <at> gnus.org>,
>         "19070 <at> debbugs.gnu.org"
> 	<19070 <at> debbugs.gnu.org>
> Date: Thu, 12 May 2022 16:53:18 +0000
> 
> > > > So I've now added switch-to-prev-buffer-skip-regexp to Emacs 29.
> > >
> > > Did you respect this part?
> > >   The default value should not exclude any buffers.
> > 
> > Did you look at the change that was actually installed?
> 
> If communicated in the bug thread then I'd know the
> answer to the question, and wouldn't need to ask.
> It wasn't.

People who want answers to those questions are expected to look in
Git.  A URL to do so was posted many times in response to your
questions like the above.

Please don't expect people here to post information that you can
easily and trivially find out yourself.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19070; Package emacs. (Thu, 12 May 2022 17:26:02 GMT) Full text and rfc822 format available.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "19070 <at> debbugs.gnu.org" <19070 <at> debbugs.gnu.org>,
 "larsi <at> gnus.org" <larsi <at> gnus.org>
Subject: RE: [External] : Re: bug#19070: 25.0.50; Provide a user option that
 filters the buffer list for `switch-to-next-buffer'
Date: Thu, 12 May 2022 17:25:33 +0000
> > > Did you look at the change that was actually installed?
> >
> > If communicated in the bug thread then I'd know the
> > answer to the question, and wouldn't need to ask.
> > It wasn't.
> 
> People who want answers to those questions are expected to look in
> Git.  A URL to do so was posted many times in response to your
> questions like the above.
> 
> Please don't expect people here to post information that you can
> easily and trivially find out yourself.

If there were an accurate classification of whether
a bug was actually fixed, versus not fixed (won't
fix), then I wouldn't need to look at anything.

In that case, "fixed" or "wont-fix" would suffice.
Alas, we now get tons and tons of "fixed"/"Done"
for bugs that are not fixed.

If a bug is partly fixed, in the view of the fixer,
then yes, IMHO it behooves the closing email to make
clear to the filer what parts were fixed, i.e., how
much it was and wasn't fixed.  That's being honest
and straightforward.

In the case of a doc bug, if the closing email
includes a _link_ to the fixed doc, or if it simply
includes the actual fixed doc textually, then of
course I'll check that result myself.  If not, I'll
have to ask questions such as what I asked here.

For a non-doc bug, a clear description of the fix
can suffice.  And a _link_ to the resulting code,
in the closing email, can help.

There's nothing odd or abnormal about expecting
specific info about how/whether a bug is "fixed".
And this is all the more important because we get
so many falsely claimed "Done" closures.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19070; Package emacs. (Thu, 12 May 2022 17:38:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 19070 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: [External] : Re: bug#19070: 25.0.50; Provide a user option that
 filters the buffer list for `switch-to-next-buffer'
Date: Thu, 12 May 2022 20:37:03 +0300
> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "larsi <at> gnus.org" <larsi <at> gnus.org>,
>         "19070 <at> debbugs.gnu.org"
> 	<19070 <at> debbugs.gnu.org>
> Date: Thu, 12 May 2022 17:25:33 +0000
> 
> > > > Did you look at the change that was actually installed?
> > >
> > > If communicated in the bug thread then I'd know the
> > > answer to the question, and wouldn't need to ask.
> > > It wasn't.
> > 
> > People who want answers to those questions are expected to look in
> > Git.  A URL to do so was posted many times in response to your
> > questions like the above.
> > 
> > Please don't expect people here to post information that you can
> > easily and trivially find out yourself.
> 
> If there were an accurate classification of whether
> a bug was actually fixed, versus not fixed (won't
> fix), then I wouldn't need to look at anything.
> 
> In that case, "fixed" or "wont-fix" would suffice.
> Alas, we now get tons and tons of "fixed"/"Done"
> for bugs that are not fixed.
> 
> If a bug is partly fixed, in the view of the fixer,
> then yes, IMHO it behooves the closing email to make
> clear to the filer what parts were fixed, i.e., how
> much it was and wasn't fixed.  That's being honest
> and straightforward.

The decision whether and how to fix a bug is a judgment call of the
development team.  We don't post all the details of the fix as part of
the bug discussion, because it's a burden, and looking in the Git
repository for the answer to that question is very easy.  Honesty has
nothing to do with that; fairness has everything to do with it: you
are being unfair expecting the Emacs maintainers to do the job that
you can do yourself, and easily so.

> There's nothing odd or abnormal about expecting
> specific info about how/whether a bug is "fixed".

Not nowadays, not with the easy access we all have to the repository
and to the actual fixes.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19070; Package emacs. (Thu, 12 May 2022 17:51:01 GMT) Full text and rfc822 format available.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "19070 <at> debbugs.gnu.org" <19070 <at> debbugs.gnu.org>,
 "larsi <at> gnus.org" <larsi <at> gnus.org>
Subject: RE: [External] : Re: bug#19070: 25.0.50; Provide a user option that
 filters the buffer list for `switch-to-next-buffer'
Date: Thu, 12 May 2022 17:50:13 +0000
> > If there were an accurate classification of whether
> > a bug was actually fixed, versus not fixed (won't
> > fix), then I wouldn't need to look at anything.
> >
> > In that case, "fixed" or "wont-fix" would suffice.
> > Alas, we now get tons and tons of "fixed"/"Done"
> > for bugs that are not fixed.
> >
> > If a bug is partly fixed, in the view of the fixer,
> > then yes, IMHO it behooves the closing email to make
> > clear to the filer what parts were fixed, i.e., how
> > much it was and wasn't fixed.  That's being honest
> > and straightforward.
> 
> The decision whether and how to fix a bug is a judgment call of the
> development team.

No one said anything to the contrary.  Common sense,
as well as politeness, calls for letting bug filers
know what was done and what was not done.

> We don't post all the details of the fix as part of
> the bug discussion, because it's a burden, and looking in the Git
> repository for the answer to that question is very easy.

Link to it directly in the closing mail.  Copy and
paste the URL - "very easy".

It's also a burden for users to report bugs and
follow up in bug threads.

> Honesty has nothing to do with that;

Honesty has to do with claiming that some "fix" was
"done" when it was not.  That's what honesty has to
do with.

> you are being unfair expecting the Emacs maintainers
> to do the job that you can do yourself, and easily so.

Put a direct link to the result (code or doc) in the
close message.

> > There's nothing odd or abnormal about expecting
> > specific info about how/whether a bug is "fixed".
> 
> Not nowadays, not with the easy access we all have
> to the repository and to the actual fixes.

Easy access for users is a link in the email.
Thank you in advance.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19070; Package emacs. (Thu, 12 May 2022 18:15:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 19070 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: [External] : Re: bug#19070: 25.0.50; Provide a user option that
 filters the buffer list for `switch-to-next-buffer'
Date: Thu, 12 May 2022 21:14:17 +0300
> From: Drew Adams <drew.adams <at> oracle.com>
> CC: "larsi <at> gnus.org" <larsi <at> gnus.org>,
>         "19070 <at> debbugs.gnu.org"
> 	<19070 <at> debbugs.gnu.org>
> Date: Thu, 12 May 2022 17:50:13 +0000
> 
> > The decision whether and how to fix a bug is a judgment call of the
> > development team.
> 
> No one said anything to the contrary.  Common sense,
> as well as politeness, calls for letting bug filers
> know what was done and what was not done.

Politeness is a two-way street.  Your wiliness to look up the changes
is your part of the politeness.

> > We don't post all the details of the fix as part of
> > the bug discussion, because it's a burden, and looking in the Git
> > repository for the answer to that question is very easy.
> 
> Link to it directly in the closing mail.  Copy and
> paste the URL - "very easy".

No, not "very easy", because when we install the changes, we don't go
through that URL, we do it by local Emacs commands that don't show the
URL.  The URL of the Git's Web access is something we don't use at
all.

> > Honesty has nothing to do with that;
> 
> Honesty has to do with claiming that some "fix" was
> "done" when it was not.  That's what honesty has to
> do with.

So now anyone who disagrees with you about the proper fix of a bug is
being dishonest?

> > you are being unfair expecting the Emacs maintainers
> > to do the job that you can do yourself, and easily so.
> 
> Put a direct link to the result (code or doc) in the
> close message.

It's a burden.  Once again, here's the URL for the Git Web access:

  https://git.savannah.gnu.org/cgit/emacs.git

Please bookmark it and use it whenever you need to know what was
installed.

> > > There's nothing odd or abnormal about expecting
> > > specific info about how/whether a bug is "fixed".
> > 
> > Not nowadays, not with the easy access we all have
> > to the repository and to the actual fixes.
> 
> Easy access for users is a link in the email.

You have it above (as you had many times before).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19070; Package emacs. (Thu, 12 May 2022 21:58:02 GMT) Full text and rfc822 format available.

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

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 19070 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org
Subject: Re: bug#19070: 25.0.50; Provide a user option that filters the
 buffer list for `switch-to-next-buffer'
Date: Thu, 12 May 2022 23:57:01 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>> Put a direct link to the result (code or doc) in the
>> close message.
>
> It's a burden.  Once again, here's the URL for the Git Web access:
>
>   https://git.savannah.gnu.org/cgit/emacs.git

Note that this page provides a search engine to scan commit messages, so
looking for a change related to a bug number or a symbol is
straightforward (since ChangeLog entries tend to include this
information):

https://git.savannah.gnu.org/cgit/emacs.git/log/?qt=grep&q=bug.19070
https://git.savannah.gnu.org/cgit/emacs.git/log/?qt=grep&q=switch-to-prev-buffer-skip-regexp

Your browser might have a feature to "add a keyword for this search" if
you right-click the input field (Firefox has that, at any rate), so
finding the answer to the question "how was bug#19070 fixed" can be as
simple as typing…

> emacs.git bug#19070

… in your URL bar.

Hope that helps.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#19070; Package emacs. (Fri, 13 May 2022 08:15:01 GMT) Full text and rfc822 format available.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 19070 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org,
 Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#19070: 25.0.50; Provide a user option that filters the
 buffer list for `switch-to-next-buffer'
Date: Fri, 13 May 2022 10:14:30 +0200
>>>>> On Thu, 12 May 2022 23:57:01 +0200, Kévin Le Gouguec <kevin.legouguec <at> gmail.com> said:

    Kévin> Eli Zaretskii <eliz <at> gnu.org> writes:
    >>> Put a direct link to the result (code or doc) in the
    >>> close message.
    >> 
    >> It's a burden.  Once again, here's the URL for the Git Web access:
    >> 
    >> https://git.savannah.gnu.org/cgit/emacs.git

    Kévin> Note that this page provides a search engine to scan commit messages, so
    Kévin> looking for a change related to a bug number or a symbol is
    Kévin> straightforward (since ChangeLog entries tend to include this
    Kévin> information):

    Kévin> https://git.savannah.gnu.org/cgit/emacs.git/log/?qt=grep&q=bug.19070
    Kévin> https://git.savannah.gnu.org/cgit/emacs.git/log/?qt=grep&q=switch-to-prev-buffer-skip-regexp

Thereʼs also

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=<commit id>

which is why I try to put commit id's in my bug closing messages. Or
thereʼs the emacs-diffs mailing list which gets copies of all the
commits.

But this is really off-topic for this bug now.

Robert
-- 




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 10 Jun 2022 11:24:07 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 292 days ago.

Previous Next


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