[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19070: 25.0.50; Provide a user option that filters the buffer list f
From: |
Drew Adams |
Subject: |
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.
- bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer', Lars Ingebrigtsen, 2022/05/11
- bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer', Drew Adams, 2022/05/12
- bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer', Eli Zaretskii, 2022/05/12
- bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer', Drew Adams, 2022/05/12
- bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer', Eli Zaretskii, 2022/05/12
- bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer', Drew Adams, 2022/05/12
- bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer', Eli Zaretskii, 2022/05/12
- bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer',
Drew Adams <=
- bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer', Eli Zaretskii, 2022/05/12
- bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer', Kévin Le Gouguec, 2022/05/12
- bug#19070: 25.0.50; Provide a user option that filters the buffer list for `switch-to-next-buffer', Robert Pluim, 2022/05/13