https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21526

In general, I find too much emphasis is now on "closing" an issue as soon as possible. I understand that open issues can be a burden for maintainers. However, filing issues, especially making them reproducible, can also be a burden to users, and users will stop filing issues if too many of them are closed unilaterally without actually correcting the root cause.

As I remember it, the Emacs maintainers used to put a lot more emphasis on actually correcting issues instead of only closing them, and this may also be the reason why fewer issues are reported now.

A great attraction of Emacs is how easily one can actually report issues, using Emacs itself: M-x report-emacs-bug RET.

> I'm going to go ahead and guess that the problems discussed were fixed, and I'm closing this bug report. If there's anything more to be worked on here, please send a mail to the debbugs address and we'll reopen the bug report.

I don't think this really qualifies as "ignoring". Having read the last two messages or so, their approach looks totally reasonable to me. Please don't scold maintainers for cleaning up? :(

Assuming the STR is clear, is it the original reporter's responsibility, or the developer's, to confirm if a bug is fixed or not?

It was five years later that someone came along and closed the bug.

After that I’m usually satisfied the bug has been fixed. So I will link the git commit hash of the fix to the bug report and ask the reporter if it fixes the issue their side. If I don’t hear anything back after a week or two I will follow up with a message much like the aforementioned: “closing this ticket because I believe it to be resolved but happy to reopen if you’re still experiencing issues.”

That is the only way I’ve found to manage projects because you either end up closing tickets prematurely and miss bugs, or you end up with tickets open for fixed issues that take time and additional mental overhead to filter out (both of which are a scarce resource when you’re trying to balance open source maintenance with a full time job and a family).

Two weeks might not seem long but I’m always happy to reopen issues. However if users really feel that hard done by this approach then they’re welcome to submit a pull request instead. Or even fork my project and maintain that they way they feel it should be done. Maybe they’ll have more free time than me to filter through historic issues that are now fixed but not closed between their personal lives and coding time.

This tacitly embraces the bugtracker-as-helpdesk/CRM mindset, i.e., the GitHub approach, which is what leads to things getting so chaotic and unwieldy in the first place. It's right in the language—focusing on "their" issue. Both maintainers and users need to approach the bugracker by recognizing that the scope of any given bug report is the bug, and by extension the project, not the bug reporter or maintainer. By the time a bug is being closed, a maintainer should know (at least with some level of confidence—but allowing for them to be wrong) whether the bug is fixed or not—because it should be well-defined. If the maintainer is not able to do this with confidence, it indicates a failure in the practices for handling bugs—and possibly (or "likely", in the case of a typical project hosted on GitHub) muddled scope.

It may be the case that from the user perspective, they're still experiencing some issue, but this doesn't call for the bug being reopened to handle it. Remember, it's not theirs, it's the bug's! If the last report led to a real bug being identified, and it really was fixed, then leave it closed and figure out if it isn't the case that they misidentified the source of the discomfort they were experiencing, and if so, have them attempt to articulate it, then open a new bug for that. Otherwise, you're just treating your bug tracker like a message board but splattering it with state changes of what amounts to your personal TODO list—where "open" and "closed" correspond to whether you've decided you're finished with it or not. Remember not to think of the bug tracker as yours either! It belongs to the project and its bugs. Think of the software as a non-human entity and you as a scientist and its designated caretaker. It's best to think of the bug reporter as a scientist, too—and the elevated expectations and responsibility that comes with it.

It's an observable truth that if you want people to use your software, it's necessary to prioritize pleasantness. It's also practically a logical necessity, unless your user community is comprised of individuals who enjoy being displeased and otherwise frustrated.

At some point, you have to close things. Chances are they were spurious, have been fixed or made irrelevant (maybe the code no longer exists) or nobody cares.

And if someone does care and it's still an issue, you can reopen. It's not as if you are permanently deleting all the information for the rest of time.

If it's still an issue with our internal customer [0], they can reopen the ticket or open a new one. But we've completely rearchitectured our systems since the ticket was first opened, our internal customer has changed leadership and has had considerable staff turnover, and not a single person has brought it up in our biweekly meetings with our internal customer for ages, so we might as well just close it out.

[0] when I say "customer", I'm talking about a department, not a single individual

In the majority of cases, there's another project that I can move to and I do so as soon as possible.

There are presumably others like me. So when you say it's sustainable, you may not be accounting for the reputational damage it does to your project, which you will almost certainly never be made explicitly aware of because users know it's not worth their time to file bugs.

As an observation, the whole thread is a back-and-forth exchange of a user supplying incidental test cases and the dev fixing them one by one, for months. I'm actually surprised the main emacs maintainer would put up with this - usually formatters and syntax highlighting are handled by user extensions, it's not humanly possible for one person to be an expert in 100+ programming languages and their favored styles. Someone else who is a heavy user of the language could take the time to dive in and probably fix all the formatting issues in one go. Or make a patch to bring in the third-party better-maintained prolog-mode that is mentioned in the discussion.

It is definitely nice that the Emacs maintainers corrected some of these regressions which I explained in this issue with steps to reproduce them. However, the information from 23 Nov 2015 that 2 out of several regressions I had reported in this issue are now believed to be corrected does not solve the other issues I reported in the course of the discussion and which still remain. It is easy to reproduce them with the instructions I posted in case someone is still interested in correcting them. Alternatively, one can simply use the third-party mode which does not have these issues also because I had previously already contributed changes to specifically address some of these issues in that original version of the mode.

The key reason for the divergence between these two versions of the same original mode is that Emacs maintainers prefer to use SMIE-based indentation for the mode, and switching the mode to SMIE in the Emacs trunk introduced the reported regressions. SMIE is an indentation and navigation engine that the Emacs maintainers provide. My impression from the discussion in the cited issue is that SMIE is lacking some of the features that are needed to implement the desired and previously supported indentation and navigation for this particular mode. There may be a way to improve SMIE to support these use cases, it may be quite hard though: I expect that if it were easy, these changes would have been made by the Emacs maintainers to solve the remaining issues too in the last few years.

The second to last post says they believe the issue is fixed, with nobody complaining it isn't fixed for the 5 years after. I guess that doesn't seem like a great example of "they closed the bug without ever fixing it".

I also dislike how your post is written to suggest that this was how the maintainer is closing many bugs, except you give one example which is your bug. This seems more like you are on some crusade because you don't like how your bug was handled.

I used this specific example to illustrate the general point I was making, and I took an issue I filed myself because I know for certain that it still persists. You will find other issues in the Emacs bug tracker (such as https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45577) that follow the same general pattern, but where in contrast it is somewhat unclear if the issue is now solved or not, and therefore I did not cite such an issue.

Another example, an issue which I also filed and which was closed even though the issue still persists:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35005

It is true: I do not like how these issues were handled, especially that they are closed without actually solving them. The Emacs bug tracker is also not like the one on Github, you have to control it with dedicated email messages. In fact, I would have to look up how to even "reopen" an Emacs bug, it is not very clear to users, and this makes it especially frustrating if issues are closed without solution.

My impression from several years of filing Emacs issues is that issues are currently closed prematurely more often than was previously the case. Maybe this impression is amplified by the fact that Emacs has not even had a dedicated bug tracker for a long time, so issues were never really "closed", but the discussion simply petered out.

At the top of your bug report, it says:

    To add a comment to this bug, you must first unarchive it, by sending
    a message to control AT debbugs.gnu.org, with unarchive 21526 in the body.
    You can then email your comments to 21526 AT debbugs.gnu.org in the normal way.

Disclaimer: I did not read all 146 messages.

> "OK, let's turn things around, indeed: we revert to Stefan Bruda's indentation code, you're handed responsibility over that code, and I get to send you the bug reports about all the regressions this will introduce."

It's not clear if that's meant genuinely or frustratedly and sarcastically, but it's taken genuinely and Markus Triska replies: "This would be a good improvement in most respects I consider important, thank you! I will treat all issues you and others send to me with great care and attention, and work on correcting all regressions and issues I can. I have a lot of experience editing Prolog code with Emacs and can spot regressions quickly."

Followed by Stefan Monnier apparently not doing that, and fixing two (of many) issues raised and discussed. (Perhaps he considered it handed over and that the next action would be patches from Markus Triska?) Then 5 years later Lars (who wasn't involved in it?) closing the whole thing without reading it in detail, taking that as "whole thing fixed".

It's not too far from Zawinski's "Cascade of Attention Deficit Teenagers" model[1] of open source bug reporting - they go unread for years, then get closed with "if it's still a problem, make a new bug".

[1] https://web.archive.org/web/20210311012401/https://www.jwz.o...

That's the outcome of metrics-driven development. Getting to 0 open issues becomes the goal, and not the effect of having less buggy software.

I personally despise the GitHub "auto close" bots. Some issues take a very long time to even reproduce, and the constant nagging to close really encourages a culture of "if it can't be easily fixed, it doesn't matter" --- which nicely correlates with the state of a lot of new software today: all the basic stuff works, but there are lots of obscure, almost edge-case bugs.

This is only true if you are talking about customer-service style exchanges. With bug trackers for open source projects there can be and often is quite a bit of effort put in narrowing down the bug by the reporter or other users and sometimes the fix ends up trivial and obvious to the developer after that. I agree with closing stale bugs that have had no interaction or quick way for the dev to check if the problem is fixed (after years, not weeks) - they can be reopened after all - but dismissing the effort by done by users to report bugs in the first place should not be your justification.

If you are looking to reduce number of issues, you are on the right track, because now not only you have closed a bunch of them without putting much work into it, but less people will be bothered to document and report their issues.

So you triage your bugs into roughly the same size chunks. You measure how many of the issues you deal with per month. You prioritize the issues. If you have more issues than your monthly velocity, you close the lowest priority WONTFIX because, well, they will not be fixed. But nobody does it this way for public projects, because then they have to deal with entitled people who want their priorities to supersede your priorities, and instead you end up with an eternally growing list of bug reports that are harder and harder to maintain. And try other approaches to make it maintainable, such as making it harder to report bugs.

Bugs won't fix themselves due to not talking about them. If you want to close a report, have a human check if the reported misbehavior does still happen, and close the bug if not (or if no way to reproduce was found). Projects seem to forget that issue reports are reports on defects of their code, so they should be the first interested in fixing whatever is wrong.

I'm the kind of user who takes the time and effort to report bugs (and I'd say that already puts me on a small % of users). But when I see these "closed because of no activity", I just say "F.U., really" and go away.

https://emacsconf.org/2020/talks/38/

There's a new portable undump in emacs 27

https://www.masteringemacs.org/article/whats-new-in-emacs-27...

a couple of examples of very core features off the top of my head

Fantastic! Two birds with one stone!

You’ve never done that at work? In every company I’ve worked for, nobody would bat an eyelid at dropping an issue that hasn’t been touched for more than a year

Developers absolutely should be testing for the issues they know about. QA is there to look for unknown issues.

Any company that depends on QA for testing and doesn’t make devs to it is miserable to work for (both as a dev and a QA).

Dont just push code and expect others to point out your flaws. Take some responsibility.

Were all problems fixed? Almost certainly not. Many will have become overcome by events, though. The ones that are still pertinent will reopen.

Such that anytime I see a large percentage of bugs closed like this, this reflects more on working in the ticketing system than it does on fixing the problem it is managing.

They report something. You badger them for six weeks to collect enough information to reproduce it. You fix the problem and slate it into a release and make it available. They don't take the release for another seven months.

I've done this several times and it's magical how you end up losing almost nothing important in the end. I think it works because if something is important enough you'll either remember it yourself or it will be communicated to you again, perhaps even via a "higher priority channel" such as the management chain.

And if you think I'm being extreme then yes, maybe, but maybe you haven't yet drowned in the never ending stream of problems for a long time.

I've also lead many mass bug closures. Most stale bugs just need a ping or a friendly closure message. The cost to reverse a wrongly closed bug from a bug cleanup sweep is zero, and in the off chance it ignites interest in some other party still paying attention it at least signals intent and starts a conversation.

Except when maintainers decide to lock the bugs automatically because Reasons.

Nothing screams contributor hostility as much as that.

Now when I get requests from those people, they go immediately to the back burner. If I hear nothing more, they get closed; if I get followups then maybe it is something they need after all.

It's easy for people to ask for others to do things. But many people are scatterbrained and can't prioritize, and can't see beyond their own immediate needs and how their requests might impact other work. Rather than try to demand some realistic sense of priority for these requests, this approach lets the urgent stuff bubble up naturally and the rest of the chaff sink to the bottom.

But, should they even care? Maybe they think it's not their job?

What I mean is, there seem to be two archetypes of ways to ask someone else for something. For lack of better terms, I'll call them "market approach" and "social approach".

"Social approach" is when you try to predict how costly your request will be to the other person, and only ask them if the importance is clearly much greater than the cost. You then expect the other person to feel compelled to prioritize your request, as they know you wouldn't be asking if it wasn't very important.

"Market approach" is when you don't give any thought about the cost to other party - you just make your request, and expect them to tell you whether they'll do it, how long will it take, and what they expect in return. You then negotiate the scope of the request and the "price" until both sides are satisfied, or the request is rejected.

I don't know which one is better. But I think we're living the worst case: everyone operates at a different point between these two idealized approaches. So, in your example, you're taking the "social" perspective - you treat requests as high priority ("they wouldn't have asked if it wasn't important") and get annoyed when your hard work isn't used. Meanwhile, those people may be operating closer to the "market" perspective - perhaps they expected you to push back on their request if it's disruptive to you, and were willing to negotiate (they knew it wasn't that important, but they didn't expect you to assume it was).

This model does explain the different sides, but the problem remains.

So it seems that the problem with the requester’s market approach is that there is no mechanism for setting value. So how do we solve that?

That is a common occurrence - which makes it dangerous for either side to make assumptions about the other.

So the more I think about it, the more I feel that it's the "market approach" that's better-suited for work requests and issue reports, when the two sides don't have a preexisting personal relationship. "Market approach" is assumption-minimizing, and thus also mistake-minimizing.

On a side note, I wonder if that's what "rejection therapy" and assertiveness are both about: they're trying to teach you to ask people more (instead of assuming they'll say no), not take rejection personally, and to be ready to just say no to other people. Taken like this, they sound like attempts to correct people into using "market approach" where they tend to use "social approach".

> So it seems that the problem with the requester’s market approach is that there is no mechanism for setting value.

I think this is not a problem at all. That's why I called it "market approach" - the market is the tool that's used to determine value.

I should get better at recognizing which of my partners are on the social strategy and who prefers a more market-based one. Probably all of us should learn this skill.

Note (for your forthcoming tweet storm, apparently) that just these evaluation steps could be pretty time-intensive for the other party in the first place.

It’s simply easier to make a request, than it is to resolve it. The cost of filing an issue is greater than the cost of resolving it.

This is why schemes like “you can only file your top 3 issues” make sense. Forcing the end user to prioritise their top issues - and to manage the ones that don’t make the cut - distributes the triage work more fairly.

We have a job to do too and it’s a waste of developers time to force us to guess what’s important to an end user. That’s their job.

The social vs. market perspectives are interesting though, I had not thought about framing requests in this way, and I'm going to try to keep that in mind in the future.

Nowadays I understand … it’s the a way to keep sane and to see what matters. Mainly in companies that have been around for decades with multiple products and many many people..

So, this doesn't always work, it can just be a way to kick the can around, and end up in the same place but with lots of extra junk flying by.

it felt pretty good.

With all due respect, this absolutely is not the only outcome. I'm going through this right now with UniFi and Ubiquiti, which has been a raging development dumpster fire for years now though the rot has only really started to become critical and more generally obvious the last year or two. UniFi is full of very important bugs, issues, and missing or badly implemented core functionality. But, like many many others, after devoting a lot of time to detailed bug reports and figuring out how to make it reproducible and extensive work helping identify how to meet standards that all got closed/ignored or even actively got worse?

I simply don't give a flying fuck any longer. I'm not "re-filing" (of course, they've dumped even their minimal mediocre old feature/bug tracker anyway with no replacement, but I don't make new threads either). I mostly don't bother anymore with reporting anything UniFi at all. Instead I've been steadily migrating away entirely. For me, UniFi is now in a completely subservient role, still doing a certain amount of switching and WiFi but with 100% of core network functions, routing/gateway coverage etc moved to OPNsense. As the time comes to get new gear anyway for WiFi 6E/7 and more multigig switching that'll be the end of it for my ~100 pieces of kit.

Of course companies/projects are free not to care, and depending on what sort of goal a project has or what sort of lock-in/stickiness and core revenue areas a business has it may indeed not matter if there is an exodus of small/older users/customers. But it shouldn't be assumed in every instance that "if this is really important someone will poke us again" because everyone only has so much time themselves to poke you, and if word gets around that it's pointless to even try than that will be the last you hear from them until they're gone entirely. IMO, the true terror for many business/projects shouldn't be criticism, it's silence. When people simply don't even care enough to even invest the time to get mad anymore.

But as someone with a long QA experience, sometimes I'm so disappointed in the 'no one bothered me, it must be bothering no one, close'. What about the time and effort of the person who described a defect in your system? Don't you want people giving you clear, researched bug reports? When you close their issues, although there CLEARLY is a problem and the ball is CLEARLY in your (sw dev) team, I feel like you're saying 'don't give me precise, actionable bugs'. That's what I'm hearing anyway.

And soon enough you get the eternal dev complaint about how 'no one fills tickets properly' and the 'no one opens issues anymore although they face clear annoying bugs' with heavy faulpelz connotations... Well you reap what you sow.

I'm not saying the project has infinite resources and that you should fix all issues all the time... I actually understand the real world tradeoffs. But put them on a special list, like knowledge database, known-bugs, not 'closed until some annoying piece-of-work busybody complains', and try earnestly to fix one once in a while, I even had a principle when I was team lead, to correct at least 5 more-than-2-years-old issues (or add a 'red' test for that bug). After all with tech turnover, those often make great onramping tickets.

And I can testify to the sheer joy of having one of your 'low priority' issues fixed, even 2-3 years later. 'hey I know it's been a long time, and we're not sure it's still annoying to you, but anyway we managed to reproduce on the latest version and we put a fix in place, let us know if you want a nightly to double-check or wait until next release'. Even though it doesn't show on SLAs, I do put in a word when renewal time comes around (even more now that I have a small bit of clout).

(Surely there's a lot more details to specify to make this a reliable bargain.)

Currently for me its neovim. What the maintainers and contributors have done is exceptional. They've breathed new life into vim (through neovim) and pushed forward broader (neo)vim development.

They did (and do) a great job of setting up their goals and achieving them. Most notably with their recent .5 release which adds support for first class Lua, native LSP, native Treesitter support, and more.

> 50% of newly reported defects are solved in under a month, 90% in under 3 months

I don't need a commitment like this. It would add unnecessary pressure to complete something that may need more time. I feel like this would follow Goodhart's law[0] and end up leading to overall worse development progress.

[0]https://en.wikipedia.org/wiki/Goodhart%27s_law

Prerequisites:

1. Maintainer has expertise about the project.

2. Connection with users and knowledge of their needs and of their willingness to pay.

3. Ability to estimate project's demands in terms of effort and expenditure, given a set of objectives. (This is just a part of an expertise really; often overlooked, but crucial here.)

Step 1: Based on the user needs, the estimates, and maintainer's other realistic earning options, calculate financial goals.

Step 2: Run the funding campaign.

Step 3: Refine the prerequisites, repeat the steps.

All abstract and hypothetical here of course.

I would love to be in such a situation... Unfortunately, I don't have a start up to sell so I'll be a slave all my life and won't have the opportunity to work full time for a non profit project that I love. Dies irae.

With Nix, it's amazing to be able to just run (on macOS/Linux)

  nix develop nixpkgs#emacs

Here are my thoughts on what is needed for emacs to have a real future in the 21st century:

1. We must create a strong community of highly-skilled programmers who use Emacs for their work, for it is out of this community that emacs contributors, developers and maintainers will come.

2. Therefore Emacs must be first-class for day-to-day programming work.

3. This means LSP. I think it means taking some lessons from VSCode: i.e. not being a traditional IDE, but having first-class LSP functionality in all common languages.

4. It probably also means being able to follow VSCode's lead in remote container-based development.

5. The emacs development community needs to become less of a weird argumentative place. The points above will help because it will have more representation from programming traditions other than lisp.

6. Development should move to something like Github/GitLab, i.e. with PRs, not emailed patches.

7. The memory of Stallman and the FSF should not be forgotten but their opinions should not be given any special weight. E.g. on using a non-free platform like Github/GitLab, and on supporting MacOS.

8. Things like org-mode and gnus are a distraction: emacs core should focus on programming modes. If it would help focus emacs development on programming modes to severely trim the core, then let's do it, and move these things into packages. org-mode is very popular but too unfocused to be in core. gnus is great but the next generation aren't going to use it for their email.

9. We should kill the idea that it's desirable for projects to become part of core. It's not desirable: it makes it extremely hard for people to contribute to those packages due to FSF papers and email/bug tracker workflows that are totally alien to contributors and not as good as more modern workflows, and it makes the emacs bug tracker unfocused.

10. We should not think about making emacs popular and instead just focus on making it excellent for programming.

> Things like org-mode and gnus are a distraction: emacs core should focus on programming modes

Emacs can and has been doing both of these for a long time. Emacs is unlike anything else out there because it empowers the user, who does not need to be programmer. The popular Helm package is maintained by a mountain climbing trainer for almost a decade. We want more of such users. We want more casual users who, during their Emacs journey will get encouraged to start tinkering and then become programmers.

> on using a non-free platform like Github/GitLab, and on supporting MacOS.

MacOS is already supported, as I understand. Github/Gitlab advice zounds nice, but we have to zoom out on this. Emacs is older than most programmers out there. It is older than git and bazaar. Using Github/Gitlab sounds nice, but it locks you in. Besides, Email is ubiquitous. If you have a network connected device, it can probably send/receive email.

> We want more of such users. We want more casual users who, during their Emacs journey will get encouraged to start tinkering and then become programmers.

Yeah, I do see that view. I just wonder whether we need to make some tough decisions in order for emacs to survive. Specifically: although emacs is wonderful for tinkerers and non-programmers, what it actually is is a lisp execution environment powering a text editor. When described like that, it's pretty clearly a tool for programmers and expert / adventurous ones at that. I think it might be best to embrace that: it's great for others to join the ride but, sadly, not the raison d'etre of emacs. Better to focus on making it very, very, good within a well-scoped area.

> MacOS is already supported, as I understand.

Stallman et al. have refused to accept into core various patches that are required to make Emacs great on MacOS. For example, native MacOS SVG rendering software is not supported. This is why the Mitsuharu emacs-mac fork [0] exists and is so loved. The reason they've refused to accept those patches is because their inner 14-year olds don't like "companies that make money" and so don't want to accept patches that give "for profit software" an advantage over "free software".

> Github/Gitlab advice zounds nice, but we have to zoom out on this. Using Github/Gitlab sounds nice, but it locks you in. Besides, Email is ubiquitous.

I guess we have to agree to disagree there. My claim is simply that PRs are a technological advance over email review. The fact that Emacs uses non-PR based development makes me not contribute to them. Emailing patches is absurd: a patch is a thing that exists in a code lineage; it has a parent; it's not an entity in its own right. There are many things that are ubiquitous but not the best choice!

[0] https://bitbucket.org/mituharu/emacs-mac/src

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

>Bill was probably referring to what RMS calls "Evil Software Hoarder Emacs" aka "UniPress Emacs", which was the commercially supported version of James Gosling's Unix Emacs (aka Gosling Emacs / Gosmacs / UniPress Emacs / Unimacs) sold by UniPress Software, and it actually cost a thousand or so for a source license (but I don't remember how much a binary license was). Sun had the source installed on their file servers while Gosling was working there, which was probably how Bill Joy had access to it, although it was likely just a free courtesy license, so Gosling didn't have to pay to license his own code back from UniPress to use at Sun.

https://en.wikipedia.org/wiki/Gosling_Emacs

>I worked at UniPress on the Emacs display driver for the NeWS window system (the PostScript based window system that James Gosling also wrote), with Mike "Emacs Hacker Boss" Gallaher, who was charge of Emacs development at UniPress. One day during the 80's Mike and I were wandering around an East coast science fiction convention, and ran into RMS, who's a regular fixture at such events.

>Mike said: "Hello, Richard. I heard a rumor that your house burned down. That's terrible! Is it true?"

>RMS replied right back: "Yes, it did. But where you work, you probably heard about it in advance."

>Everybody laughed. It was a joke! Nobody's feelings were hurt. He's a funny guy, quick on his feet!

[...]

See the following for example:

https://stackoverflow.com/questions/30151338/org-latex-previ...

https://www.reddit.com/r/emacs/comments/4n8p5i/emacs_org_mod...

https://github.com/politza/pdf-tools/issues/51

I get it, the diverse userbase of people from all walks of life using this crazy lisp-based editor from the early 80s is cool. But it will fizzle out if it is not loved and used by the next generation of professional programmers (well, this generation of under-40 professional programmers).

There are well over a million lines of Emacs Lisp code included with Emacs (a million and a half, last time I checked), and most of that is for things that the average user won’t need right away, or won’t ever need. The goal is to make Emacs (and by extension Free Software) comprehensive, not to limit the amount of work that the maintainers might need to do. The work they do is naturally limited by the amount of time that they have in a day, so of course it falls to the rest of us to chip in from time to time, especially with language–specific modes where the maintainers may not use that specific language themselves.

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

I have to disagree at 1) the assertion that it's cost free, and 2) it will prevent people from filling it again

re: 1) - it creates clutter, which at least to some individuals like myself, can be costly in the form of being overwhelming/frustrating/obstructive/etc. YMMV on cost:reward on keeping issues open indefinitely. There are other solutions like filtering, but if everyone is filtering out untouched issues, there's not much difference from closing it.

