15 ms·

My goal of closing 10% of Emacs bugs (2020)

156 points by goranmoomin 4y ago

Animats 4y ago
After 39 years of EMACS maintenance, having over 3000 bugs is embarrassing.
- andsoitis 4y ago
  It is not like there haven’t been any new features added or refactors done in 39 years… There’s an opportunity cost to fixing bugs rather than adding new capabilities or improving the code base for easier extension. Not all bugs warrant squashing.
- AlchemistCamp 4y ago
  Just wait until you see how many bugs VS Code has!
  - makach 4y ago
    I love VS Code, but I occasionally wonder; should we be amazed over its resilience or in awe that it actually works? I can't decide. also, every time I think about the amount of CPU cycles that has to be executed just for the first pixel to appear on the screen, just, wow. what a time to be alive!
    - eru 4y ago
      People used to think that Emacs was bloated. Like: 'Eight Megabytes (of RAM) And Constantly Swapping', back when 8 MiB was big.
      - db48x 4y ago
        That was back when 8MB was not just big, but so huge that your University’s Computer Science department couldn’t afford it.
  - peoplefromibiza 4y ago
    ~half of that https://github.com/microsoft/vscode/issues?q=is%3Aopen+is%3Aissue+label%3Abug https://github.com/microsoft/vscode/issues?q=is%3Aopen+is%3A... but we all know number of bugs reported is not a very useful metric (dups, weird non reproducible configurations, not confirmed bugs, etc...) besides: VS Code team is very good, we should hope that every software project was developed the same way.
  - ahaferburg 4y ago
    The amazing thing about that repo is not the amount of open bugs (1700) but the amount of closed ones (24k).
- capableweb 4y ago
  Like that says anything about anything? github.com/apple/swift has ~4000 open issues labeled as "bug" and has existed since 8 years ago. That makes about ~500 "bugs" per year while emacs by the same measure then have about ~75 bugs per year. Tell me again how awful that metric is compared to others?
  - sweetgiorni 4y ago
    I'd say that Swift's 4000 issues are significantly more embarrassing given that it's developed by the most valuable tech company in the world.
- bee_rider 4y ago
  It is an open source project, if you are really that embarrassed about the bugs you can look into submitting patches. Most likely if people have been using the program for 39 years, these bugs are not show-stoppers.
- veltas 4y ago
  All big programs have bugs, it has over 3000 because people actually use it and it has a healthy community that can report them. 3000 bugs reported is value.
- forgotpwd16 4y ago
  Besides what other commenters mentioned, Emacs is basically a mini operating system including, besides a text editor, terminal and shell, file manager, diff and merge tool, calculator, mail/news/RSS reader, calendar, diary, IRC client, debugger, sophisticated help system, and others.
- asah 4y ago
  After 39 years of EMACS maintenance, having ONLY 3000 bugs is AMAZING. --- FTFY: most commercial software projects get 3,000 bugs in 3-5 years (if they're successful and grow), and you quickly need a serious database (e.g. jira) to curate them. It's not a morale issue because there's product manager(s) who manage this herd, not eng, and there's no expectation of zero defects because the goal is to win marketshare, which is far removed from any individual bug.
- chlorion 4y ago
  I'm not really sure how to reply to this. The first thing that's worth mentioning is that Emacs isn't simply in "maintenance" mode. There is a nice steady flow of new features, significant features too such as Elisp native compilation and Wayland support. It's also important to keep in mind the sheer scale of Emacs. Vanilla Emacs ships over 1 million lines of Elisp (I'm getting 1.3m according to a small shell script). Considering just how massive of a scale this is, 3000 bugs is really not so bad.
  - db48x 4y ago
    Yea, that’s 3,000 open bug reports, but there are probably at least 10,000 unreported bugs in obscure modes. The really obscure ones are the most likely to be both half–finished and not used very much.
fantyoon 4y ago
This post should probably get a (2020).
chuckledog 4y ago
Looks like since this was posted, the page author has closed another 10% of open emacs bugs: https://lars.ingebrigtsen.no/2022/01/20/13x10/ https://lars.ingebrigtsen.no/2022/01/20/13x10/
- un_ess 4y ago
  Last update is https://lars.ingebrigtsen.no/2022/08/19/19x10/ https://lars.ingebrigtsen.no/2022/08/19/19x10/
  - agumonkey 4y ago
    does he have a live stream :)
  - db48x 4y ago
    I haven’t been following along lately, but this one has a line that made me laugh: > And that leads to Emacs hanging if the mode’s font-lock rules hasn’t been written in a careful manner, and they mostly haven’t. No, they mostly haven’t! That applies to so many things :D
    - josteink 4y ago
      I mean, you simply have to appreciate the completely unapologetic honesty in posts like this. I find it very much refreshing! I'm pretty sure you can't find any public statements by commercial projects written in the same off-handed spirit :)
