The Emacs package `Helm' is/was maintained by one guy alone named Thierry Volpiatto who is not even a developer. He is 57, and a mountain guide in the Alps!
I find it pretty amazing that someone who's been working for 20 years as a mountain guide and spends as much time as possible outdoors picks up an obscure piece of niche software like Emacs, learns to program in his 40ies and then becomes one of the most significant package contributors, all as a side hobby to his outdoor interests.
A lot of mathematicians are oddities that by some stroke of luck, or perhaps by consistent switching of hobbies, somehow figure out that they understood the basic premises of mathematics.
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.
Humans like simple things when they have social signaling value.
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.
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.
Maybe what you think is simple problem isn’t so simple after all...
This is the mark of an inexperienced software engineer in my book. Not understanding the true complexity of a given situation.
I still catch myself doing it.
I'm a senior engineer with 15 years of experience. Pretty sure I have a good grasp on "complex" vs. "unnecessarily complicated," and I see the latter a lot more than I would like to.
I think there are two axes at play here - simplicity/complexity, and familiarity/alienness. Maths might be simple, but it's also incredibly alien. Things that are alien to conventional thought processes are always disliked and disregarded when possible.
Well, or functions not -- sadly. It seems possible that the reason Mr Volpiatto ceased development was because the burnout he had close brushes with before finally caught up with him.
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 think to say "not even a developer" connotes surprise. I wouldn't expect to see someone whose dayjob doesn't involve programming work on something like an Emacs package.
> I wouldn't expect to see someone whose dayjob doesn't involve programming work on something like an Emacs package.
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.
I think this is the biggest loss we've had in the past 20 years. The takeover of open source by "professionals" has lowered the diversity of perspectives in open source.
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.
Yes,yes, yes. Is it a cultural thing why this gets lost? Is it the abscence of an enemy (Microsoft?)? Is it the cultivatism of kids today who are willing to pay for the download while 20 years ago Napster boomed? Is it the everything can be monetized and professionalized attitute vs. amateurism? I truly wonder.
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.
Perhaps it has to do with the rise of the "precariat"? Younger nerds are more worried about trying to survive than hacking Free Software for fun? It is often claimed that basic income would give a boost to such volunteering.
I don't think it's that it got lost, but rather that a lot more money got into open source development. While I was at school I was really interested in hacking on Mozilla, where they were espousing ideals about meritocracy. After a while I realized that it really mean the folks they employed to work on Firefox had all the power, simply because they had more hours per day changing everything so casual contributors couldn't keep up.
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.
This is only tangentially related, but I've always thought it was interesting, so I point it out whenever it's applicable...
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.
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.
Interesting, no details into why. Anyhow, for those who might want a replacement in case no one else picks up development for Helm, I highly recommend the Ivy package as an alternative in Emacs. I've always preferred it over Helm for being more minimal and speedier.
I higly depend on `helm-org-rifle' [1]. Lets me search trough all my org files (headars and content) and presents the results beautifully in a temp buffer. - Would be very sad if development of helm would stop.
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.
counsel has `counsel-org-goto` and `counsel-org-goto-all` to search and jump to any section in the current org file and all org files, respectively. However I think they only search in headers, not in content, so they might not be a full replacement for helm-org-rifle, but it could be worth a try.
After migrating to Doom, I'm spending quite some time waiting for Ivy's buffer list to pop up, then process my input or just the cursor movement keys. Not really seeing the ‘speedier’ part. Haven't yet looked into what's taking it so long.
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.
Damn. Helm is the most important emacs package I use. It's what makes emacs "emacs" for me, and the main reason I find every other editor "from the past".
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.
It's a bit lighter on resources as well. Although with modern processors and memory sizes, helm really is nothing compared to some of the things that go on in vscode :)
Moved from Emacs to ST then VSCode a few years ago, but still miss how that community feels (the software, the people, the discussions, EmacsWiki...)
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?
There is something about the multi cursors in ST and also in JetBrains IDEs, which just makes them more intuitive than whatever I tried in Emacs so far.
Maybe it just can't be combined with evil mode reasonably?...
Does anyone have a recommendation how to emulate the ST multicursor more closely in Emacs?
I've been using selectrum lately, it works ok, no bells and whistles... The readme [1] has a [probably very biased] comparison of alternatives, including helm.
I recently switched from ivy to selectrum as well. I miss some stuff like ivy-rich, but I found integration with prescient.el[1] more important than an eye candy (where ivy-prescient breaks every few version). I still haven't got a chance to rewrite ivy-ag with selectrum^note1, but it has been working great so far.
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))))
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" :(
Org-mode is another package that is due to "non-professional" developers. Carsten Dominik, the original creator of org-mode, is a professor of astronomy. [1] A lot of people who've contributed to org-mode are academics in fields other than computer science. Not as unrelated as mountain guides, but certainly not professional developers.
> 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.
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.
Being Emacs, it's just a matter of customization. In your example, it would probably be enough to apply advice to one of the Ivy functions to split the window appropriately when a candidate is selected. A few lines of code.
> being emacs ... customization ... a few lines of code
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.
For those unfamiliar with the alternatives, you can switch to ivy and counsel, it's pretty lightweight and a nice alternative. Works well with Doom Emacs and out of the box.
That’s too bad. I personally didn’t use helm and found it a little strange after being use to vanilla Emacs for many years, but I know a lot of people liked it a lot. I wonder what happened there?
> 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
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.
The state of the Patreon page is what it looks like when someone has an ordinary patron account. In this case, it probably means the account was reverted from a creator account to a patron account.
Thank you for pointing to the Patreon and PayPal link. Was searching for ways to support the maintainer myself and found only the Patreon link that - as you indicated - does not work.
(neo)vim user here; is this like the myriad of ctrl-p vim plugins like fzf, cpsm, etc? In the vim world the core functionality is often shelled out to a task-specific process via a plugin, and the vim code is only used to communicate with it. Is that not the case with emacs?
No that is right, emacs has two main contenders for "fuzzy search" - ido-mode and helm. They act as completion engines for all kinds of search; file, word, buffer, commands etc.
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
The closest vim has (to my knowledge) is Unite/Denite, although fzf is functionally similar minus a couple limitations on starting new fzf searches from the callback of another.
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.
Does FZF work with a list of vim's ex commands as source (preferably including plugin defined commands)?
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.
Helm allows one to specify their interface in the form of a class (helm-source) between (arbitrary searching code) and (helm-core = a standardized way to represent/navigate that in a buffer) which one can plug in his candidates for searching (anything).
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.
not very familiar with vim internals (other than knowing vim is not vi codebase), but emacs most everything is natively written in emacs lisp and has lots of hook points, emacs extensions tie into these or in some cases may carefully provide extensions/extra API's around builtin functions, etc.
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.
My one point of contention with helm is it's too controlling. There is no built in function for enumerating the candidates list, if you happen to want that. The current contents of the minibuffer (whatever you have typed or have not typed) up until recently couldnt be used as as the selection. Now there is a must-match parameter, but it can only be set upon invoking helm and not via a key binding (if you wanted both behaviours). The parameter must-match also doesn't solve the problem of selecting the empty string and selecting the empty string breaks out of helm. I still use helm for when I want strict control over the candidates, such as for running elisp functions with M-x. Ivy, on the other hand, is a much simpler fuzzy-finder. It's more like fzf. I use ivy as the default completing-read function.
Helm is amazing in that you can add it to your workflow, read practically no documentation and get a significant boost to productivity and user experience. Its a must have for me.
Popularity and familiarity certainly matters. When someone mentions Tesla most think cars not person despite the person coming first. There was also an iPhone before the Apple iPhone, but of course hardly anyone means the product meant by Linksys/Cisco.
Agreed. But if Tesla (the company) even remotely helped some people learn about Nikola Tesla, that's already something good, in my book.
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:
Helm and Magit are why I use Emacs. This is really sad. Can this repo be handed over to someone else? I'd really like to support Helm in my own way, by making code contributions if possible.
This title is extremely misleading and terrifying for a Friday night, since the most common "helm" tool is the Kubernetes one. To avoid further SRE/devops mini-heart-attacks the title should probably be updated.
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.
See this rare interview from 2018: https://sachachua.com/blog/2018/09/interview-with-thierry-vo...