Looks like since this was posted, the page author has closed another 10% of open emacs bugs: <a href="https://lars.ingebrigtsen.no/2022/01/20/13x10/" rel="nofollow">https://lars.ingebrigtsen.no/2022/01/20/13x10/</a>
> 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.<p>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.
This is from 2020. See also -<p><a href="https://news.ycombinator.com/item?id=28181575" rel="nofollow">https://news.ycombinator.com/item?id=28181575</a> - Closing 45% of the open Emacs bugs | Hacker News
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).
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.
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?<p>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.<p>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.<p>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>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><p>I couldn't disagree more.<p>I've done tons of Emacs lisp programming over the years, and IMO, the built-in documentation <i>rocks</i>. I find it at the exactly right level of detail for me: when programming, don't you <i>want</i> to know exactly about the edge-cases and subtleties?<p>Is it impossible to improve the documentation? Well, of course not. But as it stands, I find it pretty darn good.<p>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.