okamiueru 4y ago
Unrelated to the echievent the article mentions. But I'm curious, how does emacs fare for modern C++ these days? Is it a good IDE? It always struck me that an editor with the history it has, couldn't handle C++11 syntax in 2014. Or, I didn't want to try to figure out how. To clarify, I include common packages as part of "out of the box". From a quick Google search, it does look like cc-lang might be catching up. And some other one-person packages. So my question is, for those of you who work on long lived C++ projects, and on Linux, what IDE do you use? Are CLion and VSCode still the better choice?
- jleahy 4y ago
  Vim is still very popular for c++.
- matthews2 4y ago
  I don't really have any trouble using Emacs on the "modern" C++ codebases that I'm working on. I've tried lsp-mode and eglot with clangd but found that really all I need is a little bit of elisp to call clang-format, dumb-jump (<https://github.com/jacktasia/dumb-jump https://github.com/jacktasia/dumb-jump>) to jump to definition, and project-compile to build the project and collect warnings/errors into a buffer.
- rurban 4y ago
  Emacs with eglot and clangd. VSCode is nice, but on Windows I still prefer Visual Studio.
- ycombinete 4y ago
  A company I worked at handled a massive c++ code base, and nearly all the devs used Emacs as their main editor. That was back in like 2012.
- chlorion 4y ago
  lsp-mode or eglot and company combined with clangd works very well. I also just use the built in "c++-mode" for the major mode. None of these packages are built into Emacs, but eglot and company are on elpa which means they are a "package-install" command away. melpa packages (which lsp-mode is one of) are also pretty trivial to install, it just requires adding melpa to the package archive list variable then installing like normal. Some Linux distros have these available to install with the system package manager. Even Debian has a decent bit of Emacs packages available. I personally use my distros system package manager to manage my Emacs packages since it has everything I need available.
adamaries21 4y ago
[dead]
yellow_lead 4y ago
Much better than other maintainer's brags of closing bugs, which usually just require creating a bot to auto-close them, instead of actually solving them.
KingOfCoders 4y ago
Little bit related: When I come into a company as CTO, and there are too many bugs, I just close all bugs older than 6 months. Usually that's more than 10% (and the org wasn't capable or willing to fix them). Hasn't created any problems yet, but everyone feels better immediately (and we implement ways to not reach high bug levels again).
- tinus_hn 4y ago
  And as a plus, it teaches your customers not to waste their time filing bugs, so your stats look even better! A perfect example of management by excel sheet.
- gspr 4y ago
  Wh... why?
  - dj_mc_merlin 4y ago
    > the org wasn't capable or willing to fix them Probably this. Can't fix everything, and the bugs piling up demoralizes many engineers. Six months is a bit low, I'd go higher, but there's no point having a bug on your board that you're not realistically actually going to fix.
    - gspr 4y ago
      But the proposed action isn't to fix the bugs, it's to delete the documentation of the bugs! Closing your eyes don't make a problem go away. Surely the engineers understand that too, and won't get a moral boost from ignoring the known problems.
      - KingOfCoders 4y ago
        I did not suggest to ignore the known problems: "and we implement ways to not reach high bug levels again" I suggest to close bug reports of bugs that will never get fixed.
