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

61–70 of 117 posts

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

#61

Post by veltas »

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…

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.

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

#62

Post by veltas »

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

It's not about experts vs. beginners. Some people just don't like that style of documentation.

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

#63

Post by lopatin »

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…

I absolutely do not want to know about the edge cases and subtleties of my editor while I’m programming something else.

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

#64

Post by bnj »

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…

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.

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

#65

Post by ThePadawan »

bee_rider wrote: post #54
ThePadawan wrote: post #41

Earlier quoted context omitted.

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.

The ambiguity of referring to both the undesired code behaviors and the tickets tracking those issues as "the bugs" is giving me PTSD, too.

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

#66

Post by falcor84 »

gpderetta wrote: post #43
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 a well known bug handling workflow known as the "CADT Model".

Thank you, this was a fun read

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

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

#67

Post by gpderetta »

falcor84 wrote: post #66
gpderetta wrote: post #43

Earlier quoted context omitted.

This a well known bug handling workflow known as the "CADT Model".

Thank you, this was a fun read 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."

Directly linking to jwz from HN doesn't lead to the expected result though :)

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

#68

Post by TacticalCoder »

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

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

#69

Post by kleiba »

lopatin wrote: post #63
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…

I absolutely do not want to know about the edge cases and subtleties of my editor while I’m programming something else.

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.

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

#70

Post by falcor84 »

gpderetta wrote: post #67
falcor84 wrote: post #66

Earlier quoted context omitted.

Thank you, this was a fun read 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."

Directly linking to jwz from HN doesn't lead to the expected result though :)

Sorry for being obtuse, but could you please explain what I'm missing. I hope to be one of today's lucky 10,000
Post reply on HN