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

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

[Drew Adams]

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@gnu.org-20141020195941-icp42t8ttcnud09g
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking=yes,glyphs CPPFLAGS=-DGLYPH_DEBUG=1'

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

[Lars Ingebrigtsen]

Drew Adams <drew.adams@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#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer'

[Drew Adams]

> > 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.

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

[Eli Zaretskii]

> Cc: "19070@debbugs.gnu.org" <19070@debbugs.gnu.org>
> From: Drew Adams <drew.adams@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?

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

[Drew Adams]

> > > 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.

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "larsi@gnus.org" <larsi@gnus.org>,
>         "19070@debbugs.gnu.org"
> 	<19070@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.

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

[Drew Adams]

> > > 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.

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "larsi@gnus.org" <larsi@gnus.org>,
>         "19070@debbugs.gnu.org"
> 	<19070@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.

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

[Drew Adams]

> > 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.

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

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "larsi@gnus.org" <larsi@gnus.org>,
>         "19070@debbugs.gnu.org"
> 	<19070@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).

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

[Kévin Le Gouguec]

Eli Zaretskii <eliz@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.

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

[Robert Pluim]

>>>>> On Thu, 12 May 2022 23:57:01 +0200, Kévin Le Gouguec <kevin.legouguec@gmail.com> said:

    Kévin> Eli Zaretskii <eliz@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
--