yewenjie 4y ago
This is from 2020. See also - https://news.ycombinator.com/item?id=28181575 https://news.ycombinator.com/item?id=28181575 - Closing 45% of the open Emacs bugs | Hacker News
kleiba 4y ago
I saw somebody on Reddit describing reading the Emacs documentation as being forced to read an academic treatise… and I sympathise. I think thorough documentation is important, but sometimes you don’t want to read about all the subtleties and edge cases, but just want a I HAVE A STRING HERE JUST FUCKING TELL ME WHAT TO DO WITH IT list of functions. I couldn't disagree more. I've done tons of Emacs lisp programming over the years, and IMO, the built-in documentation rocks. I find it at the exactly right level of detail for me: when programming, don't you want to know exactly about the edge-cases and subtleties? Is it impossible to improve the documentation? Well, of course not. But as it stands, I find it pretty darn good. Oh, and here's also a well-kept secret: if you have a string, and don't know what to do with it, besides C-h f there's also Google. Most likely, the best result will be a link back to the documentation, so together they cover a lot of ground: the doc has the infos, and Google helps with discoverability.
- krmboya 4y ago
  For experts, a comprehensive manual is useful. For beginners, or people who occasionally dabble in elisp for some light customisation work, a whole treatise in elisp programming is probably an overkill
  - gjadi 4y ago
    Well, that's why there is several documents: C-h i * Elisp: (elisp). The Emacs Lisp Reference Manual. * Emacs Lisp Intro: (eintr). A simple introduction to Emacs Lisp * Emacs: (emacs). The extensible self-documenting text editor. * Emacs FAQ: (efaq). Frequently Asked Questions about Emacs. And that's not even looking at specialized documentation such as the one for Gnus, for Widget, for Dired-X, for Ediff, ... I agree with parent, Emacs documentation is some of the best I know and easily searchable.
    - bhrgunatha 4y ago
      The introspection via all the commands bound to C-h <key/s> is a major thing I miss from any other system. That includes the ability to view and debug the source code - including the base level commands written in C if you've configured it to do so. Plus, it's all right there _in emacs_ with all its facilities and your customisations while you're using it.
TacticalCoder 4y ago
> Namely: EMACS NO LONGER CHOKES ON LONG LINES!!!1! > > Gregory Heytings has developed a brand new, general approach to this tricky problem. The problem stems from how Emacs handles lines, basically: Many functions, like font-locking, run from redisplay, and wants to determine the syntax by looking at a line as (more or less) a unit. And that leads to Emacs hanging if the mode’s font-lock rules hasn’t been written in a careful manner, and they mostly haven’t. From the author's latest blog update. So, at last, we're not all going to need tricks in our Emacs init files anymore to make sure Emacs doesn't slow down when files very long lines (as in: thousands of "characters" or more) are opened.

156 points by goranmoomin 4y ago

Animats 4y ago

After 39 years of EMACS maintenance, having over 3000 bugs is embarrassing.

andsoitis 4y ago
It is not like there haven’t been any new features added or refactors done in 39 years… There’s an opportunity cost to fixing bugs rather than adding new capabilities or improving the code base for easier extension. Not all bugs warrant squashing.
AlchemistCamp 4y ago
Just wait until you see how many bugs VS Code has!
- makach 4y ago
  I love VS Code, but I occasionally wonder; should we be amazed over its resilience or in awe that it actually works? I can't decide. also, every time I think about the amount of CPU cycles that has to be executed just for the first pixel to appear on the screen, just, wow. what a time to be alive!
  - eru 4y ago
    People used to think that Emacs was bloated. Like: 'Eight Megabytes (of RAM) And Constantly Swapping', back when 8 MiB was big.
    - db48x 4y ago
      That was back when 8MB was not just big, but so huge that your University’s Computer Science department couldn’t afford it.
- peoplefromibiza 4y ago
  ~half of that https://github.com/microsoft/vscode/issues?q=is%3Aopen+is%3Aissue+label%3Abug https://github.com/microsoft/vscode/issues?q=is%3Aopen+is%3A... but we all know number of bugs reported is not a very useful metric (dups, weird non reproducible configurations, not confirmed bugs, etc...) besides: VS Code team is very good, we should hope that every software project was developed the same way.
- ahaferburg 4y ago
  The amazing thing about that repo is not the amount of open bugs (1700) but the amount of closed ones (24k).
capableweb 4y ago
Like that says anything about anything? github.com/apple/swift has ~4000 open issues labeled as "bug" and has existed since 8 years ago. That makes about ~500 "bugs" per year while emacs by the same measure then have about ~75 bugs per year. Tell me again how awful that metric is compared to others?
- sweetgiorni 4y ago
  I'd say that Swift's 4000 issues are significantly more embarrassing given that it's developed by the most valuable tech company in the world.
