Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lars.ingebrigtsen.no

Post reply on HN
Print view View original

51–60 of 117 posts

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

#51

Post by kleiba »

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.

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

#52

Post by gpderetta »

chlorion wrote: post #42
okamiueru wrote: post #12

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…

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 installi…

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 should try eglot at some point.

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

#53

Post by peoplefromibiza »

AlchemistCamp wrote: post #7
Animats wrote: post #2

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

Just wait until you see how many bugs VS Code has!

~half of that

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.

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

#54

Post by bee_rider »

ThePadawan wrote: post #41
KingOfCoders wrote: post #16

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).

I'm calling Poe's Law [0] on this one. 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

The followup

https://news.ycombinator.com/item?id=32734254

even retains the ambiguity. Magnificent.

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

#55

Post by KptMarchewa »

kleiba wrote: post #51

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 ov…

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.

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

#56

Post by [deleted] »

kleiba wrote: post #51

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 ov…

[deleted]

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

#57

Post by krmboya »

kleiba wrote: post #51

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 ov…

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

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

#58

Post by gjadi »

krmboya wrote: post #57
kleiba wrote: post #51

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 ov…

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

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.

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

#59

Post by cma »

KingOfCoders wrote: post #16

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).

Boeing?

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

#60

Post by kjetilho »

kqr wrote: post #50
KingOfCoders wrote: post #16

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).

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 stres…

Thanks, this was very useful.

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.

Post reply on HN