Closing 45% of the open Emacs bugs(lars.ingebrigtsen.no)
lars.ingebrigtsen.no
Closing 45% of the open Emacs bugs
https://lars.ingebrigtsen.no/2021/08/14/10x10/
180 comments
Last message in the thread:
> I'm going to go ahead and guess that the problems discussed were fixed, and I'm closing this bug report. If there's anything more to be worked on here, please send a mail to the debbugs address and we'll reopen the bug report.
I don't think this really qualifies as "ignoring". Having read the last two messages or so, their approach looks totally reasonable to me. Please don't scold maintainers for cleaning up? :(
> I'm going to go ahead and guess that the problems discussed were fixed, and I'm closing this bug report. If there's anything more to be worked on here, please send a mail to the debbugs address and we'll reopen the bug report.
I don't think this really qualifies as "ignoring". Having read the last two messages or so, their approach looks totally reasonable to me. Please don't scold maintainers for cleaning up? :(
Agreed. The bug report was one reporter and a maintainer discussing a bug for 2 months back in 2015, and at the end the maintainer says he believes he’d fixed it. Then no more messages. After 5 years of no complaints after a likely fix, closing it is very, very reasonable.
I'm kind of on the fence for these (in general, not specific to this ticket).
Assuming the STR is clear, is it the original reporter's responsibility, or the developer's, to confirm if a bug is fixed or not?
Assuming the STR is clear, is it the original reporter's responsibility, or the developer's, to confirm if a bug is fixed or not?
IMO, It is the user responsibility to make a reproducible bug (to become a failing test). From there on it is the developer responsibility to fix it (make it a passing test)
Absolutely. If there is nothing new and a bug is still there, there is simply nothing to add to the bug report. Too often now bugs get closed automatically for "inactivity" after a short period. Should users come back every months to "ping" the thread ? Some bugs last for years, they'd sooner be blocked for spamming. It's just Goodhart's law in action, a cheap way to reduce the bug report count.
No other approach is sustainable.
For what it's worth, when I encounter a project doing this I treat it as a giant red flag that the developers don't care about the quality of their project.
In the majority of cases, there's another project that I can move to and I do so as soon as possible.
There are presumably others like me. So when you say it's sustainable, you may not be accounting for the reputational damage it does to your project, which you will almost certainly never be made explicitly aware of because users know it's not worth their time to file bugs.
In the majority of cases, there's another project that I can move to and I do so as soon as possible.
There are presumably others like me. So when you say it's sustainable, you may not be accounting for the reputational damage it does to your project, which you will almost certainly never be made explicitly aware of because users know it's not worth their time to file bugs.
sometimes it feels to me that people collectively forget that writing software (especially FOSS)'s primary goal is to empower other human beings, before anything else - including our own little developer comfort. Closing unfixed bugs because of no activity really really goes against that in my mind.
Closing issues by itself do not fix bugs.
While reporter is still alive.
Really? You think that expecting a user who submitted a bug report five years earlier to still have patience to interact with it is sustainable?
Not five year. Two months went from the OP in September 2015 to the final dev message in November 2015, during which the OP and the dev were communicating regularly. It was the OP who didn't respond after the dev mentioned that he believes that he fixed all the outstanding issues.
It was five years later that someone came along and closed the bug.
It was five years later that someone came along and closed the bug.
I would estimate the chance of a user coming back to close a bug at near zero, even after only two months.
Indeed. As a fellow maintainer I will manually replicate the error the user reports, write an test to around the failing function, then fix said function.
After that I’m usually satisfied the bug has been fixed. So I will link the git commit hash of the fix to the bug report and ask the reporter if it fixes the issue their side. If I don’t hear anything back after a week or two I will follow up with a message much like the aforementioned: “closing this ticket because I believe it to be resolved but happy to reopen if you’re still experiencing issues.”
That is the only way I’ve found to manage projects because you either end up closing tickets prematurely and miss bugs, or you end up with tickets open for fixed issues that take time and additional mental overhead to filter out (both of which are a scarce resource when you’re trying to balance open source maintenance with a full time job and a family).
Two weeks might not seem long but I’m always happy to reopen issues. However if users really feel that hard done by this approach then they’re welcome to submit a pull request instead. Or even fork my project and maintain that they way they feel it should be done. Maybe they’ll have more free time than me to filter through historic issues that are now fixed but not closed between their personal lives and coding time.
After that I’m usually satisfied the bug has been fixed. So I will link the git commit hash of the fix to the bug report and ask the reporter if it fixes the issue their side. If I don’t hear anything back after a week or two I will follow up with a message much like the aforementioned: “closing this ticket because I believe it to be resolved but happy to reopen if you’re still experiencing issues.”
That is the only way I’ve found to manage projects because you either end up closing tickets prematurely and miss bugs, or you end up with tickets open for fixed issues that take time and additional mental overhead to filter out (both of which are a scarce resource when you’re trying to balance open source maintenance with a full time job and a family).
Two weeks might not seem long but I’m always happy to reopen issues. However if users really feel that hard done by this approach then they’re welcome to submit a pull request instead. Or even fork my project and maintain that they way they feel it should be done. Maybe they’ll have more free time than me to filter through historic issues that are now fixed but not closed between their personal lives and coding time.
> ask the reporter if it fixes the issue their side. If I don’t hear anything back after a week or two I will follow up with a message much like the aforementioned: “closing this ticket because I believe it to be resolved but happy to reopen if you’re still experiencing issues.”
This tacitly embraces the bugtracker-as-helpdesk/CRM mindset, i.e., the GitHub approach, which is what leads to things getting so chaotic and unwieldy in the first place. It's right in the language—focusing on "their" issue. Both maintainers and users need to approach the bugracker by recognizing that the scope of any given bug report is the bug, and by extension the project, not the bug reporter or maintainer. By the time a bug is being closed, a maintainer should know (at least with some level of confidence—but allowing for them to be wrong) whether the bug is fixed or not—because it should be well-defined. If the maintainer is not able to do this with confidence, it indicates a failure in the practices for handling bugs—and possibly (or "likely", in the case of a typical project hosted on GitHub) muddled scope.
It may be the case that from the user perspective, they're still experiencing some issue, but this doesn't call for the bug being reopened to handle it. Remember, it's not theirs, it's the bug's! If the last report led to a real bug being identified, and it really was fixed, then leave it closed and figure out if it isn't the case that they misidentified the source of the discomfort they were experiencing, and if so, have them attempt to articulate it, then open a new bug for that. Otherwise, you're just treating your bug tracker like a message board but splattering it with state changes of what amounts to your personal TODO list—where "open" and "closed" correspond to whether you've decided you're finished with it or not. Remember not to think of the bug tracker as yours either! It belongs to the project and its bugs. Think of the software as a non-human entity and you as a scientist and its designated caretaker. It's best to think of the bug reporter as a scientist, too—and the elevated expectations and responsibility that comes with it.
This tacitly embraces the bugtracker-as-helpdesk/CRM mindset, i.e., the GitHub approach, which is what leads to things getting so chaotic and unwieldy in the first place. It's right in the language—focusing on "their" issue. Both maintainers and users need to approach the bugracker by recognizing that the scope of any given bug report is the bug, and by extension the project, not the bug reporter or maintainer. By the time a bug is being closed, a maintainer should know (at least with some level of confidence—but allowing for them to be wrong) whether the bug is fixed or not—because it should be well-defined. If the maintainer is not able to do this with confidence, it indicates a failure in the practices for handling bugs—and possibly (or "likely", in the case of a typical project hosted on GitHub) muddled scope.
It may be the case that from the user perspective, they're still experiencing some issue, but this doesn't call for the bug being reopened to handle it. Remember, it's not theirs, it's the bug's! If the last report led to a real bug being identified, and it really was fixed, then leave it closed and figure out if it isn't the case that they misidentified the source of the discomfort they were experiencing, and if so, have them attempt to articulate it, then open a new bug for that. Otherwise, you're just treating your bug tracker like a message board but splattering it with state changes of what amounts to your personal TODO list—where "open" and "closed" correspond to whether you've decided you're finished with it or not. Remember not to think of the bug tracker as yours either! It belongs to the project and its bugs. Think of the software as a non-human entity and you as a scientist and its designated caretaker. It's best to think of the bug reporter as a scientist, too—and the elevated expectations and responsibility that comes with it.
You're focusing too much on correctness. Bug reports are almost never because a user has identified incorrect behavior, they are because the user has identified unpleasant behavior. The maintainer then takes that reported unpleasantness and decides whether it's a bug or a feature. If it's a bug then the maintainer, usually implicitly, updates the program specification such that the unpleasant behavior is now incorrect, perhaps by writing a test, and then corrects the incorrect behavior. But since the primary motivator is actually the user's reported unpleasant behavior, it makes sense to check that the now correct software also behaves pleasantly for the reporting user. And since pleased users may well just be using the software instead of following up in the bug tracker, it makes sense to close those issues with the proviso that displeased users are welcome to reopen them.
It's an observable truth that if you want people to use your software, it's necessary to prioritize pleasantness. It's also practically a logical necessity, unless your user community is comprised of individuals who enjoy being displeased and otherwise frustrated.
It's an observable truth that if you want people to use your software, it's necessary to prioritize pleasantness. It's also practically a logical necessity, unless your user community is comprised of individuals who enjoy being displeased and otherwise frustrated.
There are multiple types of issues. You’re describing a bug in a very pure sense. But often the most important issues are customer issues where they are blocked and need help. Then it is less about the big that you’re tracking and more about this customers experience. The resolution to their issue might not even be in your products code, but we still track it until the customer is unblocked to use our product.
> Then it is less about the big that you’re tracking and more about this customers experience.
Obviously. (Isn't it? Not sure why this explanation is appearing as a reply here. How could the previous comment have been written without a strong understanding that there's distinction? Why would it have been written unless there was a strong belief in the distinction?)
> we still track it until the customer is unblocked
As you should... in some place that isn't the bug tracker. (See "muddled.")
Obviously. (Isn't it? Not sure why this explanation is appearing as a reply here. How could the previous comment have been written without a strong understanding that there's distinction? Why would it have been written unless there was a strong belief in the distinction?)
> we still track it until the customer is unblocked
As you should... in some place that isn't the bug tracker. (See "muddled.")
Personally if a bug report does not get a reply in two months I'm probably not using it anymore. Collaborating to these kinds of projects is extremely frustrating. Why will I spend my time debugging and implementing features when issues and PR are promptly ignored or closed? Is my time a joke?
Recognising the orignal bug opener's name, Markus Triska, I know he's on HN. I checked his username to see if he's been active recently and, well, see for yourself: https://news.ycombinator.com/threads?id=triska
Maybe if the bug is important, someone else will reply to confirm? That could be a reasonable line of thinking.
Yea, if a bug has been open without further discussion for 5 years then i would too take for granted that the issue is no longer an issue and close it.
There are two instances I can think of (I've done it myself) where the bug is important but user does not come back to check on the report after 1 or 2 weeks:
1) Trying out different environment and finding things that do not work. Report a bug with reproducible example and don't check it for a while (months or years) since there is important work to be done in working environment.
2) Find a bug and then find the workaround since work can't wait for external fixes. Report a bug with reproducible example, check the status for a few days with no responses and then ignore the bug since there is important work to be done and workaround has been applied.
Now you know one of the reasons why "legacy" code might look messy - it has workarounds for the bugs that may have been fixed...but who has the time to go back and check, change, and test the "fixed" code which may introduce other bugs.
And if not, the bug is probably not important. ¯\_(ツ)_/¯
At some point, you have to close things. Chances are they were spurious, have been fixed or made irrelevant (maybe the code no longer exists) or nobody cares.
And if someone does care and it's still an issue, you can reopen. It's not as if you are permanently deleting all the information for the rest of time.
At some point, you have to close things. Chances are they were spurious, have been fixed or made irrelevant (maybe the code no longer exists) or nobody cares.
And if someone does care and it's still an issue, you can reopen. It's not as if you are permanently deleting all the information for the rest of time.
At my last job, this was the attitude we eventually took with tickets that were several years old.
If it's still an issue with our internal customer [0], they can reopen the ticket or open a new one. But we've completely rearchitectured our systems since the ticket was first opened, our internal customer has changed leadership and has had considerable staff turnover, and not a single person has brought it up in our biweekly meetings with our internal customer for ages, so we might as well just close it out.
[0] when I say "customer", I'm talking about a department, not a single individual
If it's still an issue with our internal customer [0], they can reopen the ticket or open a new one. But we've completely rearchitectured our systems since the ticket was first opened, our internal customer has changed leadership and has had considerable staff turnover, and not a single person has brought it up in our biweekly meetings with our internal customer for ages, so we might as well just close it out.
[0] when I say "customer", I'm talking about a department, not a single individual
Assuming you're the author of that bug report, it looks like you never did reply to that last message on 23 Nov 2015, so the developer was left hanging. Seems totally fair to assume this is fixed after half a decade with zero user comments.
As an observation, the whole thread is a back-and-forth exchange of a user supplying incidental test cases and the dev fixing them one by one, for months. I'm actually surprised the main emacs maintainer would put up with this - usually formatters and syntax highlighting are handled by user extensions, it's not humanly possible for one person to be an expert in 100+ programming languages and their favored styles. Someone else who is a heavy user of the language could take the time to dive in and probably fix all the formatting issues in one go. Or make a patch to bring in the third-party better-maintained prolog-mode that is mentioned in the discussion.
As an observation, the whole thread is a back-and-forth exchange of a user supplying incidental test cases and the dev fixing them one by one, for months. I'm actually surprised the main emacs maintainer would put up with this - usually formatters and syntax highlighting are handled by user extensions, it's not humanly possible for one person to be an expert in 100+ programming languages and their favored styles. Someone else who is a heavy user of the language could take the time to dive in and probably fix all the formatting issues in one go. Or make a patch to bring in the third-party better-maintained prolog-mode that is mentioned in the discussion.
In this specific case, the Emacs maintainers took a mode which already shipped with Emacs (in fact it was the mentioned third-party Prolog mode that was already bundled with Emacs with slight modifications) and changed it so that it no longer worked as previously and also not as expected.
It is definitely nice that the Emacs maintainers corrected some of these regressions which I explained in this issue with steps to reproduce them. However, the information from 23 Nov 2015 that 2 out of several regressions I had reported in this issue are now believed to be corrected does not solve the other issues I reported in the course of the discussion and which still remain. It is easy to reproduce them with the instructions I posted in case someone is still interested in correcting them. Alternatively, one can simply use the third-party mode which does not have these issues also because I had previously already contributed changes to specifically address some of these issues in that original version of the mode.
The key reason for the divergence between these two versions of the same original mode is that Emacs maintainers prefer to use SMIE-based indentation for the mode, and switching the mode to SMIE in the Emacs trunk introduced the reported regressions. SMIE is an indentation and navigation engine that the Emacs maintainers provide. My impression from the discussion in the cited issue is that SMIE is lacking some of the features that are needed to implement the desired and previously supported indentation and navigation for this particular mode. There may be a way to improve SMIE to support these use cases, it may be quite hard though: I expect that if it were easy, these changes would have been made by the Emacs maintainers to solve the remaining issues too in the last few years.
It is definitely nice that the Emacs maintainers corrected some of these regressions which I explained in this issue with steps to reproduce them. However, the information from 23 Nov 2015 that 2 out of several regressions I had reported in this issue are now believed to be corrected does not solve the other issues I reported in the course of the discussion and which still remain. It is easy to reproduce them with the instructions I posted in case someone is still interested in correcting them. Alternatively, one can simply use the third-party mode which does not have these issues also because I had previously already contributed changes to specifically address some of these issues in that original version of the mode.
The key reason for the divergence between these two versions of the same original mode is that Emacs maintainers prefer to use SMIE-based indentation for the mode, and switching the mode to SMIE in the Emacs trunk introduced the reported regressions. SMIE is an indentation and navigation engine that the Emacs maintainers provide. My impression from the discussion in the cited issue is that SMIE is lacking some of the features that are needed to implement the desired and previously supported indentation and navigation for this particular mode. There may be a way to improve SMIE to support these use cases, it may be quite hard though: I expect that if it were easy, these changes would have been made by the Emacs maintainers to solve the remaining issues too in the last few years.
[deleted]
[deleted]
[deleted]
[deleted]
> even though the issue still exists.
The second to last post says they believe the issue is fixed, with nobody complaining it isn't fixed for the 5 years after. I guess that doesn't seem like a great example of "they closed the bug without ever fixing it".
The second to last post says they believe the issue is fixed, with nobody complaining it isn't fixed for the 5 years after. I guess that doesn't seem like a great example of "they closed the bug without ever fixing it".
I have to say I find it extremely bad form to write like this hear suggesting you are an unrelated party, while in fact you are the bug reporter who didn't reply when asked if the bug still persists. At least be honest about your involvement in this issue.
I also dislike how your post is written to suggest that this was how the maintainer is closing many bugs, except you give one example which is your bug. This seems more like you are on some crusade because you don't like how your bug was handled.
I also dislike how your post is written to suggest that this was how the maintainer is closing many bugs, except you give one example which is your bug. This seems more like you are on some crusade because you don't like how your bug was handled.
You are right that I should have pointed out explicitly that I filed this specific issue. Please note though that I was not "asked if the bug still persists" before it was closed.
I used this specific example to illustrate the general point I was making, and I took an issue I filed myself because I know for certain that it still persists. You will find other issues in the Emacs bug tracker (such as https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45577) that follow the same general pattern, but where in contrast it is somewhat unclear if the issue is now solved or not, and therefore I did not cite such an issue.
Another example, an issue which I also filed and which was closed even though the issue still persists:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35005
It is true: I do not like how these issues were handled, especially that they are closed without actually solving them. The Emacs bug tracker is also not like the one on Github, you have to control it with dedicated email messages. In fact, I would have to look up how to even "reopen" an Emacs bug, it is not very clear to users, and this makes it especially frustrating if issues are closed without solution.
My impression from several years of filing Emacs issues is that issues are currently closed prematurely more often than was previously the case. Maybe this impression is amplified by the fact that Emacs has not even had a dedicated bug tracker for a long time, so issues were never really "closed", but the discussion simply petered out.
I used this specific example to illustrate the general point I was making, and I took an issue I filed myself because I know for certain that it still persists. You will find other issues in the Emacs bug tracker (such as https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45577) that follow the same general pattern, but where in contrast it is somewhat unclear if the issue is now solved or not, and therefore I did not cite such an issue.
Another example, an issue which I also filed and which was closed even though the issue still persists:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35005
It is true: I do not like how these issues were handled, especially that they are closed without actually solving them. The Emacs bug tracker is also not like the one on Github, you have to control it with dedicated email messages. In fact, I would have to look up how to even "reopen" an Emacs bug, it is not very clear to users, and this makes it especially frustrating if issues are closed without solution.
My impression from several years of filing Emacs issues is that issues are currently closed prematurely more often than was previously the case. Maybe this impression is amplified by the fact that Emacs has not even had a dedicated bug tracker for a long time, so issues were never really "closed", but the discussion simply petered out.
> In fact, I would have to look up how to even "reopen" an Emacs bug, it is not very clear to users, and this makes it especially frustrating if issues are closed without solution.
At the top of your bug report, it says:
At the top of your bug report, it says:
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21526 in the body.
You can then email your comments to 21526 AT debbugs.gnu.org in the normal way.The last message 6 years ago reads that the dev thinks the bug is fixed. Since then no-one complained. Do you know that the bug was falsely closed?
Isn’t it more an example of a bug submitter loosing interest in their bug?
Disclaimer: I did not read all 146 messages.
Disclaimer: I did not read all 146 messages.
The person you are replying to here (triska) is the original bug opener Markus Triska. A skim read of the thread, there's a long back-and-forth of Prolog parsing and formatting and interaction with Emacs movements, with many bugs raised in it. (It's more of a review-and-polish something than a single bug), and near the end Stefan Monnier says:
> "OK, let's turn things around, indeed: we revert to Stefan Bruda's indentation code, you're handed responsibility over that code, and I get to send you the bug reports about all the regressions this will introduce."
It's not clear if that's meant genuinely or frustratedly and sarcastically, but it's taken genuinely and Markus Triska replies: "This would be a good improvement in most respects I consider important, thank you! I will treat all issues you and others send to me with great care and attention, and work on correcting all regressions and issues I can. I have a lot of experience editing Prolog code with Emacs and can spot regressions quickly."
Followed by Stefan Monnier apparently not doing that, and fixing two (of many) issues raised and discussed. (Perhaps he considered it handed over and that the next action would be patches from Markus Triska?) Then 5 years later Lars (who wasn't involved in it?) closing the whole thing without reading it in detail, taking that as "whole thing fixed".
It's not too far from Zawinski's "Cascade of Attention Deficit Teenagers" model[1] of open source bug reporting - they go unread for years, then get closed with "if it's still a problem, make a new bug".
[1] https://web.archive.org/web/20210311012401/https://www.jwz.o...
> "OK, let's turn things around, indeed: we revert to Stefan Bruda's indentation code, you're handed responsibility over that code, and I get to send you the bug reports about all the regressions this will introduce."
It's not clear if that's meant genuinely or frustratedly and sarcastically, but it's taken genuinely and Markus Triska replies: "This would be a good improvement in most respects I consider important, thank you! I will treat all issues you and others send to me with great care and attention, and work on correcting all regressions and issues I can. I have a lot of experience editing Prolog code with Emacs and can spot regressions quickly."
Followed by Stefan Monnier apparently not doing that, and fixing two (of many) issues raised and discussed. (Perhaps he considered it handed over and that the next action would be patches from Markus Triska?) Then 5 years later Lars (who wasn't involved in it?) closing the whole thing without reading it in detail, taking that as "whole thing fixed".
It's not too far from Zawinski's "Cascade of Attention Deficit Teenagers" model[1] of open source bug reporting - they go unread for years, then get closed with "if it's still a problem, make a new bug".
[1] https://web.archive.org/web/20210311012401/https://www.jwz.o...
In general, I find too much emphasis is now on "closing" an issue as soon as possible. I understand that open issues can be a burden for maintainers.
That's the outcome of metrics-driven development. Getting to 0 open issues becomes the goal, and not the effect of having less buggy software.
I personally despise the GitHub "auto close" bots. Some issues take a very long time to even reproduce, and the constant nagging to close really encourages a culture of "if it can't be easily fixed, it doesn't matter" --- which nicely correlates with the state of a lot of new software today: all the basic stuff works, but there are lots of obscure, almost edge-case bugs.
That's the outcome of metrics-driven development. Getting to 0 open issues becomes the goal, and not the effect of having less buggy software.
I personally despise the GitHub "auto close" bots. Some issues take a very long time to even reproduce, and the constant nagging to close really encourages a culture of "if it can't be easily fixed, it doesn't matter" --- which nicely correlates with the state of a lot of new software today: all the basic stuff works, but there are lots of obscure, almost edge-case bugs.
From personal experience, bug reports are cheap to generate and very expensive to investigate. Additionally often it is the case that bug that no one paid any attention to eventually does go away on its own (the environment changes, the features is removed, a single commit ends up fixing multiple symptoms of the same problem, it was actually a user error, etc). Give the morale and dev time cost of a sprawling and low fidelity bug list I sympathize with aggressive bug triage, as I had to do the same myself. The real stuff will keep popping back in, and its better to have a real but incomplete list than a complete but mostly bogus one.
> bug reports are cheap to generate and very expensive to investigate
This is only true if you are talking about customer-service style exchanges. With bug trackers for open source projects there can be and often is quite a bit of effort put in narrowing down the bug by the reporter or other users and sometimes the fix ends up trivial and obvious to the developer after that. I agree with closing stale bugs that have had no interaction or quick way for the dev to check if the problem is fixed (after years, not weeks) - they can be reopened after all - but dismissing the effort by done by users to report bugs in the first place should not be your justification.
This is only true if you are talking about customer-service style exchanges. With bug trackers for open source projects there can be and often is quite a bit of effort put in narrowing down the bug by the reporter or other users and sometimes the fix ends up trivial and obvious to the developer after that. I agree with closing stale bugs that have had no interaction or quick way for the dev to check if the problem is fixed (after years, not weeks) - they can be reopened after all - but dismissing the effort by done by users to report bugs in the first place should not be your justification.
Yes, this is true, and as you say the more work is put into the bug report, the cheaper it is for the dev to investigate and the less likely it is that a bug report will be closed prematurely.
Yep. Closing issues consistently without resolving it is best way to cause your users to stop caring ever reporting new issues.
If you are looking to reduce number of issues, you are on the right track, because now not only you have closed a bunch of them without putting much work into it, but less people will be bothered to document and report their issues.
If you are looking to reduce number of issues, you are on the right track, because now not only you have closed a bunch of them without putting much work into it, but less people will be bothered to document and report their issues.
When you get more bug reports inbound than you can fix, you have bugs that will never be fixed. A good method of keeping your list of bugs to a manageable size is to simply declare that if a bug cannot be fixed in $timeframe, it should be closed as WONTFIX. Acknowledging that the bug or issue will remain because the projects resources have more important things do do, and it will never be dealt with unless some external factor is added (eg. a volunteer with skills prepared to prioritize the work). It also acknowledges that the longer bugs sit open, the less relevant they become. The feature they apply too may have changed beyond recognition, becomes deprecated, or the bug metastasizes and becomes a feature. It acknowledges that long open bugs are going to be reported multiple times anyway, and at least this way you get fresh, current reports rather than everyone dog piling on an ancient ticket that nobody wants to get near. You know the ones, where it has mutated over time that the initial report from 2008 bears no resemblance to what is currently being discussed, but everyone is cranky because it has been open 12 years and obviously the devs all suck... doesn't really inspire you to deal with it.
So you triage your bugs into roughly the same size chunks. You measure how many of the issues you deal with per month. You prioritize the issues. If you have more issues than your monthly velocity, you close the lowest priority WONTFIX because, well, they will not be fixed. But nobody does it this way for public projects, because then they have to deal with entitled people who want their priorities to supersede your priorities, and instead you end up with an eternally growing list of bug reports that are harder and harder to maintain. And try other approaches to make it maintainable, such as making it harder to report bugs.
So you triage your bugs into roughly the same size chunks. You measure how many of the issues you deal with per month. You prioritize the issues. If you have more issues than your monthly velocity, you close the lowest priority WONTFIX because, well, they will not be fixed. But nobody does it this way for public projects, because then they have to deal with entitled people who want their priorities to supersede your priorities, and instead you end up with an eternally growing list of bug reports that are harder and harder to maintain. And try other approaches to make it maintainable, such as making it harder to report bugs.
That is how most projects on GitHub are run. There is a bot that just closes issues after periods of inactivity. As if "not fixing the bug" can be considered as inactivity. Mostly in Kubernetes repositories I keep getting this "we are closing your issue, because we cba to solve it after 4 months" notifications.
I think people set up those bots without even starting to think through the consecuences of doing so. There is nothing more hostile to users than a program that misbehaves, searching and finding that the problem was reported in 2017 and closed afterwards with the excuse of no activity for the last 6 months (or any other equally ridiculously short amount of time).
Bugs won't fix themselves due to not talking about them. If you want to close a report, have a human check if the reported misbehavior does still happen, and close the bug if not (or if no way to reproduce was found). Projects seem to forget that issue reports are reports on defects of their code, so they should be the first interested in fixing whatever is wrong.
I'm the kind of user who takes the time and effort to report bugs (and I'd say that already puts me on a small % of users). But when I see these "closed because of no activity", I just say "F.U., really" and go away.
Bugs won't fix themselves due to not talking about them. If you want to close a report, have a human check if the reported misbehavior does still happen, and close the bug if not (or if no way to reproduce was found). Projects seem to forget that issue reports are reports on defects of their code, so they should be the first interested in fixing whatever is wrong.
I'm the kind of user who takes the time and effort to report bugs (and I'd say that already puts me on a small % of users). But when I see these "closed because of no activity", I just say "F.U., really" and go away.
I think this is a filter that allows the issues submitted by other big companies to get the attention they deserve while at the same time maintaining the facade of operating as an open source project
This is how some projects on GitHub are run. Any bots like that need to be set up by the maintainers.
The word “closed” doesn’t mean problem solved. It actually can legitimately mean the problem is ignored: we closed the case because nobody cared anymore.
That shouldn’t happen because people will continue to report the bug and open duplicate issues. Instead, it should be tagged with something like “won’t fix”.
Won’t fix can be such a trap as well because it doesn’t make the problem go away but signals to the users “we don’t care so go away”. The issue that pushed me off of android was tagged as wontfix, and doesn’t seem to be solved despite a decade of users complaining android is literally costing them money: https://issuetracker.google.com/issues/36907469?pli=1
If someone reopens the bug or opens another bug, that is an indication that someone still cares.
WONTFIX means the developer won't fix the bug. If you still care about it, fix it yourself or pay someone to do it for you; you're not entitled to unpaid support from 3rd parties, even if you ask nicely.
Please look at the context of my comment. ummonk suggested that developers should tag closed bugs with wontfix, even if they were only closed because no one cared (rather than because they don't want to fix it).
The affected users didn't bother to check if the issue was solved for five years. I think it is fine to close it
Or they gave up checking and moved on, but the bug is still affecting others (who do not know how or don't bother to report) - some of whom may also just move on.
I disagree. The affected users completed their responsibility of filing a ticket, and if triage is done correctly, they should rely to the issue status or comments for updates. The alternative of having issue creators regularly ping the assignee for status updates via comments seems unproductive for both the creator and assignee.
It's super sad considering the new stream of users of all levels, but energy is spent at the higher layers (emacs config, org tricks) rather than core..
There's a new elisp JIT in emacs 28
https://emacsconf.org/2020/talks/38/
There's a new portable undump in emacs 27
https://www.masteringemacs.org/article/whats-new-in-emacs-27...
a couple of examples of very core features off the top of my head
https://emacsconf.org/2020/talks/38/
There's a new portable undump in emacs 27
https://www.masteringemacs.org/article/whats-new-in-emacs-27...
a couple of examples of very core features off the top of my head
I had no idea about the new JIT but in any case it would be nice if more manpower was allocated on fixing bugs I guess.
As active as you are in the Emacs community, you ought to know that there is a steady stream of commits to "core." Anyway, if that's not enough for you, maybe you could allocate some of your own manpower to fixing those bugs.
i'm not able to commit enough neurons for emacs core right now otherwise you'd see me everywhere
This is probably because it is relatively easy to add more elisp flourishes, another seven major modes for editing JavaScript, much harder to actually improve the core.
As with any large system, improvements to core also risk compromising large, popular packages.
I wonder how remacs guys are doing now
They're no longer taking PRs, development has moved over to emacs-ng with a different perspective on how to improve Emacs.
I agree with you, but also having maintained a fairly large corporate OSS project, our backlog has gotten unsustainable. We've thrown more bodies at the problem, and are trying to deputize more of the community, but I really don't know how to manage/organize super old issues that may be legitimate, but typically aren't very searchable for people with similar problems (which often aren't obviously similar).
>However, filing issues, especially making them reproducible, can also be a burden to users, and users will stop filing issues if too many of them are closed unilaterally without actually correcting the root cause.
Fantastic! Two birds with one stone!
Fantastic! Two birds with one stone!
Your comment feels like you’ve never worked on an open source project that gets issues.
This has always been my problem with emacs. The basic interpreter and interface design is phenomenal, but it is so bogged down and buggy it is frustrating to actually push it to the limits of capability. I wish the devs would just drop support for stuff that can be maintained just as well as a plugin.
Time for a neomacs?
146 messages in that bug thread. Wow.
> I'm going to go ahead and guess that the problems discussed
were fixed, and I'm closing this bug report.
If only there was a way to find out, instead of guessing.
I’m going to start trying this at work. I wonder how it will be received?
If only there was a way to find out, instead of guessing.
I’m going to start trying this at work. I wonder how it will be received?
> I’m going to start trying this at work. I wonder how it will be received?
You’ve never done that at work? In every company I’ve worked for, nobody would bat an eyelid at dropping an issue that hasn’t been touched for more than a year
You’ve never done that at work? In every company I’ve worked for, nobody would bat an eyelid at dropping an issue that hasn’t been touched for more than a year
That's how we got that stupid bot on GitHub that constantly says "comment here or I'll close this". From time to time I have to waste my time that way. I wonder if this means maintainers want us all day bumping bugs?
I have this “ready with tests” PR for almost a year now, and every time I get a notification it’s either the bot or someone who really wants the PR to be merged bumping it up for me. I don’t even care so much about it any more…
[deleted]
Without testing to see if it is actually fixed? Never. Though, to be honest, it is QA who is testing it, not us developers. But, only QA can close a ticket and no way would they close it without being 100% sure it is fixed.
> Though, to be honest, it is QA who is testing it, not us developers.
Developers absolutely should be testing for the issues they know about. QA is there to look for unknown issues.
Any company that depends on QA for testing and doesn’t make devs to it is miserable to work for (both as a dev and a QA).
Developers absolutely should be testing for the issues they know about. QA is there to look for unknown issues.
Any company that depends on QA for testing and doesn’t make devs to it is miserable to work for (both as a dev and a QA).
Not where I work. QA are the ones who first look at all reported issues. They see if they can replicate the reported issue. If they can’t they contact the reporter and try to figure out why they can’t replicate it. Once they can replicate it they write up the ticket with replication steps and add it to the backlog to be assigned out in a sprint. They attend all meetings and explain the issues. Once the developer thinks they have fixed the issue they send it back to QA to verify it is fixed. Then QA reaches out to the person that reported the issue to tell the about the resolution.
Have you ever sent the issue back to QA as fixed, and then they do their reproducer and it’s not fixed? That’s roughly the scenario we’re asking you to have empathy toward.
That’s not testing, that’s triage. If you don’t bother writing unit tests yourself as a developer when you fix the tickets, then that’s the problem I’m referring to.
For QA to test tell if it's fixed, they must have a test case. If there is a test case here, the devs wouldn't have to guess?
The bug reproduction steps (along with expected vs actual behaviour) are in the opening comment of the bug report, so they really should not have had to guess.
See my response to kortilla above.
QA is not your test suite. Test your own code, submit working code, let QA try to break it.
Dont just push code and expect others to point out your flaws. Take some responsibility.
Dont just push code and expect others to point out your flaws. Take some responsibility.
See my response to kortilla above.
In most places I’ve worked, having a bug untouched for even a fairly small fraction of that time would result in someone getting, at a minimum, corrective counseling.
Corrective counseling for a single bug? I take it you’ve never worked in a US software company.
Yeah... This actually seems standard for old backlogs.
Were all problems fixed? Almost certainly not. Many will have become overcome by events, though. The ones that are still pertinent will reopen.
Such that anytime I see a large percentage of bugs closed like this, this reflects more on working in the ticketing system than it does on fixing the problem it is managing.
Were all problems fixed? Almost certainly not. Many will have become overcome by events, though. The ones that are still pertinent will reopen.
Such that anytime I see a large percentage of bugs closed like this, this reflects more on working in the ticketing system than it does on fixing the problem it is managing.
I’m going to guess that when you close issues that are years old, a fraction of them will reappear as enough people have devised workarounds for the issues and they will become the de facto fix.
Everybody does this, it's the normal behavior with enterprise bugs.
They report something. You badger them for six weeks to collect enough information to reproduce it. You fix the problem and slate it into a release and make it available. They don't take the release for another seven months.
They report something. You badger them for six weeks to collect enough information to reproduce it. You fix the problem and slate it into a release and make it available. They don't take the release for another seven months.
I’ve done this at work many times, it’s the only way I’ve found to keep a big project back log under control… if people care enough they can reopen
When I worked for Facebook, the had a bugtracker bot that closes open issues after 6? months of no activity. It's sort of nice, but also terrible.
when your text editor has a better bug reporting feature than its text editing feature, maybe it's time you move onto something else
If you work for a corporation and feel overwhelmed try what the emacs people did, example for email: 1) select everything in your inbox, 2) mark as read, 3) archive. For bugs it would be unassign everything from yourself, or just close them without fixing.
I've done this several times and it's magical how you end up losing almost nothing important in the end. I think it works because if something is important enough you'll either remember it yourself or it will be communicated to you again, perhaps even via a "higher priority channel" such as the management chain.
And if you think I'm being extreme then yes, maybe, but maybe you haven't yet drowned in the never ending stream of problems for a long time.
I've done this several times and it's magical how you end up losing almost nothing important in the end. I think it works because if something is important enough you'll either remember it yourself or it will be communicated to you again, perhaps even via a "higher priority channel" such as the management chain.
And if you think I'm being extreme then yes, maybe, but maybe you haven't yet drowned in the never ending stream of problems for a long time.
When doing this email trick I'd often broadcast the fact as I was "declaring email bankruptcy" to let others know I did this and may have missed their email.
I've also lead many mass bug closures. Most stale bugs just need a ping or a friendly closure message. The cost to reverse a wrongly closed bug from a bug cleanup sweep is zero, and in the off chance it ignites interest in some other party still paying attention it at least signals intent and starts a conversation.
I've also lead many mass bug closures. Most stale bugs just need a ping or a friendly closure message. The cost to reverse a wrongly closed bug from a bug cleanup sweep is zero, and in the off chance it ignites interest in some other party still paying attention it at least signals intent and starts a conversation.
> The cost to reverse a wrongly closed bug from a bug cleanup sweep is zero
Except when maintainers decide to lock the bugs automatically because Reasons.
Nothing screams contributor hostility as much as that.
Except when maintainers decide to lock the bugs automatically because Reasons.
Nothing screams contributor hostility as much as that.
This is definitely a real phenomenon, there is a lot of "work" that if ignored long enough turns out didn't need to be done at all. Lots of things get done which don't need to, knowing which is which is a really valuable skill.
There are crappy workarounds for many bugs. The cost is just moved from the mantainer to the user. After a while the bug becomes lore.
Sometimes it is more a matter of getting most of the work done, without it mattering if some gets missed. Ignoring all reported bugs might be unsustainable because eventually all your customers would get fed up and leave, but it is unlikely that any particular bug would be the breaking point between the company succeeding or going under.
At my job I have learned which people ask for things that they aren't really serious about. Only so many times I am willing to reorganize my work to install some "urgently" needed software or system configuration changes, only to later observe that they were never used.
Now when I get requests from those people, they go immediately to the back burner. If I hear nothing more, they get closed; if I get followups then maybe it is something they need after all.
It's easy for people to ask for others to do things. But many people are scatterbrained and can't prioritize, and can't see beyond their own immediate needs and how their requests might impact other work. Rather than try to demand some realistic sense of priority for these requests, this approach lets the urgent stuff bubble up naturally and the rest of the chaff sink to the bottom.
Now when I get requests from those people, they go immediately to the back burner. If I hear nothing more, they get closed; if I get followups then maybe it is something they need after all.
It's easy for people to ask for others to do things. But many people are scatterbrained and can't prioritize, and can't see beyond their own immediate needs and how their requests might impact other work. Rather than try to demand some realistic sense of priority for these requests, this approach lets the urgent stuff bubble up naturally and the rest of the chaff sink to the bottom.
> It's easy for people to ask for others to do things. But many people are scatterbrained and can't prioritize, and can't see beyond their own immediate needs and how their requests might impact other work.
But, should they even care? Maybe they think it's not their job?
What I mean is, there seem to be two archetypes of ways to ask someone else for something. For lack of better terms, I'll call them "market approach" and "social approach".
"Social approach" is when you try to predict how costly your request will be to the other person, and only ask them if the importance is clearly much greater than the cost. You then expect the other person to feel compelled to prioritize your request, as they know you wouldn't be asking if it wasn't very important.
"Market approach" is when you don't give any thought about the cost to other party - you just make your request, and expect them to tell you whether they'll do it, how long will it take, and what they expect in return. You then negotiate the scope of the request and the "price" until both sides are satisfied, or the request is rejected.
I don't know which one is better. But I think we're living the worst case: everyone operates at a different point between these two idealized approaches. So, in your example, you're taking the "social" perspective - you treat requests as high priority ("they wouldn't have asked if it wasn't important") and get annoyed when your hard work isn't used. Meanwhile, those people may be operating closer to the "market" perspective - perhaps they expected you to push back on their request if it's disruptive to you, and were willing to negotiate (they knew it wasn't that important, but they didn't expect you to assume it was).
But, should they even care? Maybe they think it's not their job?
What I mean is, there seem to be two archetypes of ways to ask someone else for something. For lack of better terms, I'll call them "market approach" and "social approach".
"Social approach" is when you try to predict how costly your request will be to the other person, and only ask them if the importance is clearly much greater than the cost. You then expect the other person to feel compelled to prioritize your request, as they know you wouldn't be asking if it wasn't very important.
"Market approach" is when you don't give any thought about the cost to other party - you just make your request, and expect them to tell you whether they'll do it, how long will it take, and what they expect in return. You then negotiate the scope of the request and the "price" until both sides are satisfied, or the request is rejected.
I don't know which one is better. But I think we're living the worst case: everyone operates at a different point between these two idealized approaches. So, in your example, you're taking the "social" perspective - you treat requests as high priority ("they wouldn't have asked if it wasn't important") and get annoyed when your hard work isn't used. Meanwhile, those people may be operating closer to the "market" perspective - perhaps they expected you to push back on their request if it's disruptive to you, and were willing to negotiate (they knew it wasn't that important, but they didn't expect you to assume it was).
I like this comment too but in many cases the requesting party has almost no relationship to the receiving party. The requester is almost always in a buyers market (filing an issue is cheap) and the receiver is almost always social (working closely with others to resolve issues).
This model does explain the different sides, but the problem remains.
So it seems that the problem with the requester’s market approach is that there is no mechanism for setting value. So how do we solve that?
This model does explain the different sides, but the problem remains.
So it seems that the problem with the requester’s market approach is that there is no mechanism for setting value. So how do we solve that?
> but in many cases the requesting party has almost no relationship to the receiving party
That is a common occurrence - which makes it dangerous for either side to make assumptions about the other.
So the more I think about it, the more I feel that it's the "market approach" that's better-suited for work requests and issue reports, when the two sides don't have a preexisting personal relationship. "Market approach" is assumption-minimizing, and thus also mistake-minimizing.
On a side note, I wonder if that's what "rejection therapy" and assertiveness are both about: they're trying to teach you to ask people more (instead of assuming they'll say no), not take rejection personally, and to be ready to just say no to other people. Taken like this, they sound like attempts to correct people into using "market approach" where they tend to use "social approach".
> So it seems that the problem with the requester’s market approach is that there is no mechanism for setting value.
I think this is not a problem at all. That's why I called it "market approach" - the market is the tool that's used to determine value.
That is a common occurrence - which makes it dangerous for either side to make assumptions about the other.
So the more I think about it, the more I feel that it's the "market approach" that's better-suited for work requests and issue reports, when the two sides don't have a preexisting personal relationship. "Market approach" is assumption-minimizing, and thus also mistake-minimizing.
On a side note, I wonder if that's what "rejection therapy" and assertiveness are both about: they're trying to teach you to ask people more (instead of assuming they'll say no), not take rejection personally, and to be ready to just say no to other people. Taken like this, they sound like attempts to correct people into using "market approach" where they tend to use "social approach".
> So it seems that the problem with the requester’s market approach is that there is no mechanism for setting value.
I think this is not a problem at all. That's why I called it "market approach" - the market is the tool that's used to determine value.
I agree with the sibling comment, your comment transmits a great insight that would make for a great longer form read. Deep down, this is another instance of the problem of human expectations and how important it is to handle them correctly for sane interactions with other peers at work.
> "Market approach" is when you don't give any thought about the cost to other party - you just make your request, and expect them to tell you whether they'll do it, how long will it take, and what they expect in return. You then negotiate the scope of the request and the "price" until both sides are satisfied, or the request is rejected.
Note (for your forthcoming tweet storm, apparently) that just these evaluation steps could be pretty time-intensive for the other party in the first place.
Note (for your forthcoming tweet storm, apparently) that just these evaluation steps could be pretty time-intensive for the other party in the first place.
If they are time intensive for other party, they would be impossible for the one asking.
This is a great insight and deserves to be turned into a more pretentious blog post that goes viral on VC Twitter.
I should get better at recognizing which of my partners are on the social strategy and who prefers a more market-based one. Probably all of us should learn this skill.
I should get better at recognizing which of my partners are on the social strategy and who prefers a more market-based one. Probably all of us should learn this skill.
I almost agreed with you until you used the pejorative “scatterbrained”. I think the explanation is “asymmetry”.
It’s simply easier to make a request, than it is to resolve it. The cost of filing an issue is greater than the cost of resolving it.
This is why schemes like “you can only file your top 3 issues” make sense. Forcing the end user to prioritise their top issues - and to manage the ones that don’t make the cut - distributes the triage work more fairly.
We have a job to do too and it’s a waste of developers time to force us to guess what’s important to an end user. That’s their job.
It’s simply easier to make a request, than it is to resolve it. The cost of filing an issue is greater than the cost of resolving it.
This is why schemes like “you can only file your top 3 issues” make sense. Forcing the end user to prioritise their top issues - and to manage the ones that don’t make the cut - distributes the triage work more fairly.
We have a job to do too and it’s a waste of developers time to force us to guess what’s important to an end user. That’s their job.
The people I'm thinking about are actually scatterbrained. They read about something new -- squirrel!! -- ask for it and then they forget they asked. When the requests are completed they never use what they asked for.
The social vs. market perspectives are interesting though, I had not thought about framing requests in this way, and I'm going to try to keep that in mind in the future.
The social vs. market perspectives are interesting though, I had not thought about framing requests in this way, and I'm going to try to keep that in mind in the future.
When I was young I hated that my manager asked me to email many times if it was important.
Nowadays I understand … it’s the a way to keep sane and to see what matters. Mainly in companies that have been around for decades with multiple products and many many people..
Nowadays I understand … it’s the a way to keep sane and to see what matters. Mainly in companies that have been around for decades with multiple products and many many people..
I've been in a place where lots of things were flaky and sub-optimal, and leadership could not prioritize, because only P0 CRITICAL was ever actually addressed, lots of dumb stuff had to be marked P0 CRITICAL to have any chance of consideration, and lots of little easy bugs reported from reasonable developers were never fixed.
So, this doesn't always work, it can just be a way to kick the can around, and end up in the same place but with lots of extra junk flying by.
So, this doesn't always work, it can just be a way to kick the can around, and end up in the same place but with lots of extra junk flying by.
For about three years I say openly that if an email is important, my manager will read it out to me. Seems to work and in that time keeping ~100 people somewhat aligned became my core responsibility.
i just took this comment as inspiration to close all the open bugs in our jira instance that hadn't been updated or commented on in the last three years. spot checking a few of them, they were all either duplicates of other bugs that had already been fixed, or no longer relevant.
it felt pretty good.
it felt pretty good.
Wow. That explains a lot about our lab HPC "facilitator's" attitude towards us haha.
+1 - subtly, if it's important someone will re-file or re-open it.
Yeah and I agree especially for poorly documented issues, unclear demands on your time, etc.
But as someone with a long QA experience, sometimes I'm so disappointed in the 'no one bothered me, it must be bothering no one, close'. What about the time and effort of the person who described a defect in your system? Don't you want people giving you clear, researched bug reports? When you close their issues, although there CLEARLY is a problem and the ball is CLEARLY in your (sw dev) team, I feel like you're saying 'don't give me precise, actionable bugs'. That's what I'm hearing anyway.
And soon enough you get the eternal dev complaint about how 'no one fills tickets properly' and the 'no one opens issues anymore although they face clear annoying bugs' with heavy faulpelz connotations... Well you reap what you sow.
I'm not saying the project has infinite resources and that you should fix all issues all the time... I actually understand the real world tradeoffs. But put them on a special list, like knowledge database, known-bugs, not 'closed until some annoying piece-of-work busybody complains', and try earnestly to fix one once in a while, I even had a principle when I was team lead, to correct at least 5 more-than-2-years-old issues (or add a 'red' test for that bug). After all with tech turnover, those often make great onramping tickets.
And I can testify to the sheer joy of having one of your 'low priority' issues fixed, even 2-3 years later. 'hey I know it's been a long time, and we're not sure it's still annoying to you, but anyway we managed to reproduce on the latest version and we put a fix in place, let us know if you want a nightly to double-check or wait until next release'. Even though it doesn't show on SLAs, I do put in a word when renewal time comes around (even more now that I have a small bit of clout).
But as someone with a long QA experience, sometimes I'm so disappointed in the 'no one bothered me, it must be bothering no one, close'. What about the time and effort of the person who described a defect in your system? Don't you want people giving you clear, researched bug reports? When you close their issues, although there CLEARLY is a problem and the ball is CLEARLY in your (sw dev) team, I feel like you're saying 'don't give me precise, actionable bugs'. That's what I'm hearing anyway.
And soon enough you get the eternal dev complaint about how 'no one fills tickets properly' and the 'no one opens issues anymore although they face clear annoying bugs' with heavy faulpelz connotations... Well you reap what you sow.
I'm not saying the project has infinite resources and that you should fix all issues all the time... I actually understand the real world tradeoffs. But put them on a special list, like knowledge database, known-bugs, not 'closed until some annoying piece-of-work busybody complains', and try earnestly to fix one once in a while, I even had a principle when I was team lead, to correct at least 5 more-than-2-years-old issues (or add a 'red' test for that bug). After all with tech turnover, those often make great onramping tickets.
And I can testify to the sheer joy of having one of your 'low priority' issues fixed, even 2-3 years later. 'hey I know it's been a long time, and we're not sure it's still annoying to you, but anyway we managed to reproduce on the latest version and we put a fix in place, let us know if you want a nightly to double-check or wait until next release'. Even though it doesn't show on SLAs, I do put in a word when renewal time comes around (even more now that I have a small bit of clout).
And the worst part is that for anything else than clearly laid out bugs/issues, I apply GP's described strategy (if it is important, it'll come back or I'll remember), especially as a protection against burnout. I have taught myself to stop worrying missing an email or not be on top of everyfuckingthing. Yeah I'll come around to look and will say 'must be redone, sorry' and there's waste. It's bad. But you can't do everything and when the external environment doesnt you adjust to your work capacity by itself, I've decided to let not-so-critical things slide a bit. If/when there's a complaint, either I'll resend the email about not having the time to follow subject X or my manager will... It's OK.
>+1 - subtly, if it's important someone will re-file or re-open it.
With all due respect, this absolutely is not the only outcome. I'm going through this right now with UniFi and Ubiquiti, which has been a raging development dumpster fire for years now though the rot has only really started to become critical and more generally obvious the last year or two. UniFi is full of very important bugs, issues, and missing or badly implemented core functionality. But, like many many others, after devoting a lot of time to detailed bug reports and figuring out how to make it reproducible and extensive work helping identify how to meet standards that all got closed/ignored or even actively got worse?
I simply don't give a flying fuck any longer. I'm not "re-filing" (of course, they've dumped even their minimal mediocre old feature/bug tracker anyway with no replacement, but I don't make new threads either). I mostly don't bother anymore with reporting anything UniFi at all. Instead I've been steadily migrating away entirely. For me, UniFi is now in a completely subservient role, still doing a certain amount of switching and WiFi but with 100% of core network functions, routing/gateway coverage etc moved to OPNsense. As the time comes to get new gear anyway for WiFi 6E/7 and more multigig switching that'll be the end of it for my ~100 pieces of kit.
Of course companies/projects are free not to care, and depending on what sort of goal a project has or what sort of lock-in/stickiness and core revenue areas a business has it may indeed not matter if there is an exodus of small/older users/customers. But it shouldn't be assumed in every instance that "if this is really important someone will poke us again" because everyone only has so much time themselves to poke you, and if word gets around that it's pointless to even try than that will be the last you hear from them until they're gone entirely. IMO, the true terror for many business/projects shouldn't be criticism, it's silence. When people simply don't even care enough to even invest the time to get mad anymore.
With all due respect, this absolutely is not the only outcome. I'm going through this right now with UniFi and Ubiquiti, which has been a raging development dumpster fire for years now though the rot has only really started to become critical and more generally obvious the last year or two. UniFi is full of very important bugs, issues, and missing or badly implemented core functionality. But, like many many others, after devoting a lot of time to detailed bug reports and figuring out how to make it reproducible and extensive work helping identify how to meet standards that all got closed/ignored or even actively got worse?
I simply don't give a flying fuck any longer. I'm not "re-filing" (of course, they've dumped even their minimal mediocre old feature/bug tracker anyway with no replacement, but I don't make new threads either). I mostly don't bother anymore with reporting anything UniFi at all. Instead I've been steadily migrating away entirely. For me, UniFi is now in a completely subservient role, still doing a certain amount of switching and WiFi but with 100% of core network functions, routing/gateway coverage etc moved to OPNsense. As the time comes to get new gear anyway for WiFi 6E/7 and more multigig switching that'll be the end of it for my ~100 pieces of kit.
Of course companies/projects are free not to care, and depending on what sort of goal a project has or what sort of lock-in/stickiness and core revenue areas a business has it may indeed not matter if there is an exodus of small/older users/customers. But it shouldn't be assumed in every instance that "if this is really important someone will poke us again" because everyone only has so much time themselves to poke you, and if word gets around that it's pointless to even try than that will be the last you hear from them until they're gone entirely. IMO, the true terror for many business/projects shouldn't be criticism, it's silence. When people simply don't even care enough to even invest the time to get mad anymore.
The most fascinating thing to me about this blog post is that here we have a guy in his fifties who got insanely rich by working very hard (no doubt) and then selling a major stock broker platform (it is briefly mentioned as "in banking") - and what does he choose to do now with spare time and more money than anyone could use? He is maintaining Emacs. For fun. This is why open source will grow. It feels meaningful to contribute. He could sail, travel, invest, buy expensive stuff, etc. But Emacs hacking it is. Makes me happy to see.
Emacs hackers can be extremely obsessive, and that's a great thing! I know one who even named their dog Emacs.
Dear HNers, would you back a crowdfunding campaign for maintenance of a particular open source software you rely on, which would have goals like "for the next year, 50% of newly reported defects are solved in under a month, 90% in under 3 months"?
(Surely there's a lot more details to specify to make this a reliable bargain.)
(Surely there's a lot more details to specify to make this a reliable bargain.)
Yes. There's open source software I love and use daily.
Currently for me its neovim. What the maintainers and contributors have done is exceptional. They've breathed new life into vim (through neovim) and pushed forward broader (neo)vim development.
They did (and do) a great job of setting up their goals and achieving them. Most notably with their recent .5 release which adds support for first class Lua, native LSP, native Treesitter support, and more.
> 50% of newly reported defects are solved in under a month, 90% in under 3 months
I don't need a commitment like this. It would add unnecessary pressure to complete something that may need more time. I feel like this would follow Goodhart's law[0] and end up leading to overall worse development progress.
[0]https://en.wikipedia.org/wiki/Goodhart%27s_law
Currently for me its neovim. What the maintainers and contributors have done is exceptional. They've breathed new life into vim (through neovim) and pushed forward broader (neo)vim development.
They did (and do) a great job of setting up their goals and achieving them. Most notably with their recent .5 release which adds support for first class Lua, native LSP, native Treesitter support, and more.
> 50% of newly reported defects are solved in under a month, 90% in under 3 months
I don't need a commitment like this. It would add unnecessary pressure to complete something that may need more time. I feel like this would follow Goodhart's law[0] and end up leading to overall worse development progress.
[0]https://en.wikipedia.org/wiki/Goodhart%27s_law
Yes, if it was one of those projects that can be "finished" and that can set a clear goal for that.
What did you have in mind to achieve that? It sounds wonderful!
"Work, listen, negotiate".
Prerequisites:
1. Maintainer has expertise about the project.
2. Connection with users and knowledge of their needs and of their willingness to pay.
3. Ability to estimate project's demands in terms of effort and expenditure, given a set of objectives. (This is just a part of an expertise really; often overlooked, but crucial here.)
Step 1: Based on the user needs, the estimates, and maintainer's other realistic earning options, calculate financial goals.
Step 2: Run the funding campaign.
Step 3: Refine the prerequisites, repeat the steps.
All abstract and hypothetical here of course.
Prerequisites:
1. Maintainer has expertise about the project.
2. Connection with users and knowledge of their needs and of their willingness to pay.
3. Ability to estimate project's demands in terms of effort and expenditure, given a set of objectives. (This is just a part of an expertise really; often overlooked, but crucial here.)
Step 1: Based on the user needs, the estimates, and maintainer's other realistic earning options, calculate financial goals.
Step 2: Run the funding campaign.
Step 3: Refine the prerequisites, repeat the steps.
All abstract and hypothetical here of course.
FTA : "I think you can pretty much pinpoint the date I didn’t have to work any more after the startup I was a co-owner of was bought and found myself with a lot of free time on my hands? Kinda? So I’ve been basically working full time on Emacs bug fixing (and triage) for a couple years (with some holidays at random) instead."
I would love to be in such a situation... Unfortunately, I don't have a start up to sell so I'll be a slave all my life and won't have the opportunity to work full time for a non profit project that I love. Dies irae.
I would love to be in such a situation... Unfortunately, I don't have a start up to sell so I'll be a slave all my life and won't have the opportunity to work full time for a non profit project that I love. Dies irae.
Not having a startup to sell doesn't mean you have to be a slave all your life. You could find a job you enjoy, or save up some money and retire. Look up "financial independence/retiring early" - it's not suitable for everyone, but if you're here, you probably qualify :)
> Just a reminder: Working on the development version of Emacs is easy on most operating systems.
With Nix, it's amazing to be able to just run (on macOS/Linux)
With Nix, it's amazing to be able to just run (on macOS/Linux)
nix develop nixpkgs#emacs
Thanks for the heads-up! Any idea why it says that this build environment is "nearly identical"?
https://nixos.org/manual/nix/unstable/command-ref/new-cli/ni...
How do we support you? Big emacs fan here.
This is amazing bug-fixing work Lars!
Here are my thoughts on what is needed for emacs to have a real future in the 21st century:
1. We must create a strong community of highly-skilled programmers who use Emacs for their work, for it is out of this community that emacs contributors, developers and maintainers will come.
2. Therefore Emacs must be first-class for day-to-day programming work.
3. This means LSP. I think it means taking some lessons from VSCode: i.e. not being a traditional IDE, but having first-class LSP functionality in all common languages.
4. It probably also means being able to follow VSCode's lead in remote container-based development.
5. The emacs development community needs to become less of a weird argumentative place. The points above will help because it will have more representation from programming traditions other than lisp.
6. Development should move to something like Github/GitLab, i.e. with PRs, not emailed patches.
7. The memory of Stallman and the FSF should not be forgotten but their opinions should not be given any special weight. E.g. on using a non-free platform like Github/GitLab, and on supporting MacOS.
8. Things like org-mode and gnus are a distraction: emacs core should focus on programming modes. If it would help focus emacs development on programming modes to severely trim the core, then let's do it, and move these things into packages. org-mode is very popular but too unfocused to be in core. gnus is great but the next generation aren't going to use it for their email.
9. We should kill the idea that it's desirable for projects to become part of core. It's not desirable: it makes it extremely hard for people to contribute to those packages due to FSF papers and email/bug tracker workflows that are totally alien to contributors and not as good as more modern workflows, and it makes the emacs bug tracker unfocused.
10. We should not think about making emacs popular and instead just focus on making it excellent for programming.
Here are my thoughts on what is needed for emacs to have a real future in the 21st century:
1. We must create a strong community of highly-skilled programmers who use Emacs for their work, for it is out of this community that emacs contributors, developers and maintainers will come.
2. Therefore Emacs must be first-class for day-to-day programming work.
3. This means LSP. I think it means taking some lessons from VSCode: i.e. not being a traditional IDE, but having first-class LSP functionality in all common languages.
4. It probably also means being able to follow VSCode's lead in remote container-based development.
5. The emacs development community needs to become less of a weird argumentative place. The points above will help because it will have more representation from programming traditions other than lisp.
6. Development should move to something like Github/GitLab, i.e. with PRs, not emailed patches.
7. The memory of Stallman and the FSF should not be forgotten but their opinions should not be given any special weight. E.g. on using a non-free platform like Github/GitLab, and on supporting MacOS.
8. Things like org-mode and gnus are a distraction: emacs core should focus on programming modes. If it would help focus emacs development on programming modes to severely trim the core, then let's do it, and move these things into packages. org-mode is very popular but too unfocused to be in core. gnus is great but the next generation aren't going to use it for their email.
9. We should kill the idea that it's desirable for projects to become part of core. It's not desirable: it makes it extremely hard for people to contribute to those packages due to FSF papers and email/bug tracker workflows that are totally alien to contributors and not as good as more modern workflows, and it makes the emacs bug tracker unfocused.
10. We should not think about making emacs popular and instead just focus on making it excellent for programming.
I think that 1 and 2 are already there. I am not sure about 8 and 9. In addition to programmers, Emacs has amazing communities of researchers, writers, note keepers, cooks, sysadmins, all kinds of remote workers. It is nice to have direct support for all kinds of things beyond LSP (which is useful and supported).
We don't need LSP to be "supported"; it needs to be as good as e.g. VSCode. Seriously; that is what is required if Emacs is to maintain a large enough community of skilled programmers to maintain it in this century.
I get it, the diverse userbase of people from all walks of life using this crazy lisp-based editor from the early 80s is cool. But it will fizzle out if it is not loved and used by the next generation of professional programmers (well, this generation of under-40 professional programmers).
I get it, the diverse userbase of people from all walks of life using this crazy lisp-based editor from the early 80s is cool. But it will fizzle out if it is not loved and used by the next generation of professional programmers (well, this generation of under-40 professional programmers).
I agree with some of your points and have to disagree with others.
> Things like org-mode and gnus are a distraction: emacs core should focus on programming modes
Emacs can and has been doing both of these for a long time. Emacs is unlike anything else out there because it empowers the user, who does not need to be programmer. The popular Helm package is maintained by a mountain climbing trainer for almost a decade. We want more of such users. We want more casual users who, during their Emacs journey will get encouraged to start tinkering and then become programmers.
> on using a non-free platform like Github/GitLab, and on supporting MacOS.
MacOS is already supported, as I understand. Github/Gitlab advice zounds nice, but we have to zoom out on this. Emacs is older than most programmers out there. It is older than git and bazaar. Using Github/Gitlab sounds nice, but it locks you in. Besides, Email is ubiquitous. If you have a network connected device, it can probably send/receive email.
> Things like org-mode and gnus are a distraction: emacs core should focus on programming modes
Emacs can and has been doing both of these for a long time. Emacs is unlike anything else out there because it empowers the user, who does not need to be programmer. The popular Helm package is maintained by a mountain climbing trainer for almost a decade. We want more of such users. We want more casual users who, during their Emacs journey will get encouraged to start tinkering and then become programmers.
> on using a non-free platform like Github/GitLab, and on supporting MacOS.
MacOS is already supported, as I understand. Github/Gitlab advice zounds nice, but we have to zoom out on this. Emacs is older than most programmers out there. It is older than git and bazaar. Using Github/Gitlab sounds nice, but it locks you in. Besides, Email is ubiquitous. If you have a network connected device, it can probably send/receive email.
Thanks, fair enough.
> We want more of such users. We want more casual users who, during their Emacs journey will get encouraged to start tinkering and then become programmers.
Yeah, I do see that view. I just wonder whether we need to make some tough decisions in order for emacs to survive. Specifically: although emacs is wonderful for tinkerers and non-programmers, what it actually is is a lisp execution environment powering a text editor. When described like that, it's pretty clearly a tool for programmers and expert / adventurous ones at that. I think it might be best to embrace that: it's great for others to join the ride but, sadly, not the raison d'etre of emacs. Better to focus on making it very, very, good within a well-scoped area.
> MacOS is already supported, as I understand.
Stallman et al. have refused to accept into core various patches that are required to make Emacs great on MacOS. For example, native MacOS SVG rendering software is not supported. This is why the Mitsuharu emacs-mac fork [0] exists and is so loved. The reason they've refused to accept those patches is because their inner 14-year olds don't like "companies that make money" and so don't want to accept patches that give "for profit software" an advantage over "free software".
> Github/Gitlab advice zounds nice, but we have to zoom out on this. Using Github/Gitlab sounds nice, but it locks you in. Besides, Email is ubiquitous.
I guess we have to agree to disagree there. My claim is simply that PRs are a technological advance over email review. The fact that Emacs uses non-PR based development makes me not contribute to them. Emailing patches is absurd: a patch is a thing that exists in a code lineage; it has a parent; it's not an entity in its own right. There are many things that are ubiquitous but not the best choice!
[0] https://bitbucket.org/mituharu/emacs-mac/src
> We want more of such users. We want more casual users who, during their Emacs journey will get encouraged to start tinkering and then become programmers.
Yeah, I do see that view. I just wonder whether we need to make some tough decisions in order for emacs to survive. Specifically: although emacs is wonderful for tinkerers and non-programmers, what it actually is is a lisp execution environment powering a text editor. When described like that, it's pretty clearly a tool for programmers and expert / adventurous ones at that. I think it might be best to embrace that: it's great for others to join the ride but, sadly, not the raison d'etre of emacs. Better to focus on making it very, very, good within a well-scoped area.
> MacOS is already supported, as I understand.
Stallman et al. have refused to accept into core various patches that are required to make Emacs great on MacOS. For example, native MacOS SVG rendering software is not supported. This is why the Mitsuharu emacs-mac fork [0] exists and is so loved. The reason they've refused to accept those patches is because their inner 14-year olds don't like "companies that make money" and so don't want to accept patches that give "for profit software" an advantage over "free software".
> Github/Gitlab advice zounds nice, but we have to zoom out on this. Using Github/Gitlab sounds nice, but it locks you in. Besides, Email is ubiquitous.
I guess we have to agree to disagree there. My claim is simply that PRs are a technological advance over email review. The fact that Emacs uses non-PR based development makes me not contribute to them. Emailing patches is absurd: a patch is a thing that exists in a code lineage; it has a parent; it's not an entity in its own right. There are many things that are ubiquitous but not the best choice!
[0] https://bitbucket.org/mituharu/emacs-mac/src
The precise term-of-art for "companies that make money" in the Emacs community, coined by RMS himself, is "Evil Software Hoarders".
https://news.ycombinator.com/item?id=26113192
>Bill was probably referring to what RMS calls "Evil Software Hoarder Emacs" aka "UniPress Emacs", which was the commercially supported version of James Gosling's Unix Emacs (aka Gosling Emacs / Gosmacs / UniPress Emacs / Unimacs) sold by UniPress Software, and it actually cost a thousand or so for a source license (but I don't remember how much a binary license was). Sun had the source installed on their file servers while Gosling was working there, which was probably how Bill Joy had access to it, although it was likely just a free courtesy license, so Gosling didn't have to pay to license his own code back from UniPress to use at Sun.
https://en.wikipedia.org/wiki/Gosling_Emacs
>I worked at UniPress on the Emacs display driver for the NeWS window system (the PostScript based window system that James Gosling also wrote), with Mike "Emacs Hacker Boss" Gallaher, who was charge of Emacs development at UniPress. One day during the 80's Mike and I were wandering around an East coast science fiction convention, and ran into RMS, who's a regular fixture at such events.
>Mike said: "Hello, Richard. I heard a rumor that your house burned down. That's terrible! Is it true?"
>RMS replied right back: "Yes, it did. But where you work, you probably heard about it in advance."
>Everybody laughed. It was a joke! Nobody's feelings were hurt. He's a funny guy, quick on his feet!
[...]
https://news.ycombinator.com/item?id=26113192
>Bill was probably referring to what RMS calls "Evil Software Hoarder Emacs" aka "UniPress Emacs", which was the commercially supported version of James Gosling's Unix Emacs (aka Gosling Emacs / Gosmacs / UniPress Emacs / Unimacs) sold by UniPress Software, and it actually cost a thousand or so for a source license (but I don't remember how much a binary license was). Sun had the source installed on their file servers while Gosling was working there, which was probably how Bill Joy had access to it, although it was likely just a free courtesy license, so Gosling didn't have to pay to license his own code back from UniPress to use at Sun.
https://en.wikipedia.org/wiki/Gosling_Emacs
>I worked at UniPress on the Emacs display driver for the NeWS window system (the PostScript based window system that James Gosling also wrote), with Mike "Emacs Hacker Boss" Gallaher, who was charge of Emacs development at UniPress. One day during the 80's Mike and I were wandering around an East coast science fiction convention, and ran into RMS, who's a regular fixture at such events.
>Mike said: "Hello, Richard. I heard a rumor that your house burned down. That's terrible! Is it true?"
>RMS replied right back: "Yes, it did. But where you work, you probably heard about it in advance."
>Everybody laughed. It was a joke! Nobody's feelings were hurt. He's a funny guy, quick on his feet!
[...]
I can see SVG fine on my Mac from top of tree emacs. (I think I use the rsvg library.) Maybe I misunderstood something; what is the thing I am missing?
So, for example, if you use preview-latex in auctex, or the equivalent functionality in org-mode, you'll notice that the small image previews are very fuzzy, and not at all what you'd expect from your retina screen. The reason ultimately is that the Mitsuharu emacs-map fork has implemented certain things which make PNGs scale correctly for Retina screens, and makes use of Apple's native webkit-based SVG renderer rather than the Stallman-acceptable librsvg. But of course Stallman refused to accept the hard work done by Mitsuharu, which makes Emacs better for a subset of Emacs users and therefore is an _improvement_ to Emacs, with the childish logic that they don't want to allow things that makes emacs better on "non-free" systems than on "free" systems.
See the following for example:
https://stackoverflow.com/questions/30151338/org-latex-previ...
https://www.reddit.com/r/emacs/comments/4n8p5i/emacs_org_mod...
https://github.com/politza/pdf-tools/issues/51
See the following for example:
https://stackoverflow.com/questions/30151338/org-latex-previ...
https://www.reddit.com/r/emacs/comments/4n8p5i/emacs_org_mod...
https://github.com/politza/pdf-tools/issues/51
Thanks! pdf-tools gives me very crip images without the flag mentioned in the gibhub issue (perhaps that's default by now?). My personal org setup uses pdf-tools, so maybe that's why I didn't notice that one either. I hadn't used the the Mac, and Emacs on a Mac as a primary driver for work from home until about 3 months ago, but after the first couple of weeks of dealing with annoying minute changes during my adaptation from Linux, I now work more-or-less fine on it (with external keyboard, mouse, and monitor most of the time, and most of the time in iterm2 on a remote Emacs server; the remaining time, from the local Emacs, for visualization, reading PDF papers or documentation, and composing local documents.)
I don't really know how the emacs project is organized but I would have assumed that prolog-mode was maintained on its own by prolog-emacs enthusiasts, and not the core emacs project. I am hard pressed to consider a complaint about indenting in a specific language mode an "Emacs bug"
The only real requirements for getting something included with Emacs itself are that you assign copyright to the FSF and that the code basically works.
There are well over a million lines of Emacs Lisp code included with Emacs (a million and a half, last time I checked), and most of that is for things that the average user won’t need right away, or won’t ever need. The goal is to make Emacs (and by extension Free Software) comprehensive, not to limit the amount of work that the maintainers might need to do. The work they do is naturally limited by the amount of time that they have in a day, so of course it falls to the rest of us to chip in from time to time, especially with language–specific modes where the maintainers may not use that specific language themselves.
There are well over a million lines of Emacs Lisp code included with Emacs (a million and a half, last time I checked), and most of that is for things that the average user won’t need right away, or won’t ever need. The goal is to make Emacs (and by extension Free Software) comprehensive, not to limit the amount of work that the maintainers might need to do. The work they do is naturally limited by the amount of time that they have in a day, so of course it falls to the rest of us to chip in from time to time, especially with language–specific modes where the maintainers may not use that specific language themselves.
This came up a couple days ago:
https://news.ycombinator.com/item?id=28150654
https://news.ycombinator.com/item?id=28150654
>It is cost free. It prevents people from filing it again. It provides insight into later problems. It provides a place where people can ask and offer advice on working around it. Sometimes an intractable bug becomes more tractable later. It can provide a clue to a later bug report. Sometimes someone new has a brainwave on how to fix it.
I have to disagree at 1) the assertion that it's cost free, and 2) it will prevent people from filling it again
re: 1) - it creates clutter, which at least to some individuals like myself, can be costly in the form of being overwhelming/frustrating/obstructive/etc. YMMV on cost:reward on keeping issues open indefinitely. There are other solutions like filtering, but if everyone is filtering out untouched issues, there's not much difference from closing it.
re: 2) is predicated on issue creators actually searching the entire backlog for a pre-existing issue, which they may or may not find.
I certainly agree that the issue itself should be kept in the tracking system, and continue to be able to be viewed and referenced for the reasons you state. Also consider that issues can be reopened if they were closed in error.
I have to disagree at 1) the assertion that it's cost free, and 2) it will prevent people from filling it again
re: 1) - it creates clutter, which at least to some individuals like myself, can be costly in the form of being overwhelming/frustrating/obstructive/etc. YMMV on cost:reward on keeping issues open indefinitely. There are other solutions like filtering, but if everyone is filtering out untouched issues, there's not much difference from closing it.
re: 2) is predicated on issue creators actually searching the entire backlog for a pre-existing issue, which they may or may not find.
I certainly agree that the issue itself should be kept in the tracking system, and continue to be able to be viewed and referenced for the reasons you state. Also consider that issues can be reopened if they were closed in error.
What's the most exciting features recently added to Emacs (or coming soon)? I don't use emacs at all, so any feature you're excited for is fair game, even if it's not exactly recent.
I'm not an Emacs user per se, but I am an org-mode user. I don't even know where to begin to start recommending org-mode, it is a literal life changer. It is everything that you've ever wanted in any note-taking app (Except perhaps syncing with mobile devices, but people are working on that).
Seriously, go through the fine tutorial and just start exploring it. No matter what you put off for doing that, it will be worth it.
https://orgmode.org/worg/org-tutorials/orgtutorial_dto.html
Seriously, go through the fine tutorial and just start exploring it. No matter what you put off for doing that, it will be worth it.
https://orgmode.org/worg/org-tutorials/orgtutorial_dto.html
Somewhat recently the native-comp branch was merged which compiles Elisp to native code.
In my experience, this has a huge positive impact on performance, and can make Emacs feel a lot faster, smoother, and more responsive. Others say it doesn’t yield a noticeable difference for them, but on both of my machines it’s quite noticeable.
In my experience, this has a huge positive impact on performance, and can make Emacs feel a lot faster, smoother, and more responsive. Others say it doesn’t yield a noticeable difference for them, but on both of my machines it’s quite noticeable.
native-comp
LSP support (Language Server Protocol). Basically any language / file format for which a LSP backend has been written can now be used from Emacs.
LSP is not as powerful yet as, say, IntelliJ IDEA for Java development but suddenly the line between "text editor" and "IDE" for Emacs got much, much, much more blurry.
LSP support (Language Server Protocol). Basically any language / file format for which a LSP backend has been written can now be used from Emacs.
LSP is not as powerful yet as, say, IntelliJ IDEA for Java development but suddenly the line between "text editor" and "IDE" for Emacs got much, much, much more blurry.
> but suddenly the line between "text editor" and "IDE" for Emacs got much, much, much more blurry
SLIME already did this to Emacs like twenty years ago.
SLIME already did this to Emacs like twenty years ago.
I wasn't aware. Is LSP support now in Emacs master/feature branch? I thought we needed lsp-mode/eglot extensions for it.
Oh sorry... I thought the question was about the Emacs ecosystem overall, not just about the core stuff.
I think it's tough as a maintainer to manage backlogs like this. A lot of people, especially new maintainers, really hate the idea of bugs just lingering unfixed when a lot of them are obviously fixable. Each bug is only a little bit of work, how hard can it be to keep on top of them?
I feel like most complex-enough projects are not in a situation where there's the time, resources, or motivation to fix everything. I can't think of any real examples where this isn't the case.
If it's a commercial company resources are the concern because achieving perfection doesn't really pay the bills or justify the staffing. In open source, motivation is really the currency and the people who are motivated to fix tens or hundreds of bugs are rare and at high risk of burning out if they attempt to fix everything that comes in.
I just think the upshot is that there's usually a significant number of bugs (or usability issues, quirks, whatever) that are not going to be fixed unless something major changes in the project. Directly acknowledging that seems good, whether closing them or otherwise marking them. Keeping it all open seems like the equivalent of keeping a basement full of junk in the off chance you need each bit in the future.
I'm not sure what the alternative is. Shutting down the project?
I feel like most complex-enough projects are not in a situation where there's the time, resources, or motivation to fix everything. I can't think of any real examples where this isn't the case.
If it's a commercial company resources are the concern because achieving perfection doesn't really pay the bills or justify the staffing. In open source, motivation is really the currency and the people who are motivated to fix tens or hundreds of bugs are rare and at high risk of burning out if they attempt to fix everything that comes in.
I just think the upshot is that there's usually a significant number of bugs (or usability issues, quirks, whatever) that are not going to be fixed unless something major changes in the project. Directly acknowledging that seems good, whether closing them or otherwise marking them. Keeping it all open seems like the equivalent of keeping a basement full of junk in the off chance you need each bit in the future.
I'm not sure what the alternative is. Shutting down the project?
"I'm going to go ahead and guess that the problems discussed
were fixed, and I'm closing this bug report. "
This is not a way to assert a bug is fixed. Success looks like actually trying the code in the bug report that demonstrates the bug, and/or contacting the report participants, to confirm that the bug is actually fixed for the participants.
This is not a way to assert a bug is fixed. Success looks like actually trying the code in the bug report that demonstrates the bug, and/or contacting the report participants, to confirm that the bug is actually fixed for the participants.
cleaning up the bug reporting system is often one of my jobs.
the point of a bug report is to let you know something is going on, to provide context useful in tracking it down, and tracking for the eventual resolution.
as they years tick by, some bug reports are counterproductive because they are unclear, dont give _any_ diagnostic information, or are no longer relevant because the codebase has shifted.
its great to say for each of these issues we should spend a day or two trying to reproduce them - but its really not the best use of time.
we're not talking about capriciously trashing useful bug reports. we're trying to lower the noise floor so that the actionable bugs stand out and are more likely to be dealt with.
the point of a bug report is to let you know something is going on, to provide context useful in tracking it down, and tracking for the eventual resolution.
as they years tick by, some bug reports are counterproductive because they are unclear, dont give _any_ diagnostic information, or are no longer relevant because the codebase has shifted.
its great to say for each of these issues we should spend a day or two trying to reproduce them - but its really not the best use of time.
we're not talking about capriciously trashing useful bug reports. we're trying to lower the noise floor so that the actionable bugs stand out and are more likely to be dealt with.
The same way we have text classification for the spam in our mail inbox, couldn't someone train a model to classify issues as actionable bugs vs. noise for large projects like the one mentioned in the OP? Data would come from closed issues:
- if the issue lead to a commit, or a merge is mentioned in the thread, then it is actionable,
- if the issue was closed without any code change, then it is noise.
- if the issue lead to a commit, or a merge is mentioned in the thread, then it is actionable,
- if the issue was closed without any code change, then it is noise.
maybe. but i think this process really helps develop a deeper understanding of the evolution of the project and doesn't take that much time.
and I bet your AI isn't going to be able to say 'oh yeah, thats just that thing we fixed in 2.1'
seems useful in a second-order capacity though - process introspection
and I bet your AI isn't going to be able to say 'oh yeah, thats just that thing we fixed in 2.1'
seems useful in a second-order capacity though - process introspection
You do see a decent number of GitHub bots that will trash issues if they don’t comply to some sort of “expected/observed/steps/specs” format, which I think more or less accomplishes the same thing. The only issue is you’re potentially losing out on issues from less-tech-savvy users, but I guess simply using GitHub filters many of those people anyways.
I'm reacting from a place of emotion here but your suggested approach just doesn't scale for an open-source project. Nothing is more soul-destroying than an ever growing backlog. If people don't care enough to follow up with an easy reproducible case or even open the PR to fix themselves then they have no right to squat the backlog.
Sure for commercial situations you expect the customer to sign off on a fix but a maintainer's responsibility in open source is exactly 0. Even having a bug tracker is an affordance from the maintainer, GitHub supports turning issues off.
I'm going to continue to terminate old issues where the problem described was vague or the reporter has gone AWOL and I would encourage all OSS maintainers out there to do the same, let's manage expectations.
Sure for commercial situations you expect the customer to sign off on a fix but a maintainer's responsibility in open source is exactly 0. Even having a bug tracker is an affordance from the maintainer, GitHub supports turning issues off.
I'm going to continue to terminate old issues where the problem described was vague or the reporter has gone AWOL and I would encourage all OSS maintainers out there to do the same, let's manage expectations.
It had been believed to have been fixed over 5 years ago, and had no follow up from the reporter to confirm or refute. Why should a maintainer spend more time on it at this point?
My company that I work at actually closes bug reports that has been in "pending customer feedback" for more than 6 months automatically. The customer is free to re-open the issue at a later date if it's still an issue.
I personally think that's fine. You'd have the time to verify and close every issue in a perfect world, but the world rarely is. Before that we had 100+ issues open with bugs we could not even reproduce that where open for years. It just becomes clutter at that point.
I personally think that's fine. You'd have the time to verify and close every issue in a perfect world, but the world rarely is. Before that we had 100+ issues open with bugs we could not even reproduce that where open for years. It just becomes clutter at that point.
That seems reasonable, because you're waiting for a response that may not arrive. This is very different from a bug where all necessary customer feedback had already been collected, and is pending a fix.
I observe many contributors over many years. And still very active.
Said that, however, didn’t I notice emacs becoming amazing in the eyes of the majority of programmers (in example).
So either it’s greatness is indeed stealth. Or maybe the code isn’t so good and requires endless work with not much added value.
If anyone with an inside view could give his opinion on this?
I’m disturbed that he needed a for loop to compute 100*(1-0.9^10)
> I’m disturbed that he needed a for loop to compute 100*(1-0.9^10)
I assumed that he just wanted a reason to include at least a _little_ elisp. (Though, even so, he could at least have run the calculation recursively; in Raku, I'd probably have written
I assumed that he just wanted a reason to include at least a _little_ elisp. (Though, even so, he could at least have run the calculation recursively; in Raku, I'd probably have written
(-> $_, $i { $i ?? &?BLOCK($_ × .9, $i-1) !! $_ })(100, 10)
I'm disturbed by this awful loop, every time I see `setq' gives me the heretic though, that most of the eslip code is just Perl with parentheses.
(cl-loop
for sum = 0 then (+ sum (* total 0.1))
for total = 100 then (* total 0.9)
repeat 10
finally (return (list sum total)))For absolute throwaway, get-something-done code, I think it was fine. If you’re trying to hack out an answer, points for style, mathematical or programming-wise, don’t count.
I am in constant awe of Lars Magne. He is both one of the most productive people I know and one of the nicest.
I've been using Emacs since 1982 or so, including ITS TECO Emacs, Gosling/UniPress/SoftwareHoarder Emacs, and Gnu Emacs, and I still use it every day, but I long ago gave up reporting Emacs bugs that will never get fixed because they are actually terribly conceived "features".
Here's an old rant from 2013 that Xah Lee archived and replied to, but that he didn't agree with, but that the late Mark Crispin covered in his own rant in 2011:
(TLDR: Don't try to change emacs into Microsoft Word without understanding why it is the way it is, don't change long-standing essential defaults out from under people, and don't break type-ahead and keyboard macros.)
https://wilkesley.org/~ian/xah/misc/Don_Hopkins_Mark_Crispin...
[Don wrote:]
>The wrong people have been drunkenly driving Emacs into the ditch for the past decade or so, and they're really screwed it up in so many ways, usually trying to be way too clever and solve problems that really aren't worth solving.
>They made “line-move-visual” the default, which in the service of making Emacs behave more like Microsoft Word, it makes ^N and ^P across wrapped lines stay on the same line and move to the part of the same line that is wrapped above or below the cursor, totally breaking type-ahead predictability and keyboard macros. That totally pissed of the late and long time Emacs user Mark Crispin, and he explains why it's such a terrible idea that breaks keyboard macros: http://compgroups.net/comp.emacs/line-move-visual/274792
>It totally breaks keyboard macros, one of the most important things about Emacs. It definitely should not have been made the default, since keyboard macros are a way of life for real emacs hackers. I totally agree with Mark's take on the problem, and I am terribly disappointed that RMS let somebody get away with changing it that way, and making that horrible mode the default.
>They just can't stop trying to make it more like Microsoft Word, while failing to actually achieve that goal, and only succeeding in inflicting half-assed solutions with harmful unpredictable side-effects on the users.
>Another example is how the region highlighting and the weird pending delete behavior terrorizes me that sometimes but not all the time according to rules I just can't figure out or tell by looking at the screen, when I type something that I intend to insert, a huge chunk of my buffer might just disappear, but sometimes it doesn't. So now Emacs has become unpredictable and malicious. I have to do a dance of “insert character, undo” to know that I have canceled the pending delete mode. You can't tell if you are in pending delete mode just by looking at the screen and seeing the obnoxious highlighting, because sometimes it highlights the region and isn't in pending delete mode, and sometimes it highlights the region and is in pending delete mode. I just wish it would stop highlighting the region, because any time I set a mark and move around, it highlights half of the screen at no use to me, and that just gives me a headache, and I have to insert a character an undo it to cancel the highlighting, and until I cancel the highlighting I am living in terror that my next keystroke will delete a huge unseen portion of the buffer.
>And the thing that REALLY pisses me off is the lame-assed attempt to make ^A and ^E ignore the prompt in shell mode. There is an extremely simple reliable solution to the problem of separating the prompt from your input in shell mode so you can always get to the beginning of the line with ^A, and that is to have a newline at the end of your prompt, so every line you type in is on the whole line and does not have a prompt prefix, therefore no half-assed magic is necessary.
>But the half-assed magic is terribly implemented and has bizarre side-effects that screw me all the time: I get these fucking invisible force fields inserted into the line between my characters whenever I yank some text onto the line that has a prompt or a command line on it, and I can't move past them with ^A or ^E (but sometimes I can — they're not predictable which is even worse)! And I can get any number of these fucking invisible force fields on my line, so in order to get to the beginning of the line I have to go ^A, look at the screen to see if I made it, type ^B ^A if I didn't, again and again, until I drill past all the invisible force fields that are trying to make my day happier.
>And then I have to mark the beginning of the line I want to edit and repeat, go to the end of line by drilling back some number of opposite facing invisible force fields (which may be in different places than the ones going the other direction), and then kill the region, go to the end of the buffer, then yank the entire line to get a copy of it without any fucking invisible force fields in it.
>But if there is an invisible force field in the line, or I just want to edit a few characters of the line and that adds some invisible force fields that were not even there before, and then I hit return in the vain hope of re-entering the entire line but not the prompt, it just enters the tail of the line after the last invisible force field, making an error in the shell, or sometimes even executing a totally different command than I intended and totally fucking me over.
>I would really like somebody to explain what the fuck the idea behind the invisible force fields are, and give me the address of whoever thought is was such a brilliant idea, so I can send a robot drone to firebomb their house, or worse yet send RMS to live with them for a few months. Why did they do something so terrible, that totally fucks up such common important operations, to solve a trivial problem that has a much better solution?
>Emacs used to be totally predictable. I learned it at 300 baud over the ARPANET on ITS, and I could type ahead hundreds of characters to do all kinds of stuff, and then go take a piss or get a drink or take a bong hit, and come back later, and it would be in exactly the state I meant for it to end up in. Now, I can't do that even on a local display. And for some fucking reason, it waits for up to five seconds sometime before updating the display when I'm running it in a terminal (especially when I start an incremental search or query replace). What the fuck is that about??! Not only is it totally unpredictable and forces me to stop what I'm doing and wait for it to catch up so I can figure out what state it guessed its way into before going on, but it won't paint the screen for five seconds when running on a modern top-of-the-line computer!
>Emacs has become a shrine to outrageous violations of the principle of least astonishment. I just can't figure out how they could have come up with so many ways to corrupt it, when it used to work so well. It's totally unpredictable now, and I can't type ahead any more, so I have to type a few characters, look at the screen to see how it misinterpreted my intentions, and then try to work around the misunderstanding.
https://wilkesley.org/~ian/xah/misc/Mark_Crispin_emacs_line_...
[Mark wrote:]
>emacs line wrap rant by Mark Crispin 2011-06-03
https://groups.google.com/d/msg/comp.emacs/Q1SeBV1kkIs/vmY_e...
>What mindless cretin thought that it should be a good idea to make line-move-visual be the default in emacs 23?
>I just found out about this charming "improvement" in the worst possible way. Investigation determined that a "routine" software update had just installed emacs 23 and gave me this "improvement".
>People wonder why everybody hasn't dumped proprietary desktop software. This is an example why. Emacs' line behavior has well over 30 years of history, and some bagbiter goes and changes it BY DEFAULT.
>Add all the cute new features you want. But leave the goddamn defaults alone.
>If you want to have your own playpen where you twiddle defaults to your hearts content, have at it. But don't pretend that you produce software for a production environment, and stop telling the Linux distributions that they should "upgrade" to your "improved" versions. People doing real work depend upon those distributions.
>It does no good to say "read the release notes" when the affected users don't get the release notes and don't even know that a new release happened. It is also unreasonable to expect users to subscribe to every obscure newsgroup, forum, and wiki to hear about changes that will turn their expectations upside down.
>Yes, I fixed my .emacs file. And I'm putting in the same change to all the .emacs files on all the dozens of other machines I use, even though they still have emacs 22, because otherwise this unpleasant surprise will repeat itself over and over again.
>Grr.
>>On Thu, 3 Jun 2010, Uday S Reddy posted:
>>I am not taking sides on the line-move-visual issue. But I do know that it was a complex decision for the Emacs developers and it wasn't made easily.
>They made the wrong decision. Changes to default behavior are a bad idea. Changes to default behavior of the most basic functionality are an extremely bad idea.
>I don't care if M-X fart-noisily-with-spray changes its default scent from skunk to lemon. But I damn well do care about the most basic operations: all CTRL single letter and ESC single letter. After 33+ years of using emacs, I expect these to be reliable and not suddenly change.
>I wasted hours trying to figure out what the hell was wrong with my file, or my terminal emulator window, or my system. The fact that the problem went away on a different system added further confusion. It was only when I did ESC <n> CTRL/N and saw that it moved me the wrong number of lines, but only on one system, that I realized that emacs changed. And that's when I did ESC X describe-key CTRL/N and read about line-mode-visual, although it did not mention that this was now the default.
>Surprise. Grr.
>>However, I am concerned about downstream distributions that omit the release notes. That seems to be a real disservice to the users.
>So I find a system with the release notes. And the reference to this incompatible change is buried 300+ lines deep, after numerous pointless entries such as emacs having a character set 4 times bigger than Unicode.
>-- Mark --
>>On Fri, 4 Jun 2010, Tassilo Horn posted:
>> But all visual line behavior break keyboard macros. Define a macro, then change your window size (so that lines are differently visually wrapped), and bang your macro messes up your text. It's semantics change with the frame/window size. That's silly.
>This is precisely how I got screwed by this incompatible change. But the change in behavior also confused the hell out of me. Almost all of my editing is C source code.
>>Because keyboard macros are important to me, I set line-move-visual to nil.
>Yes.
>-- Mark --
[Don writes:]
To be fair, Xah has written his own pro-line-move-visual rant:
https://wilkesley.org/~ian/xah/emacs/emacs_line_move_visual....
I respect Xah's position, and he wrote a lot interesting text and links and emacs history and learned opinion, but I won't quote it here, because I still disagree with him, and he doesn't address the fact that line-move-visual BREAKS keyboard macros, and keyboard macros are one of the most important reasons and powerful techniques for using Emacs.
But I quoted Mark's rant because I agree with him, he wrote MM and IMAP, his TELNET UI design inspired GLS to write the Telnet Song, and he had the panache to use terms like "cretin" and "bagbiter" and "M-X fart-noisily-with-spray". ;) RIP Mark Crispin.
https://en.wikipedia.org/wiki/Mark_Crispin
Title: Telnet Song, Poet: Guy L. Steele, Jr
https://web.archive.org/web/20040111114819/http://www.cs.ric...
Here's an old rant from 2013 that Xah Lee archived and replied to, but that he didn't agree with, but that the late Mark Crispin covered in his own rant in 2011:
(TLDR: Don't try to change emacs into Microsoft Word without understanding why it is the way it is, don't change long-standing essential defaults out from under people, and don't break type-ahead and keyboard macros.)
https://wilkesley.org/~ian/xah/misc/Don_Hopkins_Mark_Crispin...
[Don wrote:]
>The wrong people have been drunkenly driving Emacs into the ditch for the past decade or so, and they're really screwed it up in so many ways, usually trying to be way too clever and solve problems that really aren't worth solving.
>They made “line-move-visual” the default, which in the service of making Emacs behave more like Microsoft Word, it makes ^N and ^P across wrapped lines stay on the same line and move to the part of the same line that is wrapped above or below the cursor, totally breaking type-ahead predictability and keyboard macros. That totally pissed of the late and long time Emacs user Mark Crispin, and he explains why it's such a terrible idea that breaks keyboard macros: http://compgroups.net/comp.emacs/line-move-visual/274792
>It totally breaks keyboard macros, one of the most important things about Emacs. It definitely should not have been made the default, since keyboard macros are a way of life for real emacs hackers. I totally agree with Mark's take on the problem, and I am terribly disappointed that RMS let somebody get away with changing it that way, and making that horrible mode the default.
>They just can't stop trying to make it more like Microsoft Word, while failing to actually achieve that goal, and only succeeding in inflicting half-assed solutions with harmful unpredictable side-effects on the users.
>Another example is how the region highlighting and the weird pending delete behavior terrorizes me that sometimes but not all the time according to rules I just can't figure out or tell by looking at the screen, when I type something that I intend to insert, a huge chunk of my buffer might just disappear, but sometimes it doesn't. So now Emacs has become unpredictable and malicious. I have to do a dance of “insert character, undo” to know that I have canceled the pending delete mode. You can't tell if you are in pending delete mode just by looking at the screen and seeing the obnoxious highlighting, because sometimes it highlights the region and isn't in pending delete mode, and sometimes it highlights the region and is in pending delete mode. I just wish it would stop highlighting the region, because any time I set a mark and move around, it highlights half of the screen at no use to me, and that just gives me a headache, and I have to insert a character an undo it to cancel the highlighting, and until I cancel the highlighting I am living in terror that my next keystroke will delete a huge unseen portion of the buffer.
>And the thing that REALLY pisses me off is the lame-assed attempt to make ^A and ^E ignore the prompt in shell mode. There is an extremely simple reliable solution to the problem of separating the prompt from your input in shell mode so you can always get to the beginning of the line with ^A, and that is to have a newline at the end of your prompt, so every line you type in is on the whole line and does not have a prompt prefix, therefore no half-assed magic is necessary.
>But the half-assed magic is terribly implemented and has bizarre side-effects that screw me all the time: I get these fucking invisible force fields inserted into the line between my characters whenever I yank some text onto the line that has a prompt or a command line on it, and I can't move past them with ^A or ^E (but sometimes I can — they're not predictable which is even worse)! And I can get any number of these fucking invisible force fields on my line, so in order to get to the beginning of the line I have to go ^A, look at the screen to see if I made it, type ^B ^A if I didn't, again and again, until I drill past all the invisible force fields that are trying to make my day happier.
>And then I have to mark the beginning of the line I want to edit and repeat, go to the end of line by drilling back some number of opposite facing invisible force fields (which may be in different places than the ones going the other direction), and then kill the region, go to the end of the buffer, then yank the entire line to get a copy of it without any fucking invisible force fields in it.
>But if there is an invisible force field in the line, or I just want to edit a few characters of the line and that adds some invisible force fields that were not even there before, and then I hit return in the vain hope of re-entering the entire line but not the prompt, it just enters the tail of the line after the last invisible force field, making an error in the shell, or sometimes even executing a totally different command than I intended and totally fucking me over.
>I would really like somebody to explain what the fuck the idea behind the invisible force fields are, and give me the address of whoever thought is was such a brilliant idea, so I can send a robot drone to firebomb their house, or worse yet send RMS to live with them for a few months. Why did they do something so terrible, that totally fucks up such common important operations, to solve a trivial problem that has a much better solution?
>Emacs used to be totally predictable. I learned it at 300 baud over the ARPANET on ITS, and I could type ahead hundreds of characters to do all kinds of stuff, and then go take a piss or get a drink or take a bong hit, and come back later, and it would be in exactly the state I meant for it to end up in. Now, I can't do that even on a local display. And for some fucking reason, it waits for up to five seconds sometime before updating the display when I'm running it in a terminal (especially when I start an incremental search or query replace). What the fuck is that about??! Not only is it totally unpredictable and forces me to stop what I'm doing and wait for it to catch up so I can figure out what state it guessed its way into before going on, but it won't paint the screen for five seconds when running on a modern top-of-the-line computer!
>Emacs has become a shrine to outrageous violations of the principle of least astonishment. I just can't figure out how they could have come up with so many ways to corrupt it, when it used to work so well. It's totally unpredictable now, and I can't type ahead any more, so I have to type a few characters, look at the screen to see how it misinterpreted my intentions, and then try to work around the misunderstanding.
https://wilkesley.org/~ian/xah/misc/Mark_Crispin_emacs_line_...
[Mark wrote:]
>emacs line wrap rant by Mark Crispin 2011-06-03
https://groups.google.com/d/msg/comp.emacs/Q1SeBV1kkIs/vmY_e...
>What mindless cretin thought that it should be a good idea to make line-move-visual be the default in emacs 23?
>I just found out about this charming "improvement" in the worst possible way. Investigation determined that a "routine" software update had just installed emacs 23 and gave me this "improvement".
>People wonder why everybody hasn't dumped proprietary desktop software. This is an example why. Emacs' line behavior has well over 30 years of history, and some bagbiter goes and changes it BY DEFAULT.
>Add all the cute new features you want. But leave the goddamn defaults alone.
>If you want to have your own playpen where you twiddle defaults to your hearts content, have at it. But don't pretend that you produce software for a production environment, and stop telling the Linux distributions that they should "upgrade" to your "improved" versions. People doing real work depend upon those distributions.
>It does no good to say "read the release notes" when the affected users don't get the release notes and don't even know that a new release happened. It is also unreasonable to expect users to subscribe to every obscure newsgroup, forum, and wiki to hear about changes that will turn their expectations upside down.
>Yes, I fixed my .emacs file. And I'm putting in the same change to all the .emacs files on all the dozens of other machines I use, even though they still have emacs 22, because otherwise this unpleasant surprise will repeat itself over and over again.
>Grr.
>>On Thu, 3 Jun 2010, Uday S Reddy posted:
>>I am not taking sides on the line-move-visual issue. But I do know that it was a complex decision for the Emacs developers and it wasn't made easily.
>They made the wrong decision. Changes to default behavior are a bad idea. Changes to default behavior of the most basic functionality are an extremely bad idea.
>I don't care if M-X fart-noisily-with-spray changes its default scent from skunk to lemon. But I damn well do care about the most basic operations: all CTRL single letter and ESC single letter. After 33+ years of using emacs, I expect these to be reliable and not suddenly change.
>I wasted hours trying to figure out what the hell was wrong with my file, or my terminal emulator window, or my system. The fact that the problem went away on a different system added further confusion. It was only when I did ESC <n> CTRL/N and saw that it moved me the wrong number of lines, but only on one system, that I realized that emacs changed. And that's when I did ESC X describe-key CTRL/N and read about line-mode-visual, although it did not mention that this was now the default.
>Surprise. Grr.
>>However, I am concerned about downstream distributions that omit the release notes. That seems to be a real disservice to the users.
>So I find a system with the release notes. And the reference to this incompatible change is buried 300+ lines deep, after numerous pointless entries such as emacs having a character set 4 times bigger than Unicode.
>-- Mark --
>>On Fri, 4 Jun 2010, Tassilo Horn posted:
>> But all visual line behavior break keyboard macros. Define a macro, then change your window size (so that lines are differently visually wrapped), and bang your macro messes up your text. It's semantics change with the frame/window size. That's silly.
>This is precisely how I got screwed by this incompatible change. But the change in behavior also confused the hell out of me. Almost all of my editing is C source code.
>>Because keyboard macros are important to me, I set line-move-visual to nil.
>Yes.
>-- Mark --
[Don writes:]
To be fair, Xah has written his own pro-line-move-visual rant:
https://wilkesley.org/~ian/xah/emacs/emacs_line_move_visual....
I respect Xah's position, and he wrote a lot interesting text and links and emacs history and learned opinion, but I won't quote it here, because I still disagree with him, and he doesn't address the fact that line-move-visual BREAKS keyboard macros, and keyboard macros are one of the most important reasons and powerful techniques for using Emacs.
But I quoted Mark's rant because I agree with him, he wrote MM and IMAP, his TELNET UI design inspired GLS to write the Telnet Song, and he had the panache to use terms like "cretin" and "bagbiter" and "M-X fart-noisily-with-spray". ;) RIP Mark Crispin.
https://en.wikipedia.org/wiki/Mark_Crispin
Title: Telnet Song, Poet: Guy L. Steele, Jr
https://web.archive.org/web/20040111114819/http://www.cs.ric...
>They made “line-move-visual” the default, which in the service of making Emacs behave more like Microsoft Word, it makes ^N and ^P across wrapped lines stay on the same line and move to the part of the same line that is wrapped above or below the cursor, totally breaking type-ahead predictability and keyboard macros.
As you say, "keyboard macros are a way of life for real emacs hackers" and that just happened to break my use of an on the fly macro five minutes ago. With today's super wide landscape modes it's not normally a problem, but someone also decided to change some default two window modes to vertical instead of horizontal.
The other two changes are also constant annoyances, in particular I'm really impressed how much shell mode has been broken.
As you say, "keyboard macros are a way of life for real emacs hackers" and that just happened to break my use of an on the fly macro five minutes ago. With today's super wide landscape modes it's not normally a problem, but someone also decided to change some default two window modes to vertical instead of horizontal.
The other two changes are also constant annoyances, in particular I'm really impressed how much shell mode has been broken.
Here are the reports of the shell mode "invisible force field" bugs, that were closed but not fixed, then opened again, then closed again, and still not fixed, because the bug was apparently put back in, for reasons I can't fathom.
I still suffer from this bug every day, and have developed elaborate work-arounds involving many extra key presses that I've committed to muscle memory and do without thinking now.
Well actually I do think about how stupid it is this isn't fixed, and how stupid it is somebody designed and implemented it in the first place, and how stupid it is that somebody put the bug it back in after somebody fixed it, every time I have to work around it, which is regularly, quite often.
Shell mode didn't originally have this problem, not in UniPress/Gosling Emacs, and not in the original Gnu emacs. Somebody actually came up with it and programmed it and got it past the gatekeepers and reviewed and committed in the main code (possibly twice!), and now nobody will acknowledge that it is a problem, even after Daniel's extremely detailed step-by-step bug report showing how to reproduce it (as if it didn't happen many times a day under normal usage), and my reminder that it was back.
The irony is that the broken shell mode is supposed to be one of the primary and most powerful advantages and flexible ways to use emacs, which can be synergistically combined with keyboard macros (which are also broken) to make on-the-fly macros that copy and paste and edit the long-lined output of one program and feed it into another (which can go terribly wrong, because of these two bugs and their interactions).
i.e.: split the shell window, switch to the top output window, position the cursor on the first line of output from a previously run command in the top window, switch to the bottom input window, position the cursor at the end on the prompt, switch back to the input window, start a keyboard macro, copy a line of output from the top output window, move to the next line (invoking the visual-lines bug), switch to the bottom output window, yank the line of text and edit it into a new input or command, and hit return to enter it into the shell (invoking the shell invisible force field bug), then switch back to the first window, end the macro, then ^U <count> ^X e repeat as much as needed. But no, you get hit by the visual-lines bug in the top output window, and the invisible force field bug in the bottom input window, again and again, spewing invalid mangled commands to the shell that do god knows what. It's like getting Eiffel-Towered by two bugs at once, one in each window!
https://debbugs.gnu.org/db/37/3735.html
>Introduction:
>In shell mode, editing of command output and previous command lines into new command lines and submission of those new command lines are quite broken.
>For example, editing a previous command's output lines to turn them into a new command line and then typing RET (executing comint-send-input) to try to submit it to the shell frequently submits only part of the line, and C-a and C-e frequently stop somewhere in the middle of the line.
>These problems severely reduce the usability of shell mode, which, before the breakage, was great for editing command output into related command lines (and editing it in general).
>Also, note that the partial submission can be very dangerous. For example, trying to edit an output line "one_thing" (e.g., from an "ls /dir" command) into the command line "rm -rf /dir/one_thing" can easily result in the command line "rm -rf /dir/" instead.
>The problem appears to be because of changes made to distinguish shell-prompt text from command text (and maybe also changes made to highlight error lines in command output. Apparently, boundaries between runs of text with different attributes cause commands to hit those boundaries instead of their normal boundaries (e.g., line boundaries for C-e, C-a, RET (comint-send-input)).
>Version information: This problem:
>- did not exist in Emacs 20.7.2,
>- first appeared somewhere in Emacs 21.x,
>- exists in Emacs 22.2.21 (NTEmacs and Debian Etch's emacs22 package, version_22.2+2-5), and
>- exists in Emacs 22.3 (built from the source in http://ftp.gnu.org/pub/gnu/emacs/emacs-22.3.tar.gz as of 2009-06-30).
>Details:
>Most of the problems occur when editing a line that originally was a command output line and that is being edited into a new command line, or when typing RET (to run comint-send-input) on such a line to execute the command line.
>However, some of the problems also occur when editing or when typing RET on a line that was a previously entered command.
>The main subproblems are:
[Pages of detailed step-by-step instructions to reproduce it under many circumstances omited]
https://debbugs.gnu.org/db/18/18135.html
>Daniel submitted this excellent bug report for a bug that has really been causing me problems, which was claimed to have been fixed, but definitely is not fixed in Emacs 23.3.1 or 24.3.1.
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3735
>Chong mentioned it was fixed in Emacs 23, but said he didn't recall who fixed it.
>Apparently it was put back in and has been back for a long time.
>Could you please investigate to see who fixed it, and who put it back in, and WHY?
>This bug REALLY needs to be fixed, as it makes shell mode practically unusable, and as Daniel described, can lead to some very dangerous and inexplicable accidents.
>And whoever put the bug back in after it was fixed last time needs to stop doing that, please.
>-Don
I still suffer from this bug every day, and have developed elaborate work-arounds involving many extra key presses that I've committed to muscle memory and do without thinking now.
Well actually I do think about how stupid it is this isn't fixed, and how stupid it is somebody designed and implemented it in the first place, and how stupid it is that somebody put the bug it back in after somebody fixed it, every time I have to work around it, which is regularly, quite often.
Shell mode didn't originally have this problem, not in UniPress/Gosling Emacs, and not in the original Gnu emacs. Somebody actually came up with it and programmed it and got it past the gatekeepers and reviewed and committed in the main code (possibly twice!), and now nobody will acknowledge that it is a problem, even after Daniel's extremely detailed step-by-step bug report showing how to reproduce it (as if it didn't happen many times a day under normal usage), and my reminder that it was back.
The irony is that the broken shell mode is supposed to be one of the primary and most powerful advantages and flexible ways to use emacs, which can be synergistically combined with keyboard macros (which are also broken) to make on-the-fly macros that copy and paste and edit the long-lined output of one program and feed it into another (which can go terribly wrong, because of these two bugs and their interactions).
i.e.: split the shell window, switch to the top output window, position the cursor on the first line of output from a previously run command in the top window, switch to the bottom input window, position the cursor at the end on the prompt, switch back to the input window, start a keyboard macro, copy a line of output from the top output window, move to the next line (invoking the visual-lines bug), switch to the bottom output window, yank the line of text and edit it into a new input or command, and hit return to enter it into the shell (invoking the shell invisible force field bug), then switch back to the first window, end the macro, then ^U <count> ^X e repeat as much as needed. But no, you get hit by the visual-lines bug in the top output window, and the invisible force field bug in the bottom input window, again and again, spewing invalid mangled commands to the shell that do god knows what. It's like getting Eiffel-Towered by two bugs at once, one in each window!
https://debbugs.gnu.org/db/37/3735.html
>Introduction:
>In shell mode, editing of command output and previous command lines into new command lines and submission of those new command lines are quite broken.
>For example, editing a previous command's output lines to turn them into a new command line and then typing RET (executing comint-send-input) to try to submit it to the shell frequently submits only part of the line, and C-a and C-e frequently stop somewhere in the middle of the line.
>These problems severely reduce the usability of shell mode, which, before the breakage, was great for editing command output into related command lines (and editing it in general).
>Also, note that the partial submission can be very dangerous. For example, trying to edit an output line "one_thing" (e.g., from an "ls /dir" command) into the command line "rm -rf /dir/one_thing" can easily result in the command line "rm -rf /dir/" instead.
>The problem appears to be because of changes made to distinguish shell-prompt text from command text (and maybe also changes made to highlight error lines in command output. Apparently, boundaries between runs of text with different attributes cause commands to hit those boundaries instead of their normal boundaries (e.g., line boundaries for C-e, C-a, RET (comint-send-input)).
>Version information: This problem:
>- did not exist in Emacs 20.7.2,
>- first appeared somewhere in Emacs 21.x,
>- exists in Emacs 22.2.21 (NTEmacs and Debian Etch's emacs22 package, version_22.2+2-5), and
>- exists in Emacs 22.3 (built from the source in http://ftp.gnu.org/pub/gnu/emacs/emacs-22.3.tar.gz as of 2009-06-30).
>Details:
>Most of the problems occur when editing a line that originally was a command output line and that is being edited into a new command line, or when typing RET (to run comint-send-input) on such a line to execute the command line.
>However, some of the problems also occur when editing or when typing RET on a line that was a previously entered command.
>The main subproblems are:
[Pages of detailed step-by-step instructions to reproduce it under many circumstances omited]
https://debbugs.gnu.org/db/18/18135.html
>Daniel submitted this excellent bug report for a bug that has really been causing me problems, which was claimed to have been fixed, but definitely is not fixed in Emacs 23.3.1 or 24.3.1.
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3735
>Chong mentioned it was fixed in Emacs 23, but said he didn't recall who fixed it.
>Apparently it was put back in and has been back for a long time.
>Could you please investigate to see who fixed it, and who put it back in, and WHY?
>This bug REALLY needs to be fixed, as it makes shell mode practically unusable, and as Daniel described, can lead to some very dangerous and inexplicable accidents.
>And whoever put the bug back in after it was fixed last time needs to stop doing that, please.
>-Don
thanks so much
I changed my Google password, and overall, I received 6 security alerts because of it... I wish that Google would close some bugs too. They are also known for closing unfixed bugs though...
They shut down emacs?
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21526
In general, I find too much emphasis is now on "closing" an issue as soon as possible. I understand that open issues can be a burden for maintainers. However, filing issues, especially making them reproducible, can also be a burden to users, and users will stop filing issues if too many of them are closed unilaterally without actually correcting the root cause.
As I remember it, the Emacs maintainers used to put a lot more emphasis on actually correcting issues instead of only closing them, and this may also be the reason why fewer issues are reported now.
A great attraction of Emacs is how easily one can actually report issues, using Emacs itself: M-x report-emacs-bug RET.