bee_rider 4y ago
It is an open source project, if you are really that embarrassed about the bugs you can look into submitting patches. Most likely if people have been using the program for 39 years, these bugs are not show-stoppers.
veltas 4y ago
All big programs have bugs, it has over 3000 because people actually use it and it has a healthy community that can report them. 3000 bugs reported is value.
forgotpwd16 4y ago
Besides what other commenters mentioned, Emacs is basically a mini operating system including, besides a text editor, terminal and shell, file manager, diff and merge tool, calculator, mail/news/RSS reader, calendar, diary, IRC client, debugger, sophisticated help system, and others.
asah 4y ago
After 39 years of EMACS maintenance, having ONLY 3000 bugs is AMAZING. --- FTFY: most commercial software projects get 3,000 bugs in 3-5 years (if they're successful and grow), and you quickly need a serious database (e.g. jira) to curate them. It's not a morale issue because there's product manager(s) who manage this herd, not eng, and there's no expectation of zero defects because the goal is to win marketshare, which is far removed from any individual bug.
chlorion 4y ago
I'm not really sure how to reply to this. The first thing that's worth mentioning is that Emacs isn't simply in "maintenance" mode. There is a nice steady flow of new features, significant features too such as Elisp native compilation and Wayland support. It's also important to keep in mind the sheer scale of Emacs. Vanilla Emacs ships over 1 million lines of Elisp (I'm getting 1.3m according to a small shell script). Considering just how massive of a scale this is, 3000 bugs is really not so bad.
- db48x 4y ago
  Yea, that’s 3,000 open bug reports, but there are probably at least 10,000 unreported bugs in obscure modes. The really obscure ones are the most likely to be both half–finished and not used very much.

fantyoon 4y ago

This post should probably get a (2020).

chuckledog 4y ago

Looks like since this was posted, the page author has closed another 10% of open emacs bugs: https://lars.ingebrigtsen.no/2022/01/20/13x10/ https://lars.ingebrigtsen.no/2022/01/20/13x10/

un_ess 4y ago
Last update is https://lars.ingebrigtsen.no/2022/08/19/19x10/ https://lars.ingebrigtsen.no/2022/08/19/19x10/
- agumonkey 4y ago
  does he have a live stream :)
- db48x 4y ago
  I haven’t been following along lately, but this one has a line that made me laugh: > And that leads to Emacs hanging if the mode’s font-lock rules hasn’t been written in a careful manner, and they mostly haven’t. No, they mostly haven’t! That applies to so many things :D
  - josteink 4y ago
    I mean, you simply have to appreciate the completely unapologetic honesty in posts like this. I find it very much refreshing! I'm pretty sure you can't find any public statements by commercial projects written in the same off-handed spirit :)

okamiueru 4y ago

Unrelated to the echievent the article mentions. But I'm curious, how does emacs fare for modern C++ these days? Is it a good IDE? It always struck me that an editor with the history it has, couldn't handle C++11 syntax in 2014. Or, I didn't want to try to figure out how. To clarify, I include common packages as part of "out of the box". From a quick Google search, it does look like cc-lang might be catching up. And some other one-person packages. So my question is, for those of you who work on long lived C++ projects, and on Linux, what IDE do you use? Are CLion and VSCode still the better choice?

jleahy 4y ago
Vim is still very popular for c++.
matthews2 4y ago
I don't really have any trouble using Emacs on the "modern" C++ codebases that I'm working on. I've tried lsp-mode and eglot with clangd but found that really all I need is a little bit of elisp to call clang-format, dumb-jump (<https://github.com/jacktasia/dumb-jump https://github.com/jacktasia/dumb-jump>) to jump to definition, and project-compile to build the project and collect warnings/errors into a buffer.
rurban 4y ago
Emacs with eglot and clangd. VSCode is nice, but on Windows I still prefer Visual Studio.
ycombinete 4y ago
A company I worked at handled a massive c++ code base, and nearly all the devs used Emacs as their main editor. That was back in like 2012.
chlorion 4y ago
lsp-mode or eglot and company combined with clangd works very well. I also just use the built in "c++-mode" for the major mode. None of these packages are built into Emacs, but eglot and company are on elpa which means they are a "package-install" command away. melpa packages (which lsp-mode is one of) are also pretty trivial to install, it just requires adding melpa to the package archive list variable then installing like normal. Some Linux distros have these available to install with the system package manager. Even Debian has a decent bit of Emacs packages available. I personally use my distros system package manager to manage my Emacs packages since it has everything I need available.

