Emacs-Helm development is now stalled(github.com)
github.com
Emacs-Helm development is now stalled
https://github.com/emacs-helm/helm/issues/2386
117 comments
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.
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.
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 think all of this is vastly oversimplified.
> Humans don't like simple 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.
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.
>Humans don't like simple things.
I the tech-world i have to say i love simple things, always.
I the tech-world i have to say i love simple things, always.
> Humans don't like simple things.
I like simple things, am I not human?
I like simple things, am I not human?
The brain obscures a lot of complexities.
Just take any simple thing and start thinking of any aspect of it. That itself is not simple!!
Just take any simple thing and start thinking of any aspect of it. That itself is not simple!!
About as expected as the Spanish Inquisition.
Open source is pretty interesting in how it functions and it’s something I really want to understand more deeply.
Thank you for the book suggestion. It was recommended by Guido van Rossum recently: https://twitter.com/gvanrossum/status/1297043394712092672
Great! Ordered. Thank you!
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 wonder if there is a way out of that.
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.
Obligatory XKCD https://xkcd.com/2347/
I would consider him a developer if he developed this package. Maybe not a developer by professional occupation, but still a developer.
I think you meant he’s not a professional developer.
Professional being a person who gets paid to do work.
Clearly his development of software that is widely used is not in question.
Professional being a person who gets paid to do work.
Clearly his development of software that is widely used is not in question.
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.
Sure. Doesn't make it a good way to communicate that surprise.
> 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.
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.
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.
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.
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.
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.
A follow up issue[0]:
> 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.
[0]: https://github.com/emacs-helm/helm/issues/2388
> 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.
[0]: https://github.com/emacs-helm/helm/issues/2388
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]: https://github.com/alphapapa/org-rifle
And yes, ivy is an awesome package. Higly recommend it.
[1]: https://github.com/alphapapa/org-rifle
I'm glad you find it useful.
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.
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.
Ivy is at best an alternative to ido.
It requires using return/tab to complete things, which is precisely what helm does not do.
It requires using return/tab to complete things, which is precisely what helm does not do.
Like all keybinds in Emacs, this is a matter of defaults and preferences.
(use-package helm
:bind* (:map helm-map
([tab] . helm-next-line)
([backtab] . helm-previous-line)
("C-S-SPC" . helm-next-source)))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.
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.
[deleted]
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".
Is there a way to help Thierry financially?
Is there a way to help Thierry financially?
I have spacemacs configured to use it, too.
The interview in https://news.ycombinator.com/item?id=24450038
mentions there is a Patreon account
https://www.patreon.com/emacshelm
I'm not at all sure whether that would be effective help today. Other ideas?
I'm not at all sure whether that would be effective help today. Other ideas?
There was a Patreon linked to from the interview linked to in another comment, but it seems to be defunct: https://www.patreon.com/emacshelm/creators
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.
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.
I love helm but I've in the past years found ivy to work better in the ecosystem at large. I still miss some aspects of helm but it could be an option
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 :)
It appears that you may have to travel to the alps and leave a very surprising tip.
There were efforts of getting financial help ifyou check the README history.
Sadly to no avail I guess.
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?
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.
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.
Emacs has multi cursors (https://html.duckduckgo.com/html?q=emacs%20multi%20cursors) though I never saw them as useful, search & replace seemed better. Perhaps I was missing something.
I use multicursor all the time and it works great. Probably because I never got used macros.
I'd say spend the time to get used to macros and and regexes. Each is so capable, together they are more than the their sum.
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.
1: https://github.com/raxod502/selectrum#why-use-selectrum
1: https://github.com/raxod502/selectrum#why-use-selectrum
Thanks for this link.
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" :(
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.
[1] https://staff.fnwi.uva.nl/c.dominik/
[1] https://staff.fnwi.uva.nl/c.dominik/
> 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.
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.
Thanks, I have found this "menu", but it felt awkward and limited to either horizontal or vertical.
I have come to split first and search second.
It’s all about personal preferences.
I have come to split first and search second.
It’s all about personal preferences.
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.
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.
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:
^note1: I don't use rg due to dependency on PCRE2 which doesn't play nice on my OpenBSD machine.
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.
> ^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`).
FWIW, PCRE2 seems to be an optional dependency, and disabled by default (unless you build it with `--feature pcre2`).
The last time I tried rg with pcre2 disabled (OpenBSD 6.4?), it SEGFAULT even with wxallowed :(
Looks like either things have changed, or this only happens under some specific circumstances.
I just tried installing it into a clean OpenBSD 6.7 VM, and it ran fine out of the box:
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:hiOh, that is nice. Thank you for testing!
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.
I switched from helm to ivy-counsel-swiper earlier this year and I haven't looked back.
That’s too bad. Once I discovered helm, that was a complete game changer for how I used Emacs.
Guess I’ll still hang on as a user, and see how it pans out over time.
Guess I’ll still hang on as a user, and see how it pans out over time.
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?
Helm has a slight learning curve (more like un-learning curve). Need to forget Tab completing/narrowing. (It is hard for long time Emacs users)
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.
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.
Nineteen minutes before opening the linked issue announcing that the development had been stalled, he removed a chunk of text from the README: https://github.com/emacs-helm/helm/commit/9a5258db9c7bb12698...
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.
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.
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.
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.
(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?
It's more like fuzzy search for everything you could possibly do, with docs and completion. I'm a vimmer, emacs people should correct me.
It's magic because everything is a single lisp environment. So the client/server thing vim does isn't as unified.
It's magic because everything is a single lisp environment. So the client/server thing vim does isn't as unified.
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
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
> emacs has two main contenders for "fuzzy search" - ido-mode and helm.
Also Ivy.
Also Ivy.
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.
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.
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.
Yes, `:Commands` does that. Not sure if it’s documented in more detail somewhere else, but it’s listed here (https://github.com/junegunn/fzf.vim/blob/master/README.md#co...).
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.
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.
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.
I hope somebody will step up a new maintainer. Helm is very popular and part of many people daily emacs workflow.
Fork me!
Could you please rename the title to state that it’s Emacs-Helm search extension? Otherwise it’s too click baity for the Kubernetes crowd.
[deleted]
Eh, and I almost lost my breath when I thought my favorite open-source synth[1] was being discontinued.
[1] https://tytel.org/helm/
[1] https://tytel.org/helm/
Is it actually under active development? Are pull requests getting reviewed and merged?
I clicked in to see why would kubernetes helm would stop development without any indication all of a sudden.
Yup, that’s why I clicked
(The Emacs thing, not the Kubernetes thing.)
Yeah was quite surprised when I saw the title. Naming things and stuff, but the title should probably say emacs-helm.
Helm (for Emacs) and was there before Helm (for k8s).
Maybe Helm (for k8s) should have been named k8s-helm to avoid confusion.
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.
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.
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:
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:
Elon didn’t name the company, it already existed when he got on board, but I see your point.
TIL.
Thanks!
Thanks!
Yeah, naming things is hard, talking about how things are named is even harder! hahah
Yeah..I almost had a heart attack reading the title.
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.
Thanks for the mini heart attack. Thought it was the Helm synthesizer. https://github.com/mtytel/helm
Well.. it looks like that hasn't had any commits for over two years anyway. Which might be okay; it could be done.
What? More like commits every other day for several years.
https://github.com/emacs-helm/helm/commits/master?after=19d2...
https://github.com/emacs-helm/helm/commits/master?after=19d2...
The comment you are replying to is not talking about the emacs helm but rather the synth.
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.
Most common for you. I’ve never even heard of that thing.
But yeah, if the title can be more specific, that can’t possibly hurt anyone.
But yeah, if the title can be more specific, that can’t possibly hurt anyone.
I admit that, yes, it's more common for me.
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.
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.
Helm is a mess of code, I'd suggest it probably has become unmaintainable. Ivy is my preferred completion plugin.
Why the negativity? Helm has served me really well for pretty much every day for the last 10 years. I'm extremely thankful for it.
See this rare interview from 2018: https://sachachua.com/blog/2018/09/interview-with-thierry-vo...