re: 2) is predicated on issue creators actually searching the entire backlog for a pre-existing issue, which they may or may not find.

I certainly agree that the issue itself should be kept in the tracking system, and continue to be able to be viewed and referenced for the reasons you state. Also consider that issues can be reopened if they were closed in error.

Seriously, go through the fine tutorial and just start exploring it. No matter what you put off for doing that, it will be worth it.

https://orgmode.org/worg/org-tutorials/orgtutorial_dto.html

In my experience, this has a huge positive impact on performance, and can make Emacs feel a lot faster, smoother, and more responsive. Others say it doesn’t yield a noticeable difference for them, but on both of my machines it’s quite noticeable.

LSP support (Language Server Protocol). Basically any language / file format for which a LSP backend has been written can now be used from Emacs.

LSP is not as powerful yet as, say, IntelliJ IDEA for Java development but suddenly the line between "text editor" and "IDE" for Emacs got much, much, much more blurry.

SLIME already did this to Emacs like twenty years ago.

I feel like most complex-enough projects are not in a situation where there's the time, resources, or motivation to fix everything. I can't think of any real examples where this isn't the case.

If it's a commercial company resources are the concern because achieving perfection doesn't really pay the bills or justify the staffing. In open source, motivation is really the currency and the people who are motivated to fix tens or hundreds of bugs are rare and at high risk of burning out if they attempt to fix everything that comes in.

I just think the upshot is that there's usually a significant number of bugs (or usability issues, quirks, whatever) that are not going to be fixed unless something major changes in the project. Directly acknowledging that seems good, whether closing them or otherwise marking them. Keeping it all open seems like the equivalent of keeping a basement full of junk in the off chance you need each bit in the future.

I'm not sure what the alternative is. Shutting down the project?

This is not a way to assert a bug is fixed. Success looks like actually trying the code in the bug report that demonstrates the bug, and/or contacting the report participants, to confirm that the bug is actually fixed for the participants.

the point of a bug report is to let you know something is going on, to provide context useful in tracking it down, and tracking for the eventual resolution.

as they years tick by, some bug reports are counterproductive because they are unclear, dont give _any_ diagnostic information, or are no longer relevant because the codebase has shifted.

its great to say for each of these issues we should spend a day or two trying to reproduce them - but its really not the best use of time.

we're not talking about capriciously trashing useful bug reports. we're trying to lower the noise floor so that the actionable bugs stand out and are more likely to be dealt with.

- if the issue lead to a commit, or a merge is mentioned in the thread, then it is actionable,

- if the issue was closed without any code change, then it is noise.

and I bet your AI isn't going to be able to say 'oh yeah, thats just that thing we fixed in 2.1'

seems useful in a second-order capacity though - process introspection

Sure for commercial situations you expect the customer to sign off on a fix but a maintainer's responsibility in open source is exactly 0. Even having a bug tracker is an affordance from the maintainer, GitHub supports turning issues off.

I'm going to continue to terminate old issues where the problem described was vague or the reporter has gone AWOL and I would encourage all OSS maintainers out there to do the same, let's manage expectations.

I personally think that's fine. You'd have the time to verify and close every issue in a perfect world, but the world rarely is. Before that we had 100+ issues open with bugs we could not even reproduce that where open for years. It just becomes clutter at that point.

I assumed that he just wanted a reason to include at least a _little_ elisp. (Though, even so, he could at least have run the calculation recursively; in Raku, I'd probably have written

  (-> $_, $i { $i ?? &?BLOCK($_ × .9, $i-1) !! $_ })(100, 10)

  (cl-loop
    for sum = 0 then (+ sum (* total 0.1))
    for total = 100 then (* total 0.9)
    repeat 10
    finally (return (list sum total)))

Here's an old rant from 2013 that Xah Lee archived and replied to, but that he didn't agree with, but that the late Mark Crispin covered in his own rant in 2011:

(TLDR: Don't try to change emacs into Microsoft Word without understanding why it is the way it is, don't change long-standing essential defaults out from under people, and don't break type-ahead and keyboard macros.)

https://wilkesley.org/~ian/xah/misc/Don_Hopkins_Mark_Crispin...

[Don wrote:]

>The wrong people have been drunkenly driving Emacs into the ditch for the past decade or so, and they're really screwed it up in so many ways, usually trying to be way too clever and solve problems that really aren't worth solving.

>They made “line-move-visual” the default, which in the service of making Emacs behave more like Microsoft Word, it makes ^N and ^P across wrapped lines stay on the same line and move to the part of the same line that is wrapped above or below the cursor, totally breaking type-ahead predictability and keyboard macros. That totally pissed of the late and long time Emacs user Mark Crispin, and he explains why it's such a terrible idea that breaks keyboard macros: http://compgroups.net/comp.emacs/line-move-visual/274792

>It totally breaks keyboard macros, one of the most important things about Emacs. It definitely should not have been made the default, since keyboard macros are a way of life for real emacs hackers. I totally agree with Mark's take on the problem, and I am terribly disappointed that RMS let somebody get away with changing it that way, and making that horrible mode the default.

>They just can't stop trying to make it more like Microsoft Word, while failing to actually achieve that goal, and only succeeding in inflicting half-assed solutions with harmful unpredictable side-effects on the users.

>Another example is how the region highlighting and the weird pending delete behavior terrorizes me that sometimes but not all the time according to rules I just can't figure out or tell by looking at the screen, when I type something that I intend to insert, a huge chunk of my buffer might just disappear, but sometimes it doesn't. So now Emacs has become unpredictable and malicious. I have to do a dance of “insert character, undo” to know that I have canceled the pending delete mode. You can't tell if you are in pending delete mode just by looking at the screen and seeing the obnoxious highlighting, because sometimes it highlights the region and isn't in pending delete mode, and sometimes it highlights the region and is in pending delete mode. I just wish it would stop highlighting the region, because any time I set a mark and move around, it highlights half of the screen at no use to me, and that just gives me a headache, and I have to insert a character an undo it to cancel the highlighting, and until I cancel the highlighting I am living in terror that my next keystroke will delete a huge unseen portion of the buffer.

>And the thing that REALLY pisses me off is the lame-assed attempt to make ^A and ^E ignore the prompt in shell mode. There is an extremely simple reliable solution to the problem of separating the prompt from your input in shell mode so you can always get to the beginning of the line with ^A, and that is to have a newline at the end of your prompt, so every line you type in is on the whole line and does not have a prompt prefix, therefore no half-assed magic is necessary.

>But the half-assed magic is terribly implemented and has bizarre side-effects that screw me all the time: I get these fucking invisible force fields inserted into the line between my characters whenever I yank some text onto the line that has a prompt or a command line on it, and I can't move past them with ^A or ^E (but sometimes I can — they're not predictable which is even worse)! And I can get any number of these fucking invisible force fields on my line, so in order to get to the beginning of the line I have to go ^A, look at the screen to see if I made it, type ^B ^A if I didn't, again and again, until I drill past all the invisible force fields that are trying to make my day happier.

>And then I have to mark the beginning of the line I want to edit and repeat, go to the end of line by drilling back some number of opposite facing invisible force fields (which may be in different places than the ones going the other direction), and then kill the region, go to the end of the buffer, then yank the entire line to get a copy of it without any fucking invisible force fields in it.

>But if there is an invisible force field in the line, or I just want to edit a few characters of the line and that adds some invisible force fields that were not even there before, and then I hit return in the vain hope of re-entering the entire line but not the prompt, it just enters the tail of the line after the last invisible force field, making an error in the shell, or sometimes even executing a totally different command than I intended and totally fucking me over.

>I would really like somebody to explain what the fuck the idea behind the invisible force fields are, and give me the address of whoever thought is was such a brilliant idea, so I can send a robot drone to firebomb their house, or worse yet send RMS to live with them for a few months. Why did they do something so terrible, that totally fucks up such common important operations, to solve a trivial problem that has a much better solution?

>Emacs used to be totally predictable. I learned it at 300 baud over the ARPANET on ITS, and I could type ahead hundreds of characters to do all kinds of stuff, and then go take a piss or get a drink or take a bong hit, and come back later, and it would be in exactly the state I meant for it to end up in. Now, I can't do that even on a local display. And for some fucking reason, it waits for up to five seconds sometime before updating the display when I'm running it in a terminal (especially when I start an incremental search or query replace). What the fuck is that about??! Not only is it totally unpredictable and forces me to stop what I'm doing and wait for it to catch up so I can figure out what state it guessed its way into before going on, but it won't paint the screen for five seconds when running on a modern top-of-the-line computer!

>Emacs has become a shrine to outrageous violations of the principle of least astonishment. I just can't figure out how they could have come up with so many ways to corrupt it, when it used to work so well. It's totally unpredictable now, and I can't type ahead any more, so I have to type a few characters, look at the screen to see how it misinterpreted my intentions, and then try to work around the misunderstanding.

https://wilkesley.org/~ian/xah/misc/Mark_Crispin_emacs_line_...

[Mark wrote:]

>emacs line wrap rant by Mark Crispin 2011-06-03

https://groups.google.com/d/msg/comp.emacs/Q1SeBV1kkIs/vmY_e...

>What mindless cretin thought that it should be a good idea to make line-move-visual be the default in emacs 23?

>I just found out about this charming "improvement" in the worst possible way. Investigation determined that a "routine" software update had just installed emacs 23 and gave me this "improvement".

>People wonder why everybody hasn't dumped proprietary desktop software. This is an example why. Emacs' line behavior has well over 30 years of history, and some bagbiter goes and changes it BY DEFAULT.

>Add all the cute new features you want. But leave the goddamn defaults alone.

>If you want to have your own playpen where you twiddle defaults to your hearts content, have at it. But don't pretend that you produce software for a production environment, and stop telling the Linux distributions that they should "upgrade" to your "improved" versions. People doing real work depend upon those distributions.

>It does no good to say "read the release notes" when the affected users don't get the release notes and don't even know that a new release happened. It is also unreasonable to expect users to subscribe to every obscure newsgroup, forum, and wiki to hear about changes that will turn their expectations upside down.

>Yes, I fixed my .emacs file. And I'm putting in the same change to all the .emacs files on all the dozens of other machines I use, even though they still have emacs 22, because otherwise this unpleasant surprise will repeat itself over and over again.

>Grr.

>>On Thu, 3 Jun 2010, Uday S Reddy posted:

>>I am not taking sides on the line-move-visual issue. But I do know that it was a complex decision for the Emacs developers and it wasn't made easily.

>They made the wrong decision. Changes to default behavior are a bad idea. Changes to default behavior of the most basic functionality are an extremely bad idea.

>I don't care if M-X fart-noisily-with-spray changes its default scent from skunk to lemon. But I damn well do care about the most basic operations: all CTRL single letter and ESC single letter. After 33+ years of using emacs, I expect these to be reliable and not suddenly change.

>I wasted hours trying to figure out what the hell was wrong with my file, or my terminal emulator window, or my system. The fact that the problem went away on a different system added further confusion. It was only when I did ESC <n> CTRL/N and saw that it moved me the wrong number of lines, but only on one system, that I realized that emacs changed. And that's when I did ESC X describe-key CTRL/N and read about line-mode-visual, although it did not mention that this was now the default.

>Surprise. Grr.

>>However, I am concerned about downstream distributions that omit the release notes. That seems to be a real disservice to the users.

>So I find a system with the release notes. And the reference to this incompatible change is buried 300+ lines deep, after numerous pointless entries such as emacs having a character set 4 times bigger than Unicode.

>-- Mark --

>>On Fri, 4 Jun 2010, Tassilo Horn posted:

>> But all visual line behavior break keyboard macros. Define a macro, then change your window size (so that lines are differently visually wrapped), and bang your macro messes up your text. It's semantics change with the frame/window size. That's silly.

>This is precisely how I got screwed by this incompatible change. But the change in behavior also confused the hell out of me. Almost all of my editing is C source code.

>>Because keyboard macros are important to me, I set line-move-visual to nil.

>Yes.

>-- Mark --

[Don writes:]

To be fair, Xah has written his own pro-line-move-visual rant:

https://wilkesley.org/~ian/xah/emacs/emacs_line_move_visual....

I respect Xah's position, and he wrote a lot interesting text and links and emacs history and learned opinion, but I won't quote it here, because I still disagree with him, and he doesn't address the fact that line-move-visual BREAKS keyboard macros, and keyboard macros are one of the most important reasons and powerful techniques for using Emacs.

But I quoted Mark's rant because I agree with him, he wrote MM and IMAP, his TELNET UI design inspired GLS to write the Telnet Song, and he had the panache to use terms like "cretin" and "bagbiter" and "M-X fart-noisily-with-spray". ;) RIP Mark Crispin.

https://en.wikipedia.org/wiki/Mark_Crispin

Title: Telnet Song, Poet: Guy L. Steele, Jr

https://web.archive.org/web/20040111114819/http://www.cs.ric...

As you say, "keyboard macros are a way of life for real emacs hackers" and that just happened to break my use of an on the fly macro five minutes ago. With today's super wide landscape modes it's not normally a problem, but someone also decided to change some default two window modes to vertical instead of horizontal.

The other two changes are also constant annoyances, in particular I'm really impressed how much shell mode has been broken.

I still suffer from this bug every day, and have developed elaborate work-arounds involving many extra key presses that I've committed to muscle memory and do without thinking now.

Well actually I do think about how stupid it is this isn't fixed, and how stupid it is somebody designed and implemented it in the first place, and how stupid it is that somebody put the bug it back in after somebody fixed it, every time I have to work around it, which is regularly, quite often.

Shell mode didn't originally have this problem, not in UniPress/Gosling Emacs, and not in the original Gnu emacs. Somebody actually came up with it and programmed it and got it past the gatekeepers and reviewed and committed in the main code (possibly twice!), and now nobody will acknowledge that it is a problem, even after Daniel's extremely detailed step-by-step bug report showing how to reproduce it (as if it didn't happen many times a day under normal usage), and my reminder that it was back.

The irony is that the broken shell mode is supposed to be one of the primary and most powerful advantages and flexible ways to use emacs, which can be synergistically combined with keyboard macros (which are also broken) to make on-the-fly macros that copy and paste and edit the long-lined output of one program and feed it into another (which can go terribly wrong, because of these two bugs and their interactions).

i.e.: split the shell window, switch to the top output window, position the cursor on the first line of output from a previously run command in the top window, switch to the bottom input window, position the cursor at the end on the prompt, switch back to the input window, start a keyboard macro, copy a line of output from the top output window, move to the next line (invoking the visual-lines bug), switch to the bottom output window, yank the line of text and edit it into a new input or command, and hit return to enter it into the shell (invoking the shell invisible force field bug), then switch back to the first window, end the macro, then ^U <count> ^X e repeat as much as needed. But no, you get hit by the visual-lines bug in the top output window, and the invisible force field bug in the bottom input window, again and again, spewing invalid mangled commands to the shell that do god knows what. It's like getting Eiffel-Towered by two bugs at once, one in each window!

https://debbugs.gnu.org/db/37/3735.html

>Introduction:

>In shell mode, editing of command output and previous command lines into new command lines and submission of those new command lines are quite broken.

>For example, editing a previous command's output lines to turn them into a new command line and then typing RET (executing comint-send-input) to try to submit it to the shell frequently submits only part of the line, and C-a and C-e frequently stop somewhere in the middle of the line.

>These problems severely reduce the usability of shell mode, which, before the breakage, was great for editing command output into related command lines (and editing it in general).

>Also, note that the partial submission can be very dangerous. For example, trying to edit an output line "one_thing" (e.g., from an "ls /dir" command) into the command line "rm -rf /dir/one_thing" can easily result in the command line "rm -rf /dir/" instead.

>The problem appears to be because of changes made to distinguish shell-prompt text from command text (and maybe also changes made to highlight error lines in command output. Apparently, boundaries between runs of text with different attributes cause commands to hit those boundaries instead of their normal boundaries (e.g., line boundaries for C-e, C-a, RET (comint-send-input)).

>Version information: This problem:

>- did not exist in Emacs 20.7.2,

>- first appeared somewhere in Emacs 21.x,

>- exists in Emacs 22.2.21 (NTEmacs and Debian Etch's emacs22 package, version_22.2+2-5), and

>- exists in Emacs 22.3 (built from the source in http://ftp.gnu.org/pub/gnu/emacs/emacs-22.3.tar.gz as of 2009-06-30).

>Details:

>Most of the problems occur when editing a line that originally was a command output line and that is being edited into a new command line, or when typing RET (to run comint-send-input) on such a line to execute the command line.

>However, some of the problems also occur when editing or when typing RET on a line that was a previously entered command.

>The main subproblems are:

[Pages of detailed step-by-step instructions to reproduce it under many circumstances omited]

https://debbugs.gnu.org/db/18/18135.html

>Daniel submitted this excellent bug report for a bug that has really been causing me problems, which was claimed to have been fixed, but definitely is not fixed in Emacs 23.3.1 or 24.3.1.

> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3735

>Chong mentioned it was fixed in Emacs 23, but said he didn't recall who fixed it.

>Apparently it was put back in and has been back for a long time.

>Could you please investigate to see who fixed it, and who put it back in, and WHY?

>This bug REALLY needs to be fixed, as it makes shell mode practically unusable, and as Daniel described, can lead to some very dangerous and inexplicable accidents.

>And whoever put the bug back in after it was fixed last time needs to stop doing that, please.

>-Don