* bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer'
@ 2014-11-16 16:38 Drew Adams
2022-05-12 1:35 ` Lars Ingebrigtsen
0 siblings, 1 reply; 12+ messages in thread
From: Drew Adams @ 2014-11-16 16:38 UTC (permalink / raw)
To: 19070
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'
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer'
2014-11-16 16:38 bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer' Drew Adams
@ 2022-05-12 1:35 ` Lars Ingebrigtsen
2022-05-12 16:02 ` Drew Adams
0 siblings, 1 reply; 12+ messages in thread
From: Lars Ingebrigtsen @ 2022-05-12 1:35 UTC (permalink / raw)
To: Drew Adams; +Cc: 19070
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer'
2022-05-12 1:35 ` Lars Ingebrigtsen
@ 2022-05-12 16:02 ` Drew Adams
2022-05-12 16:47 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Drew Adams @ 2022-05-12 16:02 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 19070@debbugs.gnu.org
> > 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer'
2022-05-12 16:02 ` Drew Adams
@ 2022-05-12 16:47 ` Eli Zaretskii
2022-05-12 16:53 ` Drew Adams
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2022-05-12 16:47 UTC (permalink / raw)
To: Drew Adams; +Cc: 19070, larsi
> 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?
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer'
2022-05-12 16:47 ` Eli Zaretskii
@ 2022-05-12 16:53 ` Drew Adams
2022-05-12 17:06 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Drew Adams @ 2022-05-12 16:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 19070@debbugs.gnu.org, larsi@gnus.org
> > > 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer'
2022-05-12 16:53 ` Drew Adams
@ 2022-05-12 17:06 ` Eli Zaretskii
2022-05-12 17:25 ` Drew Adams
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2022-05-12 17:06 UTC (permalink / raw)
To: Drew Adams; +Cc: 19070, larsi
> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer'
2022-05-12 17:06 ` Eli Zaretskii
@ 2022-05-12 17:25 ` Drew Adams
2022-05-12 17:37 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Drew Adams @ 2022-05-12 17:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 19070@debbugs.gnu.org, larsi@gnus.org
> > > 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer'
2022-05-12 17:25 ` Drew Adams
@ 2022-05-12 17:37 ` Eli Zaretskii
2022-05-12 17:50 ` Drew Adams
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2022-05-12 17:37 UTC (permalink / raw)
To: Drew Adams; +Cc: 19070, larsi
> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer'
2022-05-12 17:37 ` Eli Zaretskii
@ 2022-05-12 17:50 ` Drew Adams
2022-05-12 18:14 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Drew Adams @ 2022-05-12 17:50 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 19070@debbugs.gnu.org, larsi@gnus.org
> > 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer'
2022-05-12 17:50 ` Drew Adams
@ 2022-05-12 18:14 ` Eli Zaretskii
2022-05-12 21:57 ` Kévin Le Gouguec
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2022-05-12 18:14 UTC (permalink / raw)
To: Drew Adams; +Cc: 19070, larsi
> 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).
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer'
2022-05-12 18:14 ` Eli Zaretskii
@ 2022-05-12 21:57 ` Kévin Le Gouguec
2022-05-13 8:14 ` Robert Pluim
0 siblings, 1 reply; 12+ messages in thread
From: Kévin Le Gouguec @ 2022-05-12 21:57 UTC (permalink / raw)
To: Drew Adams; +Cc: 19070, Eli Zaretskii, larsi
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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer'
2022-05-12 21:57 ` Kévin Le Gouguec
@ 2022-05-13 8:14 ` Robert Pluim
0 siblings, 0 replies; 12+ messages in thread
From: Robert Pluim @ 2022-05-13 8:14 UTC (permalink / raw)
To: Kévin Le Gouguec; +Cc: 19070, Eli Zaretskii, larsi, Drew Adams
>>>>> 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
--
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-05-13 8:14 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-11-16 16:38 bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer' Drew Adams
2022-05-12 1:35 ` Lars Ingebrigtsen
2022-05-12 16:02 ` Drew Adams
2022-05-12 16:47 ` Eli Zaretskii
2022-05-12 16:53 ` Drew Adams
2022-05-12 17:06 ` Eli Zaretskii
2022-05-12 17:25 ` Drew Adams
2022-05-12 17:37 ` Eli Zaretskii
2022-05-12 17:50 ` Drew Adams
2022-05-12 18:14 ` Eli Zaretskii
2022-05-12 21:57 ` Kévin Le Gouguec
2022-05-13 8:14 ` Robert Pluim
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).