adamaries21 4y ago

[dead]

yellow_lead 4y ago

Much better than other maintainer's brags of closing bugs, which usually just require creating a bot to auto-close them, instead of actually solving them.

KingOfCoders 4y ago

Little bit related: When I come into a company as CTO, and there are too many bugs, I just close all bugs older than 6 months. Usually that's more than 10% (and the org wasn't capable or willing to fix them). Hasn't created any problems yet, but everyone feels better immediately (and we implement ways to not reach high bug levels again).

tinus_hn 4y ago
And as a plus, it teaches your customers not to waste their time filing bugs, so your stats look even better! A perfect example of management by excel sheet.
gspr 4y ago
Wh... why?
- dj_mc_merlin 4y ago
  > the org wasn't capable or willing to fix them Probably this. Can't fix everything, and the bugs piling up demoralizes many engineers. Six months is a bit low, I'd go higher, but there's no point having a bug on your board that you're not realistically actually going to fix.
  - gspr 4y ago
    But the proposed action isn't to fix the bugs, it's to delete the documentation of the bugs! Closing your eyes don't make a problem go away. Surely the engineers understand that too, and won't get a moral boost from ignoring the known problems.
    - KingOfCoders 4y ago
      I did not suggest to ignore the known problems: "and we implement ways to not reach high bug levels again" I suggest to close bug reports of bugs that will never get fixed.

yewenjie 4y ago

This is from 2020. See also - https://news.ycombinator.com/item?id=28181575 https://news.ycombinator.com/item?id=28181575 - Closing 45% of the open Emacs bugs | Hacker News

kleiba 4y ago

I saw somebody on Reddit describing reading the Emacs documentation as being forced to read an academic treatise… and I sympathise. I think thorough documentation is important, but sometimes you don’t want to read about all the subtleties and edge cases, but just want a I HAVE A STRING HERE JUST FUCKING TELL ME WHAT TO DO WITH IT list of functions. I couldn't disagree more. I've done tons of Emacs lisp programming over the years, and IMO, the built-in documentation rocks. I find it at the exactly right level of detail for me: when programming, don't you want to know exactly about the edge-cases and subtleties? Is it impossible to improve the documentation? Well, of course not. But as it stands, I find it pretty darn good. Oh, and here's also a well-kept secret: if you have a string, and don't know what to do with it, besides C-h f there's also Google. Most likely, the best result will be a link back to the documentation, so together they cover a lot of ground: the doc has the infos, and Google helps with discoverability.

krmboya 4y ago
For experts, a comprehensive manual is useful. For beginners, or people who occasionally dabble in elisp for some light customisation work, a whole treatise in elisp programming is probably an overkill
- gjadi 4y ago
  Well, that's why there is several documents: C-h i * Elisp: (elisp). The Emacs Lisp Reference Manual. * Emacs Lisp Intro: (eintr). A simple introduction to Emacs Lisp * Emacs: (emacs). The extensible self-documenting text editor. * Emacs FAQ: (efaq). Frequently Asked Questions about Emacs. And that's not even looking at specialized documentation such as the one for Gnus, for Widget, for Dired-X, for Ediff, ... I agree with parent, Emacs documentation is some of the best I know and easily searchable.
  - bhrgunatha 4y ago
    The introspection via all the commands bound to C-h <key/s> is a major thing I miss from any other system. That includes the ability to view and debug the source code - including the base level commands written in C if you've configured it to do so. Plus, it's all right there _in emacs_ with all its facilities and your customisations while you're using it.

TacticalCoder 4y ago

> Namely: EMACS NO LONGER CHOKES ON LONG LINES!!!1! > > Gregory Heytings has developed a brand new, general approach to this tricky problem. The problem stems from how Emacs handles lines, basically: Many functions, like font-locking, run from redisplay, and wants to determine the syntax by looking at a line as (more or less) a unit. And that leads to Emacs hanging if the mode’s font-lock rules hasn’t been written in a careful manner, and they mostly haven’t. From the author's latest blog update. So, at last, we're not all going to need tricks in our Emacs init files anymore to make sure Emacs doesn't slow down when files very long lines (as in: thousands of "characters" or more) are opened.