Merge with org-sticky-header?

[aspiers]

As discussed on Matrix, this seems to be a generalised version of https://github.com/alphapapa/org-sticky-header which works across multiple major modes. So I'm guessing it would make sense to merge with https://github.com/alphapapa/org-sticky-header and then open up for contributions supporting other major modes?

[alphapapa]

I appreciate your reporting these issues and suggestions, but I don't want to take on the maintenance of this as a package at this time. I probably should have posted it as a Gist instead of a full repo. If you're interested, you're welcome to take this code and run with it.

[aspiers]

Don't worry! :wink: You are of course not remotely obliged to respond to any of these issues or PRs. As with any FOSS project, releasing the code does not imply any commitment to maintain it. So feel free to totally ignore any activity here with a clear conscience. However you could still consider keeping the repo open because others like me may want to come along and collaborate on it.

It would be helpful to understand your intentions with https://github.com/alphapapa/org-sticky-header though. Do you intend to maintain that project? And momentarily ignoring the concern about who might do the work, do you see benefit for users in merging these two projects or otherwise generalising org-sticky-header to something which would work across multiple major modes? For example, if I or someone else volunteered to unify the two, do you think this would be a good way forward? It seems like a good idea to me (and indeed it seemed like that was already your intention in the way you wrote this code) but I could easily be missing something so I wanted to sanity check my understanding.

[alphapapa]

It would be helpful to understand your intentions with https://github.com/alphapapa/org-sticky-header though. Do you intend to maintain that project?

Well, I just updated it 9 days ago... ;) I've been maintaining it for 3.5 years. I don't intend to stop maintaining any of my published packages. If I did decide to retire some packages in the future, I would say so.

And momentarily ignoring the concern about who might do the work, do you see benefit for users in merging these two projects or otherwise generalising org-sticky-header to something which would work across multiple major modes? For example, if I or someone else volunteered to unify the two, do you think this would be a good way forward? It seems like a good idea to me (and indeed it seemed like that was already your intention in the way you wrote this code) but I could easily be missing something so I wanted to sanity check my understanding.

Maybe. Of course, at the low level they are very similar. At the same time, org-sticky-header has a bunch of Org-specific features, and I don't know if it would be good to cram them into a generalized package. And it has over 6,000 downloads, so it would not be right to abandon those users by abandoning the package. So org-sticky-header will not be going away.

If you are interested in co-maintaining this package, I'd be willing to join that effort (without any specific commitments to do anything on it). Really, I just slapped this together by copying some code from org-sticky-header and modifying it a little. It's a relatively trivial library, but it could be quite useful.

If it were to be a serious, published package, it might need a better name. This one sounds generic and boring.

Also, considering how simple and generally useful it may be, and that it probably won't need heavy development once it's stabilized, it might be appropriate for publishing on ELPA.

[aspiers]

Thanks - great thoughts, and agreed on all points. One idea might be to view (what is currently named) simple-sticky-header as the "framework", and have other packages like org-sticky-header as "plugins" which add support for specific major modes. Similarly to how you have things like company-mode with different backends. Although in this case, it's such simple functionality that maybe they could all live in a single repo, albeit potentially in different files. Either way it should be possible to provide backwards compatibility without much difficulty. I'll have a think about it.

[alphapapa]

That could work.

Regarding the name: This is probably worse, rather than being an improvement, however I have noticed that my org-super-agenda package seems to have an effective name (e.g. someone made a org-super-links package too), though it seems hyperbolic in hindsight--so may I suggest super-sticky-mode (ha). Although I'd still prefer something neither "super" nor "sticky." Maybe some play on a synonym of "glue"? I suppose I'm tired of generic-sounding, hyphenated names, and I'm gravitating toward shorter, catchier ones.

Anyway, it doesn't matter that much. Let me know what you think.

[aspiers]

Firstly, Happy New Year! ;-)

Hehe, shorter catchier names do make things more fun. Given that the point of the package is to broadcast some useful information from the top of the window, how about something like lighthouse or pharos or similar? (beacon is already taken.)

[alphapapa]

I forgot that I even made this until just now, when I needed it (having recently disabled Semantic in my Emacs config), and felt like I had made something like this already. :)

How about super-sticky-header? That seems reasonably descriptive while still being usefully hyperbolic, haha.

[alphapapa]

@aspiers I went with topsy, because it appears at the top of the window. :)

[aspiers]

Brilliant name, love it! :grin: