Add custom variable for the mode toggle message

[hpfr]

Re: #131. I see other modes issue enable/disable messages, but I think they use whatever magic is part of define-minor-mode, which doesn't nag me on startup 😉.

Thanks for being open to this, and for your work! Big fan of this package.

To reduce the check for its existence, I could autoload the new variable.

[hpfr]

@alphapapa Any feedback on this?

[alphapapa]

Is the boundp check necessary? I don't think it should be.

Other than that, I'll merge this when I work on this package again. My time to work on Elisp stuff is limited right now.

[hpfr]

Is the boundp check necessary? I don't think it should be.

You're right; it's not necessary. In my initial testing, my changes must not have propagated to the new Emacs instance I ran at some point. I've pushed the removal.

[hpfr]

Rebased. Let me know if there’s anything else I can do to ease merging. Thanks!

[hpfr]

v1.3

:cry:

[alphapapa]

v1.3

😢

Well, it had been over a year since the last release, and there had already been several additions and fixes made, so I had to draw the line somewhere, otherwise I'll never be able to tag a new stable release. This may be a nice change, but it's a very minor one, so it doesn't warrant postponing a stable release to include it.

But now that 1.3 is out, this can be merged easily enough...

[alphapapa]

@hpfr Ok, there you go. (Now I may hear from other contributors whose more substantial patches are yet to be merged...)

[hpfr]

Thanks!

Can you explain the branching/release strategy your packages use? If you’ve already done this elsewhere a link is fine.

Most Emacs packages tag stable versions and have a default branch that regularly gets pull requests merged. Users who prefer stability can pin to a stable release, and users who prefer the latest updates can fetch the default branch.

It seems like you tag stable versions, but instead of regularly merging into the default branch, you tend to approve, add a milestone, and then let the PRs sit there until the mood strikes you to tag another release. Then you merge all the stuff you approved a while ago over a short span and tag, before the cycle repeats. This seems pointless to me. Users who prefer stability can still pin to a stable release, but users who prefer the latest updates have to cobble together their own development branch. Most don’t, so you end up with only a few people playing with the latest MRs before they end up in a tagged version. Why not just merge when you approve? People can always use the tags instead of the default branch head.

[alphapapa]

It seems like your real question is this: "Why don't you merge patches immediately? Because I want the changes sooner and I don't want to have to apply the patches myself."

And the answer is usually something like, "Because I have to tidy it up, test it, and add documentation and changelog entries, and I don't have time to do that right now." IOW, I don't merge patches to master that aren't ready yet; master is intended to always be stable and usable (if for no other reason than that 99.9% of users install from MELPA and get that build). If a patch already has all of those things taken care of, and needs no further changes, and it's obviously not going to break anything, then it could be merged as soon as I see it. But that's rarely the case.

I also have tens of other Emacs packages that I maintain, and jobs, and hopefully some semblance of a life, so what I try to do is to at least answer issues and PRs when I see them so that they won't sit unanswered for a long time; even then, I still overlook some for a while.

Then when I sit down to work on a package, I triage the things that need to be done. If the master branch has already accumulated a decent number of changes and they've been on the branch for a while, I may choose to tag a release then and defer other changes until the next version. Otherwise, as I said, a new stable release would never happen. I already waited too long to tag v1.3 of this package.

And the time I've spent explaining myself here could have been spent further working on actual issues. (I'm starting to sound like @tarsius now. Jonas, you have my empathy, sir.)

[hpfr]

It seems like your real question is this: "Why don't you merge patches immediately? Because I want the changes sooner and I don't want to have to apply the patches myself."

This is assuming bad faith; I was genuinely curious. Living on my branch and rebasing is easy enough, especially given your merge strategy :laughing:; I just didn’t understand why you did it that way. I guess I could have worded “This seems pointless to me” less bluntly. But I get it, I’m sure you get plenty of questions in bad faith. Don’t blame you for assuming it.

And the time I've spent explaining myself here could have been spent further working on actual issues.

Well, thanks for humoring me. For what it’s worth, if you had a pull request template, I would have put together the docs and changelog entry, or at least an attempt. I could have looked at the past commits, I guess. Sorry about that; I was pretty new to contributing when I originally wrote this.

[alphapapa]

It's not a matter of assuming bad faith. I read your questions several times and boiled them down to what seemed to be the root issue, that the way I maintain this package hasn't been optimal for you.

It seemed like you assumed that I don't have good reasons for what I do. And that seems like a strange assumption to make, because I'd think that, if you look at what I've done here, you'd see that I do things deliberately. I even have checklists for making commits and releases.

With the tens of packages I maintain, I don't plan to sit down and add templates to all of them. I recently added a bug report template to Ement.el's repo; no one has used it yet.

Besides, if I required submitters to make the changelog entries and such, that might deter some contributions; I remain torn as to whether I should expect that of the contributor or consider it my responsibility as the maintainer. I tend to follow Postel's Law, so if someone wants to submit a useful patch but they don't want to tidy it up to my standards, I'll put it on my todo list and get to it eventually.

But then someone else may be annoyed that I haven't merged some random fix yet. Well, you can't please everyone, but everyone has the freedom to maintain their own fork and apply whatever patches they want. But then someone will complain about having to do that...

Anyway, if someone wants to sponsor work on a particular patch, I'm available. Otherwise, I continue working on these projects in my spare time.

Now if someone wants to volunteer to help maintain them, I'm open to that, but that's happened approximately once, in all the years and tens of packages I've been maintaining.

[tarsius]

(I'm starting to sound like @tarsius now. Jonas, you have my empathy, sir.)

I don't remember recent involvements in any "get off my lawn" incidences. :stuck_out_tongue_closed_eyes: