Emacs-Helm development is now stalled
github.com
github.com
See this rare interview from 2018: https://sachachua.com/blog/2018/09/interview-with-thierry-vo...
Professional being a person who gets paid to do work.
Clearly his development of software that is widely used is not in question.
Twenty years ago, I maintained some Free Software projects. I wasn't employed in IT at all, in fact at the time I was studying towards a soft humanities field, and all my knowledge of programming was self-taught. So much of the other Linux software I used seemed to come from similar people. After all, the draw of Linux and GNU tools was that you were free to tinker with your computer and teach yourself from books, no expensive commercial software required.
I get the impression that laypeople developing and maintaining packages has become less common as the open-source movement took off and more paid employees at corporations started to do these kind of tasks. Similarly, the premiere "news for nerds" site today is Hacker News, which comes out of the corporate world, while its forebear Slashdot of the early millennium had a more varied mix of professional IT people and hobbyists.
Some of the most renowned folks from my generation or the one before me are not professional software engineers. And those people were the ones that valued Free Software more than the ones who are professional software engineers.
I often wonder if this is one of the bigger reasons why FOSS is doing so much worse these days.
I am 45 and I experienced the net and hackerism of 20 years ago as a wonderful world which it is no more today and I can't really say why.
It made sense for them, of course, since they can't hire that many people and just have them sit on their thumbs all day.
John Kemmeny (one of the inventors of Basic) wrote a book in 1972, "Man and the Computer," summarizing the development of the computer up until that point, and making some predictions about the future. He was surprisingly accurate, and predicted the internet, online encyclopedias, computers in every house, and a lot of other stuff.
There was one big thing that he was wrong about, though. He expected that in the future more or less everybody using computers would have a basic understanding of programming, and be able to automate simple tasks for themselves. I think if that prediction had come true, open source projects developed by amateur, non-professionals would be a lot more common.
For a while, it looked like things were headed that way, but at some point companies realized they could make more money if computers were primarily used for media consumption, and so the interfaces and expectations about users have been getting dumbed down ever since.
My impression is that most open source projects that do not habitually burn their creators are either strategic assets to a handful of multi billion dollar companies, in which case at least core contributors get a normal life and see some actual upside for their work; or part time labors of love of talented individuals who have either not hit the scale where they would need to engage with a large number of users or who are very good at saying No.
Even the rare super-elite developers like Zig's Andrew Kelley who manage to get full-time funding for their work via patreon/github don't seem to pull in more than a fraction of what they'd make in normal employment as a single person for their whole project.
Open source started out as asymmetrical warfare against The Man (personified to Microsoft) but by now has been mostly co-opted into a form of voluntary self-exploitation to enrich mega-corps.
I wonder if there is a way out of that.
After all, the issue is that mathematics is simple. Humans don't like simple things. And when humans think they have found simple things they start wars or some novel iteration of discrimination against others.
It's amazing how true this is. You can see it very clearly in your day-to-day as a software engineer. The vast majority of people you will encounter in your career favor fancy, complicated solutions to problems that could be easily solved with fewer resources. And yet when you float those ideas, you're laughed at.
I like simple things, am I not human?
Just take any simple thing and start thinking of any aspect of it. That itself is not simple!!
Creating new complex things is easy, because you can assemble them from existing simple things. Creating new simple things is more difficult, because you must go beyond assembling existing simple things.
Simple things lose their signaling value when they become well-known. Complex things lose their signaling value when they are replaced by simple things.
Therefore, it makes perfect sense that humans attack simple things: they threaten the signaling value of the easier to create complex things.
I the tech-world i have to say i love simple things, always.
> Thanks so much for everything! #2388
Nice to see a positive response from the emacs community.
Helm only seems to have 15 issues, maybe it really is that close to complete for most people using it. I know I use helm and haven't thought twice about it.
And yes, ivy is an awesome package. Higly recommend it.
1. Helm is not going to stop working anytime soon. I haven't even upgraded Helm in my configuration for a long time, and the version I have installed still works fine.
2. The latest version of Helm should continue working for even longer.
3. It shouldn't require much effort to make the occasional fix to Helm for compatibility with newer Emacs versions.
4. It's likely that Helm will continue to be maintained by someone, if not Thierry after some time away.
5. org-rifle already has a non-Helm interface built-in.
6. See also org-ql, which supersedes org-rifle to some extent.
It requires using return/tab to complete things, which is precisely what helm does not do.
(use-package helm
:bind* (:map helm-map
([tab] . helm-next-line)
([backtab] . helm-previous-line)
("C-S-SPC" . helm-next-source)))As for the ‘minimal’ part, indeed Helm has niceties thrown in, like recent files in the buffer list (I happen to been using that), or seeing docs from some completion lists.
Is there a way to help Thierry financially?
I'm not at all sure whether that would be effective help today. Other ideas?
However, sounds from that interview that being in the mountains is both his job and primary source of enjoyment, so I wouldn't be surprised if money isn't a factor.
IIRC I used to move around mostly using ido.el, when anything.el and later Helm appeared with their alternative way of displaying results, using half the window.
But then at some point got sick of the text UI and moved to Sublime Text. Probably multi-cursors made me move?
For a few years I remember opening Emacs exclusively for https://www.emacswiki.org/emacs/grep-edit.el.
I feel like Emacs is full of those hidden gems that only a hundred people use.
For some reason, neither helm, ivy or selectrum allows to open a candidate buffer / file in either the current buffer, a vertical or horizontal split window, like what I have grown an addiction for with fzf.vim.
As I have also grown an addiction to org mode, emacs ergonomics always feel weird to me, even with evil mode.
Selectrum seems to explicitly exclude "alternate actions" :(
I use ivy and counsel, and both counsel-find-file and ivy-switch-buffer offer the alternate action "other window" under M-o j. I'm not sure if that covers your entire use-case, but it works fine for me.
I have come to split first and search second.
It’s all about personal preferences.
I see where you are heading and I am not following you in this rabbit hole ;)
I came to use emacs for org mode, when what I really wanted was to use org mode in vim. We can’t have All the nice things, so it’s okay, I’ll live with that. I actually found out I could use emacs as a "org mode beautifier" in neoformat.vim; it is slow, but it can tangle the org file and output back to vim. Good enough.
My only issue with selectrum was, back when I'm using ivy, I rebind forward direction keys (<right>/C-l/C-f) to `ivy-partial-or-done` which either complete the input with the selection or visit a file depending on the context. Selectrum doesn't have equivalent implementation, but it's easy enough to implement. Reposting in here in case anybody needs it:
(defun gemacs--selectrum-insert-or-submit-current-candidate ()
"Insert current candidate or forward to `selectrum-select-current-candidate'
if input text hasn't changed since last completion."
(interactive)
(let ((prev-input (selectrum-get-current-input)))
(when (> (length (selectrum-get-current-candidates)) 0)
(selectrum-insert-current-candidate))
(when (string= prev-input (selectrum-get-current-input))
(selectrum-select-current-candidate))))
^note1: I don't use rg due to dependency on PCRE2 which doesn't play nice on my OpenBSD machine.
FWIW, PCRE2 seems to be an optional dependency, and disabled by default (unless you build it with `--feature pcre2`).
I just tried installing it into a clean OpenBSD 6.7 VM, and it ran fine out of the box:
# pkg_add rust
# cargo install ripgrep
# echo hi > asdf
# .cargo/bin/rg hi
asdf
1:hiGuess I’ll still hang on as a user, and see how it pans out over time.
Just start typing snippets of what you want.
Once you get used to it, you want it everywhere.
FZF on zsh works the same way and is a pleasure to use for people with 10 of thousands of items in shell history.
Here's how it looked before that change: https://github.com/emacs-helm/helm/blob/23f32ec37dadea5656fb...
Here's a representation of the text for those who don't want to click through:
> Maintaining Helm requires a [lot of work](https://github.com/emacs-helm/helm/commits?author=thierryvol...), Thanks to all the people that are helping or have helped Helm development,
> but they are actually too few.
> If you feel Helm is making your daily work easier,
> please consider making a donation.
> Thank you! — Thierry Volpiatto
> [PayPal link image][Pateron link image]
The Patreon link doesn't seem to be working (the page is mostly blank, which seems like a bit of a bug on Patreon's end if nothing else).
The PayPal link is still active.
---
There was also this README change in May that removed some text: https://github.com/emacs-helm/helm/commit/3be1389e3912d6580a...
Which looked like this prior to the change: https://github.com/emacs-helm/helm/blob/1fbb3a9f6da328519162...
Compressed representation:
> Maintaining Helm requires a lot of work, which I have done voluntarily since 2011. As it demands lots of my time it gets increasingly difficult maintaining it without financial help. Thanks to all the people that are helping or have helped Helm development, but they are actually too few to continue serenely. By the way, after the release of version 3.0 I will have to stop developing Helm seriously until I get enough financial support, only providing a minimal bugfix maintenance. Thanks for your understanding
> If you feel Helm is making your daily work easier, please consider making a donation. Thank you! — Thierry Volpiatto
Development was also apparently stalled for a time in 2018-2019: https://github.com/emacs-helm/helm/issues/2083
From my brief skimming, it seems like this has been coming on for a while, which is a sad thought.
---
One more thing that might be meaningless, but which I think indicates a level of ongoing care about the project (which is not surprising given his past work on it). The commit that most recently modified the README accidentally undid the latest change he'd made, from two days before. He added another commit a minute later to re-apply it. A small thing, but I figured I'd mention it.
It's magic because everything is a single lisp environment. So the client/server thing vim does isn't as unified.
Helm acts similar to Ctrl+P, ido is like an incremental search so finding a file named BasketViewController.swift in path ~/Code/MyApp/;
In helm would be 'bvc', whereas in ido it would be c -> code (hit enter), m -> MyApp (tab across if its not first result, enter) Bas -> BasketViewController.swift
Also Ivy.
Like helm, fzf and Unite can be fed arbitrary completion candidates, custom callbacks, mostly customized fuzzy matching. fzf is very fast, which is the main claim over what seems to be the more featureful Unite/Denite.
That functionality (helm-M-x) has been the best part of using emacs. It's always something I miss when I'm back in vim land. Really nice to just be able to discover these things without a mess of gui everywhere distracting me when I don't need it.
So if one eg. used shell or remote tools, it would still plug into helm, one would write a "helm-source" which communicated to helm how the source was updated and provide actions to communicate back and update/filter the source.
Helm is itself a library loaded into a given emacs image which provides useful functionality, but also that many other packages build on top of. Not sure if the point about plugins as a process was just wondering about how it works or hinting at some kind of 'workaround' for not being maintained by isolating it; issue here seems aside from potential bitrot in helm itself to be the overall ecosystem of all 'emacs helm plugins' deteriorating if helm is not maintained, which separate process plugin architecture wouldn't solve.
Or not-emacs-helm.
And maybe helm is confusing as well for boat enthusiasts and should have been named emacs-helm and... oh... oh, I see, naming things and stuff...
Gotcha.
NB: I've had this thought that naming a company Tesla, once you know the history of Nikola Tesla, his legend and legacy, is bold and it says something about E. Musk's self-esteem. :shrug:
Thanks!
Why, oh, why?
https://github.com/emacs-helm/helm/commits/master?after=19d2...
But yeah, if the title can be more specific, that can’t possibly hurt anyone.
I felt comfortable calling it the "most common" on a wider scale based on a quick search for "helm" using the HN Search. At quick glance ~90% of "Helm" mentions are the Kubernetes tool.