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.
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!
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?
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.
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.
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.
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.
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.
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.
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?
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>) to jump to definition, and project-compile to build the project and collect warnings/errors into a buffer.
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.
I also use lsp-mode+clangd and it works very well. I get completion, jump to definition/implementation/usage, type hints, inline docs, fix-it hints and some minor refactoring help.
I do get some random emacs hangs from time to time (I assume it blocks waiting for some clangd output), likely due to an interaction between lsp-format-region and aggressive-indent-mode. It is an explicitly unsupported combination and it is resolved by killing clangd but it is a bit annoying.
I use sublime because it has nice IDE-like features like a file tree, goto-file, goto-symbol, references to, definitions of, but it is doing simple pattern matching; no IDE will be smart enough to figure out the ungodly build system I work with.
If I'm on windows I like visual studio, love the debugger, but for regular code-slinging I find it pretty slow/unresponsive. I also found VSCode totally unresponsive on Linux so I have pretty high expectations for speed.
People I work with use everything from Atom to Vim to VSCode to Eclipse to Emacs to visual studio on a windows machine, network mounting their linux drive. Everyone builds from a terminal because that is the only thing that works.
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.
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).
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.
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.
Your customers must be reeling at this! Do you really not think it's important to them that known flaws in the product are documented?
> Fixed bugs are important.
Sure. And so are unfixed ones! I'd say even more so.
> Bugs in a bugtracker that are not fixed get you nowhere.
Of course they do! The best thing, as you say, is to fix the problem. But the worst thing is to pretend the problem doesn't exist – documenting it is clearly better.
"But the worst thing is to pretend the problem doesn't exist"
No where did I pretend the problem does not exist.
I wrote
"and we implement ways to not reach high bug levels again"
to fix the problem. I'm not advocating slashing all the bugs every month, or every year. I propose slashing bugs once when the reports got out of hand because of a bad bug culture and then implement better QA and bug fixing practices. This is the opposite of what you imply.
> Because if they’re not resolved yet, there’s no client suffering from them in short term.
This seems like an unrealistically perfect product.
> If they suffer from such a bug, someone will raise it again.
And this seems terrible for everyone involved. Terrible for the customers who have to nag, stay "on the ball" and make sure bugs get re-filed, and terrible for the developers who have to figure out which old (fake-closed) bug reports actually match the new filings.
> I'd buy this if the bug was actually gone. But it's not! Closing a bug report doesn't make the bug go away!
It does improve morale. Developers see a mountain of bugs they could never fix.
> I don't understand. Can you elaborate?
Say you have 100 bugs open for 10 developers, and you close all bugs older than 6 months. Then you go through the remaining one and close all the ones who have no impact ("css line should be 2 pixel but is one pixel") on customers and you get to 30. Then you implement (better) code reviews, phase injection analysis (in which phase a bug was introduced, E.g. missing requirement, and where it was found E.g. customer), enforce static tools (Clippy) policy. Then you do two bug fixing sprints and refactoring of code that gets a high amount of bugs and you have a manageable bug count of 10 (1/dev instead of 10/dev) which keeps low because of the quality improvements you made.
> This seems like a terrible waste of everyone's time.
No managing hundreds of bugs in a bugtracker that do not get fixed is a terrible waste of everyone's time.
> It does improve morale. Developers see a mountain of bugs they could never fix.
So you propose that telling them that the mountain is gone will actually make them believe that it is?
> No managing hundreds of bugs in a bugtracker that do not get fixed is a terrible waste of everyone's time.
How do bug tracker entries waste people's time? Sure, confirming or fixing or otherwise working on a bug takes time, but that's hardly wasted. And if the bug just sits there, how does it waste time?
> So you propose that telling them that the mountain is gone will actually make them believe that it is?
Yes... at least in the short term.
Think about seeing 100 issues vs 1000 issues. 1000 issues is clearly more demotivating. It's also a lot harder to tackle because of the sheer amount. You don't have enough time to fix all of them, so how to do you prioritize and distribute the work? With 100 issues you can get stuck in much quicker and prevent those 1000 issues from stacking up again.
> How do bug tracker entries waste people's time? Sure, confirming or fixing or otherwise working on a bug takes time, but that's hardly wasted. And if the bug just sits there, how does it waste time?
How many bugs do not have payoff proportional to the time spent triaging and working on them? Probably most. Cutting a whole lot of issues probably makes the 'right' decision for >50% of them.
That might actually also be a good technical way to keep track of which bugs were already 'properly' closed, and which were only closed as part of the clean slate.
(Depending on what kind of operations your bug tracker supports or doesn't support.)
It enables the company to get to a different level of fixing bugs. Say you have 10+bugs/engineer, it's hard to realistically lower them. So you slash the number of bugs and that enables you to implement ways to keep the bug count low: fix-bug-first, code reviews, checklists, static tools, phase injection analysis, bug council, etc.
1. You don't know if they are still there. Thousands of commits have been done since then. Whenever I did go through a long list of old bugs, many were not reproduceable.
2. Many companies have no bug triage process and just fill every bug that is reported. So these are bugs that no one has any intention of fixing. So it's not important if they are there or not.
3. You seem to think that only the bugs in your bugtracker are there. They might be the minority of bugs in your code. Whenever I increase unit testing in my own code, I find dozens of bugs. I was once in a company that hired students during holidays for explorative testing. Dozens of bugs were found every time. The amount of bugs in your bugtracker depends on how much customers you have, how much they care and how big your QA effort is. It's nowhere the number of bugs in your application. The bugs in your bugtracker are a random selection with a bias to the more obvious ones of the bugs in your code.
4. If you don't want to fix bugs, you don't need to track them.
If you have a critical security issue not fixed ASAP but lying around for 10 months I'd say you have other problems in your organisation than a high bug count.
> 1. You don't know if they are still there. Thousands of commits have been done since then. Whenever I did go through a long list of old bugs, many were not reproduceable.
It can certainly be reasonable to close unreproducable bugs. But you said that you habitually come in and close any bug older than 6 months. Those are different things.
> 2. Many companies have no bug triage process and just fill every bug that is reported. So these are bugs that no one has any intention of fixing. So it's not important if they are there or not.
Surely it's important to know that the bug exists even if it's unlikely to be fixed?
> 3. You seem to think that only the bugs in your bugtracker are there.
Not at all. What makes you think that?
> The bugs in your bugtracker are a random selection with a bias to the more obvious ones of the bugs in your code.
OK. And? You propose throwing out a list of problems because that list is biased and incomplete? "– My roof is leaking! – Yes, but you're focusing on that because it's easy to see! You should ignore it unless you are also sure that your electrical wiring is sound."
> 4. If you don't want to fix bugs, you don't need to track them.
With respect, this is absolutely nuts! Knowing of deficiencies in a program can be very, very useful!
On the theory that the valid and important enough bugs would've been fixed within 6 months?
Any idea the breakdown of the bugs that were closed?
(Guesses at percentages of which were user error, applied only to an older version, duplicates, irreproducibile, valid but would happen only in freak circumstances, low impact, etc.)
This might be an OK strategy for an internal bug tracker but for an open source project or something else with a public bug tracker just closing unresolved bugs is the best way to alienate your most dedicated users who have taken the time to file bug reports.
Yes you're right, in an open source project the bug tracker helps developers understand why something doesn't work and if it's their problem or a library bug.
Lol.
I don't know why, but apparently my browser isn't sending the referrer header, and I'm using vanilla chrome on Android.
EDIT: Sorry, I think it might actually just be that because I first visited that page before coming in via HN, I've just been seeing the cached version of the real page, instead of the DDoS-protecting testicle.
Jamie (JWZ) doesn't like Hacker News, so like several other sites he detects this site in referrer headers sent by browsers and if it's present you get a custom image instead of what you wanted to read.
Having read his blog for years, I don't think he likes anything or anyone. Not even his nightclub, based on his the past 2.5 years simultaneously a) describing COVID19 as an existential threat to humanity, b) insisting on/bragging about maintaining super-strict requirements for patrons (when San Francisco loosened restrictions, he of course denounced the city as going "against science"), and c) lamenting the continued money drain that his club is.
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.
This is sometimes called a "bug bankrupcty". I'm not that convinced of its usefulness.
Let's apply basic systems theory: if bugs are filed faster than they are resolved, the tendency of the open bug count is toward the infinite. You can declare bankruptcy but it won't change the dynamics of the system: bugs will keep piling up. So you may feel temporary relief, but the underlying problem is still there, causing stress.
You could apply the rule more dynamically: all bugs older than X are always automatically demoted to wontfix status, on the basis that factually, they haven't actually been prioritised for a while. In this case you're using real-world prioritisation decisions to drive the prioritisation status in your bug tracker. This is a more stable solution.
----
But here's where you can take it to the next level. You're de-prioritising a bug for 6 months and then automatically marking it as wontfix. Using "open for 6 months" as the signal to wontfix a bug is relying on a lagging signal.
It would be nice with a leading signal instead, so that you can mark it as wontfix immediately as soon as you know it won't be fixed for six months.
How do you know which bugs fall into the wontfix category immediately? Here's one way:
Make note of the average rate of commits the team is capable of, and decide how much of their time they should spend on bugs, and call the product of that M. Let's say you like the 6 month wontfix threshold, and call this time W. Apply Little's law:
L = M*W
L is the number of open bugs you can have. Find the top L bugs, and mark the rest as wontfix (or the lowest priority level, depending on what angers your users less.)
Concrete example: my previous team committed stuff at a rate of 6.2/day. They spent 30 % of their time fixing bugs. That's roughly 1.9 bug fixed per day. Six months is on average something like 110 workdays. All in all 1.9 * 110 ~= 200 bugs can be open with this the team at any given time.
Anything other than the most important 200 gets marked wontfix immediately.
----
You might complain that it's difficult to say that a bug is less important than 200 other bugs, and you'd be right. Based on my experience, I'd run this with two priority levels and much stricter thresholds. When I have run the analysis on internal bug databases, bugs that are allowed to linger for more than a month are very rarely fixed anyway.
When you have stricter thresholds, you can't just mark everything else "wontfix", because it makes your users angry when it seems like you won't even bother with most of their reported bugs, so you have to add a third priority level that serves as the "probablywontfix" bucket in practise.
- Priority 1 bugs should be fixed within a week,
- Priority 2 bugs should be fixed within a month.
- Priority 3 bugs come without any sort of SLO.
How many open bugs can we have of the priority levels? Same sort of reasoning, but we also need to allocate effort toward priority 1 and priority 2. Let's say 50/50 because I haven't tried evaluating the optimal split.
- Priority 1 bugs open: 1.9 bugs/day * 0.5 * 5 days ~= 5 open bugs
- Priority 2 bugs open: 1.9 bugs/day * 0.5 * 22 days ~= 20 open bugs
For an Open Source project, WONTFIX is particularily disheartening, but also annoying to the next user wanting to report the same bug and not finding it in the list of open bugs. In such cases, it would be better to set the level PATCHESWELCOME to control expectation. I guess this corresponds to your "Priority 3", but is more explicit about it.
Big appreciation for this post. Ironically recently I’ve been drowning in emails and this walkthrough made me think about how I can apply the same reasoning to managing my inbox.
This approach flattens the complexity of bugs into a single value, then measures the importance of bugs by a loosely-correlated, highly-noisy signal: time in queue.
This is also why a recent client dumped a decades-long vendor in an enterprise setting that by proxy implemented this approach through a newly-offshored support team that didn't understand the product and stalled on difficult bugs until the bug reports died on the vine even after repeated executive meetings. Ask the account executive how they felt about losing out on an easy seven-figure annual renewal to a rival who won't likely come up for displacement until after the account exec retires.
To add to the sting, the displacement came at a time that the role of the software product was planned for a big expansion. The tab for more licenses and the work was so high but close enough between the incumbent and challenger that it opened the door...and there went an 8-figure year for the incumbent's account executive. Decades of brand-building and relationship management down the tubes all so some support department head can show off on their scope's bottom line.
We understood these were challenging problems to solve, were patient, and willing to put in the significant person-months of time it would take to help solve them. Client leadership however, was not willing to just get indefinitely shuffled onto the bug queue.
We're not stupid. We know what being blown off looks like. We know when we're talking with a Regex Support organization versus a Semantic Support organization. The lag time between realizing that and acting upon it might take a few years, but once it happens in enterprise software, vendors rarely get another shot within another decade.
As someone who takes a lot of care to document bugs, I would quit if you did that to my bugs. If something isn't reproducible anymore, fine, close it. But just closing stuff that nobody got around to fixing yet is evil.
Usually people don't quit when I join and are rather happy that problems are solved instead of not solved.
I would also not sit at my desk one day, and close all the bugs - but talk to developers, managers, leads, QA and product on how we solve the bug problems together. Slashing the number of bugs in the bugtracker is only one task and people didn't object but agreed to it as a way forward.
I created by first bugs 40 years ago, I've created bugs that brought down sites and have been a tech manager for 25+ years learning on the way on how to deal with bugs. From my experience: "fixing yet" this is the problem. It's not "yet" it's "ever". If a company doesn't fix bugs in 6 or 12 months, it's never spending enough time to fix these bugs because new feature development is always more important.
With the slashing of the bugs and a different approach to quality (E.g. fix bugs first) I would assume you're much happier that the bugs you report get fixed and developers are happy for your good bug reports than bug reports sitting in a bug tracker who no one acts upon.
I would say that closing the bugs as WONTFIX is just changing the specs of the application so it's not a bug anymore.
E.g. if you've got a bug that emojis cause an endpoint to throw a 500, closing the bug as WONTFIX is akin to just saying that emojis are invalid input to the application.
After 6 months or a year, that's how everyone is treating it anyways.
> But just closing stuff that nobody got around to fixing yet is evil.
If nobody is ever going to get around to fixing it, then I'd argue that it needs to be closed.
Which isn't to defend blindly closing issues open more than X days, but in a bugtracker I think it needs to be valid to close an issue was WONTFIX when it might be a valid issue, but the code owners are simply never going to budget the time to get around to it in the next 10 years.
And the bug will still be there and searchable, and people can find it and see the resolution. It may not be satisfying, but the end result communicates clearly that any fix will need to be externally contributed.
Keeping around hundreds of bugs that will never be allocated resources or closed is a drain on the team who is maintaining the bugtracker, they have to periodically go through and curate all those issues, and just looking at the number is fatiguing. The result is usually that people stop interacting with the bugtracker and users really wind up shouting into the void.
There seems to be this attitude by users that they can demand that their issues stay open forever, and that the negative impact on the developers is some kind of punishment for them not having the time to address the issue and that it is unfair to just close issues that won't be addressed, but that's a very self-centered perspective on the part of the user, and the developers wind up suffering a psychological death-by-1000-cuts problem that doesn't help the project or anything get done.
But that means you need to accept at some point that someone is going to kill your baby that you produced and close an issue and tell you that they're not prioritizing it. But they're communicating that they've made a choice, rather than making that choice anyway while leaving the issue open for multiple years and never doing anything about it because they don't have infinite time to fix everything (and every large codebase will always have more bugs than time to fix them).
> I just close all bugs older than 6 months [...] everyone feels better immediately
I mean, people would feel even better if you just closed all the bugs, right?
Some of the oldest unclosed bug reports are the most valuable. because they document long-standing pain points. Not that you would know... :-)
If there were, say, 300 open bugs, you and 4 other people go through and triage them. ("You get bugs whose numbers are 0 mod 5, I get bugs wholes numbers are 1 mod 5", ... )
Organizing lots of tiny bugs into an omnibus bug is also great if all the tasks can be done at the same time. "OMNIBUS: fix help messages. See.... (list of a dozen old closed bugs)"
"Some of the oldest unclosed bug reports are the most valuable. because they document long-standing pain points."
Say there is a bug, "The line should be 2 em high" and the bug is not fixed for 6+ months, how is this more valuable because it's older?
Yes, I would agree with the triage, and do it if possible. If an organisation is unwilling to spend resources to fix bugs, a triage doesn't work.
It's the same with this 100 item backlogs, people put things in backlogs at position 20+ that are never developed but suggest they are developed, reducing immediate pain ("No, we're not going to develop this") but trading it for long term pain ("No, it's not in the next Sprint").
Yes, aggregating bugs into an OMNIBUS or aggregating bugs into a feature as requirements is valuable too.
"The line should be 2 em high" seems more like a feature request or... like just a general whining, than a bug. Your strategy of just closing these is probably valid. But I would call it "closing non-bug complaints which abuse the bug tracker," not slashing bugs.
The reason people are so confused here, I think, is because to programmers, bugs are incorrect behavior of the program. These bugs exist whether they are reported or not. Removing bug reports does not remove bugs.
In other comments you mention "and we implement ways to not reach high bug levels again." Is it possible that from a programmer's point of view, you are actually enforcing proper use of the bug tracker? i.e., keeping graphic design opinions about line widths out of it.
You might be overgeneralizing, I have been coding for 40+ years, maintained several successful open source projects, fixed many bugs, created even more, wrote bug reports and have a Go IDE open right now.
When I buy a second-hand car, if there's a warning light on the instrument panel I put a piece of electrician's tape over it. Hasn't created any problems yet, but everyone feels better immediately.
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.
Reference vs documentation. First you need to find "shape" of thing that you're actually want to use in your current problem. Bunch of examples are the best aid here. If you find whatever you want, then it's time to understand all the subtleties.
But isn't that exactly how Emacs' documentation is organized? For each topic, you get an entry page that gives an overview, followed by a more detailed API documentation.
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
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.
It's subjective. I am also a computer monk, but there are people out there who have irrational feelings about Real Documentation(TM), and ultimately they are worth accommodating.
I know you mean that in a snarky way, but I just for clarity: we're talking about programming your editor here, i.e., writing code to extend Emacs' functionality, not using Emacs to write some unrelated program - which, of course, you probably do much more often, but then you don't need to look up the documentation we're talking about here.
> 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.
116 comments
[ 2.7 ms ] story [ 176 ms ] threadshould 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!
'Eight Megabytes (of RAM) And Constantly Swapping', back when 8 MiB was big.
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.
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?
---
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.
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.
> 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
I'm pretty sure you can't find any public statements by commercial projects written in the same off-handed spirit :)
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?
VSCode is nice, but on Windows I still prefer Visual Studio.
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.
I do get some random emacs hangs from time to time (I assume it blocks waiting for some clangd output), likely due to an interaction between lsp-format-region and aggressive-indent-mode. It is an explicitly unsupported combination and it is resolved by killing clangd but it is a bit annoying.
I should try eglot at some point.
If I'm on windows I like visual studio, love the debugger, but for regular code-slinging I find it pretty slow/unresponsive. I also found VSCode totally unresponsive on Linux so I have pretty high expectations for speed.
People I work with use everything from Atom to Vim to VSCode to Eclipse to Emacs to visual studio on a windows machine, network mounting their linux drive. Everyone builds from a terminal because that is the only thing that works.
Sounds very familiar! People who don't use IDEs should be banned from building tooling - especially build systems.
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.
I suggest to close bug reports of bugs that will never get fixed.
OK. We still disagree about whether that is smart, but one thing is sure: that's not what you wrote originally.
Bugs in a bugtracker are not important. Fixed bugs are important. There is a distinction. Bugs in a bugtracker that are not fixed get you nowhere.
Your customers must be reeling at this! Do you really not think it's important to them that known flaws in the product are documented?
> Fixed bugs are important.
Sure. And so are unfixed ones! I'd say even more so.
> Bugs in a bugtracker that are not fixed get you nowhere.
Of course they do! The best thing, as you say, is to fix the problem. But the worst thing is to pretend the problem doesn't exist – documenting it is clearly better.
It's better to not fix bugs than to fix them?
"But the worst thing is to pretend the problem doesn't exist"
No where did I pretend the problem does not exist.
I wrote
"and we implement ways to not reach high bug levels again"
to fix the problem. I'm not advocating slashing all the bugs every month, or every year. I propose slashing bugs once when the reports got out of hand because of a bad bug culture and then implement better QA and bug fixing practices. This is the opposite of what you imply.
This seems like an unrealistically perfect product.
> If they suffer from such a bug, someone will raise it again.
And this seems terrible for everyone involved. Terrible for the customers who have to nag, stay "on the ball" and make sure bugs get re-filed, and terrible for the developers who have to figure out which old (fake-closed) bug reports actually match the new filings.
- Improves morale
- Focuses the team
- Makes the task more approachable
Etc.
The important ones will probably bubble up again in due time.
I'd buy this if the bug was actually gone. But it's not! Closing a bug report doesn't make the bug go away!
> - Focuses the team
A decent bug tracker should have priority levels for various bugs, surely.
> - Makes the task more approachable
I don't understand. Can you elaborate?
> The important ones will probably bubble up again in due time.
This seems like a terrible waste of everyone's time.
It does improve morale. Developers see a mountain of bugs they could never fix.
> I don't understand. Can you elaborate?
Say you have 100 bugs open for 10 developers, and you close all bugs older than 6 months. Then you go through the remaining one and close all the ones who have no impact ("css line should be 2 pixel but is one pixel") on customers and you get to 30. Then you implement (better) code reviews, phase injection analysis (in which phase a bug was introduced, E.g. missing requirement, and where it was found E.g. customer), enforce static tools (Clippy) policy. Then you do two bug fixing sprints and refactoring of code that gets a high amount of bugs and you have a manageable bug count of 10 (1/dev instead of 10/dev) which keeps low because of the quality improvements you made.
> This seems like a terrible waste of everyone's time.
No managing hundreds of bugs in a bugtracker that do not get fixed is a terrible waste of everyone's time.
So you propose that telling them that the mountain is gone will actually make them believe that it is?
> No managing hundreds of bugs in a bugtracker that do not get fixed is a terrible waste of everyone's time.
How do bug tracker entries waste people's time? Sure, confirming or fixing or otherwise working on a bug takes time, but that's hardly wasted. And if the bug just sits there, how does it waste time?
Yes... at least in the short term.
Think about seeing 100 issues vs 1000 issues. 1000 issues is clearly more demotivating. It's also a lot harder to tackle because of the sheer amount. You don't have enough time to fix all of them, so how to do you prioritize and distribute the work? With 100 issues you can get stuck in much quicker and prevent those 1000 issues from stacking up again.
> How do bug tracker entries waste people's time? Sure, confirming or fixing or otherwise working on a bug takes time, but that's hardly wasted. And if the bug just sits there, how does it waste time?
How many bugs do not have payoff proportional to the time spent triaging and working on them? Probably most. Cutting a whole lot of issues probably makes the 'right' decision for >50% of them.
I can see how this can provide psychological benefits to some people.
(Depending on what kind of operations your bug tracker supports or doesn't support.)
2. Many companies have no bug triage process and just fill every bug that is reported. So these are bugs that no one has any intention of fixing. So it's not important if they are there or not.
3. You seem to think that only the bugs in your bugtracker are there. They might be the minority of bugs in your code. Whenever I increase unit testing in my own code, I find dozens of bugs. I was once in a company that hired students during holidays for explorative testing. Dozens of bugs were found every time. The amount of bugs in your bugtracker depends on how much customers you have, how much they care and how big your QA effort is. It's nowhere the number of bugs in your application. The bugs in your bugtracker are a random selection with a bias to the more obvious ones of the bugs in your code.
4. If you don't want to fix bugs, you don't need to track them.
Would 10 month old well documented report of critical security issue also would be closed after your purge?
It can certainly be reasonable to close unreproducable bugs. But you said that you habitually come in and close any bug older than 6 months. Those are different things.
> 2. Many companies have no bug triage process and just fill every bug that is reported. So these are bugs that no one has any intention of fixing. So it's not important if they are there or not.
Surely it's important to know that the bug exists even if it's unlikely to be fixed?
> 3. You seem to think that only the bugs in your bugtracker are there.
Not at all. What makes you think that?
> The bugs in your bugtracker are a random selection with a bias to the more obvious ones of the bugs in your code.
OK. And? You propose throwing out a list of problems because that list is biased and incomplete? "– My roof is leaking! – Yes, but you're focusing on that because it's easy to see! You should ignore it unless you are also sure that your electrical wiring is sound."
> 4. If you don't want to fix bugs, you don't need to track them.
With respect, this is absolutely nuts! Knowing of deficiencies in a program can be very, very useful!
Any idea the breakdown of the bugs that were closed?
(Guesses at percentages of which were user error, applied only to an older version, duplicates, irreproducibile, valid but would happen only in freak circumstances, low impact, etc.)
I could 100% believe this is genuine, but I would also 100% believe this is a quote from a Dilbert-like comic strip.
[0] https://en.wikipedia.org/wiki/Poe%27s_law
https://news.ycombinator.com/item?id=32734254
even retains the ambiguity. Magnificent.
https://www.jwz.org/doc/cadt.html
And it was particularly nice to see that is by Jamie Zawinski of Zawinski's Law fame:
"Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."
(Assuming you use a browser that sends the referer header)
EDIT: Sorry, I think it might actually just be that because I first visited that page before coming in via HN, I've just been seeing the cached version of the real page, instead of the DDoS-protecting testicle.
I think it's currently this: https://cdn.jwz.org/images/2016/hn.png
Having read his blog for years, I don't think he likes anything or anyone. Not even his nightclub, based on his the past 2.5 years simultaneously a) describing COVID19 as an existential threat to humanity, b) insisting on/bragging about maintaining super-strict requirements for patrons (when San Francisco loosened restrictions, he of course denounced the city as going "against science"), and c) lamenting the continued money drain that his club is.
Let's apply basic systems theory: if bugs are filed faster than they are resolved, the tendency of the open bug count is toward the infinite. You can declare bankruptcy but it won't change the dynamics of the system: bugs will keep piling up. So you may feel temporary relief, but the underlying problem is still there, causing stress.
You could apply the rule more dynamically: all bugs older than X are always automatically demoted to wontfix status, on the basis that factually, they haven't actually been prioritised for a while. In this case you're using real-world prioritisation decisions to drive the prioritisation status in your bug tracker. This is a more stable solution.
----
But here's where you can take it to the next level. You're de-prioritising a bug for 6 months and then automatically marking it as wontfix. Using "open for 6 months" as the signal to wontfix a bug is relying on a lagging signal.
It would be nice with a leading signal instead, so that you can mark it as wontfix immediately as soon as you know it won't be fixed for six months.
How do you know which bugs fall into the wontfix category immediately? Here's one way:
Make note of the average rate of commits the team is capable of, and decide how much of their time they should spend on bugs, and call the product of that M. Let's say you like the 6 month wontfix threshold, and call this time W. Apply Little's law:
L is the number of open bugs you can have. Find the top L bugs, and mark the rest as wontfix (or the lowest priority level, depending on what angers your users less.)Concrete example: my previous team committed stuff at a rate of 6.2/day. They spent 30 % of their time fixing bugs. That's roughly 1.9 bug fixed per day. Six months is on average something like 110 workdays. All in all 1.9 * 110 ~= 200 bugs can be open with this the team at any given time.
Anything other than the most important 200 gets marked wontfix immediately.
----
You might complain that it's difficult to say that a bug is less important than 200 other bugs, and you'd be right. Based on my experience, I'd run this with two priority levels and much stricter thresholds. When I have run the analysis on internal bug databases, bugs that are allowed to linger for more than a month are very rarely fixed anyway.
When you have stricter thresholds, you can't just mark everything else "wontfix", because it makes your users angry when it seems like you won't even bother with most of their reported bugs, so you have to add a third priority level that serves as the "probablywontfix" bucket in practise.
- Priority 1 bugs should be fixed within a week,
- Priority 2 bugs should be fixed within a month.
- Priority 3 bugs come without any sort of SLO.
How many open bugs can we have of the priority levels? Same sort of reasoning, but we also need to allocate effort toward priority 1 and priority 2. Let's say 50/50 because I haven't tried evaluating the optimal split.
- Priority 1 bugs open: 1.9 bugs/day * 0.5 * 5 days ~= 5 open bugs
- Priority 2 bugs open: 1.9 bugs/day * 0.5 * 22 days ~= 20 open bugs
- Priority 3 bugs open: everything else.
This you can actually work with.
For an Open Source project, WONTFIX is particularily disheartening, but also annoying to the next user wanting to report the same bug and not finding it in the list of open bugs. In such cases, it would be better to set the level PATCHESWELCOME to control expectation. I guess this corresponds to your "Priority 3", but is more explicit about it.
This is also why a recent client dumped a decades-long vendor in an enterprise setting that by proxy implemented this approach through a newly-offshored support team that didn't understand the product and stalled on difficult bugs until the bug reports died on the vine even after repeated executive meetings. Ask the account executive how they felt about losing out on an easy seven-figure annual renewal to a rival who won't likely come up for displacement until after the account exec retires.
To add to the sting, the displacement came at a time that the role of the software product was planned for a big expansion. The tab for more licenses and the work was so high but close enough between the incumbent and challenger that it opened the door...and there went an 8-figure year for the incumbent's account executive. Decades of brand-building and relationship management down the tubes all so some support department head can show off on their scope's bottom line.
We understood these were challenging problems to solve, were patient, and willing to put in the significant person-months of time it would take to help solve them. Client leadership however, was not willing to just get indefinitely shuffled onto the bug queue.
We're not stupid. We know what being blown off looks like. We know when we're talking with a Regex Support organization versus a Semantic Support organization. The lag time between realizing that and acting upon it might take a few years, but once it happens in enterprise software, vendors rarely get another shot within another decade.
I would also not sit at my desk one day, and close all the bugs - but talk to developers, managers, leads, QA and product on how we solve the bug problems together. Slashing the number of bugs in the bugtracker is only one task and people didn't object but agreed to it as a way forward.
I created by first bugs 40 years ago, I've created bugs that brought down sites and have been a tech manager for 25+ years learning on the way on how to deal with bugs. From my experience: "fixing yet" this is the problem. It's not "yet" it's "ever". If a company doesn't fix bugs in 6 or 12 months, it's never spending enough time to fix these bugs because new feature development is always more important.
With the slashing of the bugs and a different approach to quality (E.g. fix bugs first) I would assume you're much happier that the bugs you report get fixed and developers are happy for your good bug reports than bug reports sitting in a bug tracker who no one acts upon.
But they are not solved, are they?
> With the slashing of the bugs...
And it's not slashing bugs, but slashing bug reports. The bugs are still there.
You might have overseen
"and we implement ways to not reach high bug levels again"
E.g. if you've got a bug that emojis cause an endpoint to throw a 500, closing the bug as WONTFIX is akin to just saying that emojis are invalid input to the application.
After 6 months or a year, that's how everyone is treating it anyways.
If nobody is ever going to get around to fixing it, then I'd argue that it needs to be closed.
Which isn't to defend blindly closing issues open more than X days, but in a bugtracker I think it needs to be valid to close an issue was WONTFIX when it might be a valid issue, but the code owners are simply never going to budget the time to get around to it in the next 10 years.
And the bug will still be there and searchable, and people can find it and see the resolution. It may not be satisfying, but the end result communicates clearly that any fix will need to be externally contributed.
Keeping around hundreds of bugs that will never be allocated resources or closed is a drain on the team who is maintaining the bugtracker, they have to periodically go through and curate all those issues, and just looking at the number is fatiguing. The result is usually that people stop interacting with the bugtracker and users really wind up shouting into the void.
There seems to be this attitude by users that they can demand that their issues stay open forever, and that the negative impact on the developers is some kind of punishment for them not having the time to address the issue and that it is unfair to just close issues that won't be addressed, but that's a very self-centered perspective on the part of the user, and the developers wind up suffering a psychological death-by-1000-cuts problem that doesn't help the project or anything get done.
But that means you need to accept at some point that someone is going to kill your baby that you produced and close an issue and tell you that they're not prioritizing it. But they're communicating that they've made a choice, rather than making that choice anyway while leaving the issue open for multiple years and never doing anything about it because they don't have infinite time to fix everything (and every large codebase will always have more bugs than time to fix them).
I mean, people would feel even better if you just closed all the bugs, right?
Some of the oldest unclosed bug reports are the most valuable. because they document long-standing pain points. Not that you would know... :-)
If there were, say, 300 open bugs, you and 4 other people go through and triage them. ("You get bugs whose numbers are 0 mod 5, I get bugs wholes numbers are 1 mod 5", ... )
Organizing lots of tiny bugs into an omnibus bug is also great if all the tasks can be done at the same time. "OMNIBUS: fix help messages. See.... (list of a dozen old closed bugs)"
Say there is a bug, "The line should be 2 em high" and the bug is not fixed for 6+ months, how is this more valuable because it's older?
Yes, I would agree with the triage, and do it if possible. If an organisation is unwilling to spend resources to fix bugs, a triage doesn't work.
It's the same with this 100 item backlogs, people put things in backlogs at position 20+ that are never developed but suggest they are developed, reducing immediate pain ("No, we're not going to develop this") but trading it for long term pain ("No, it's not in the next Sprint").
Yes, aggregating bugs into an OMNIBUS or aggregating bugs into a feature as requirements is valuable too.
The reason people are so confused here, I think, is because to programmers, bugs are incorrect behavior of the program. These bugs exist whether they are reported or not. Removing bug reports does not remove bugs.
In other comments you mention "and we implement ways to not reach high bug levels again." Is it possible that from a programmer's point of view, you are actually enforcing proper use of the bug tracker? i.e., keeping graphic design opinions about line widths out of it.
You might be overgeneralizing, I have been coding for 40+ years, maintained several successful open source projects, fixed many bugs, created even more, wrote bug reports and have a Go IDE open right now.
https://news.ycombinator.com/item?id=28181575 - Closing 45% of the open Emacs bugs | Hacker News
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.
* 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.
Plus, it's all right there _in emacs_ with all its facilities and your customisations while you're using it.
M-x shortdoc-display-group string
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.