Closing 45% of the open Emacs bugs
This was achieved also by ignoring open issues and simply closing the bug even though the issue still exists. An example of this is:
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.
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.
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.
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.)
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.
> 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)
and be on my way to fetch the tarball and compile (dependencies already loaded into PATH). The same goes for packages like vim or even firefox, if you wanted to hack on them.nix develop nixpkgs#emacsHow 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.
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"
This came up a couple days ago:
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 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'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.
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 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...
thanks so much
> WE BROKE THE ~RESISTANCE~ SUPPORT!
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?