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