I recently gave it a try after seeing dessalines recommending it. It is pretty cool but years of vim muscle memory won’t go away so easily :D
this post was submitted on 26 Jun 2023
59 points (94.0% liked)
Linux
48083 readers
785 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
In my opinion, users who already use vim are not the primary target audience of Helix. I see the target group more among users who want to switch from a "normal" editor to a modal editor. The selection → action model and the easier shortcuts probably make the switch easier for many. I personally don't like vim at all because of the handling (purely subjective view). Helix will definitely not be my default editor but I get along much better with it than with vim or neovim.
When I first tried Helix, my main concern (that prevented me from getting too far into it) was not going from Vim to Helix, but the other way around. Vim (or sometimes vi) is a standard editor on almost any Linux machine, so if I am ever working on a server if a VM, I would need to know/use Vim keybinds. That made Vim a more useful tool for me to learn at the time, as I could use the skills both on my machine and anywhere else.
I don’t feel like this is true anymore. Many distros do not ship vi(m) anymore but only nano.
Seems like most rpm based distro still ship vi/vim and don't default to nano.
Good to know. In Debian and Gentoo nano is the only editor by default.
Vim (or sometimes vi) is a standard editor on almost any Linux machine, so if I am ever working on a server if a VM, I would need to know/use Vim keybinds.
I understand the argument, but in my opinion it is used far too often and is not always true.
Not everyone works with servers on which they have no influence on the installed software.
And in the few cases where I had to work with servers on which I had no influence on the installed software and on which actually only vim was installed, I could always use sshfs or rclone mount without any problems so that the editor I used didn't matter.
I agree, never understood why they changed a lot of basic shortcuts away from what vi/vim/neovim uses.
I am a fairly long time emacs user, used it as my primary editor and note taking app for around six years. I have a config large enough to warrant its own git repo separate from my normal dotfiles.
Before emacs I used vim for several years.
After really getting into Rust, I decided about three months ago to just take a look at helix and see what it was about… and I haven’t opened emacs or vim again since.
LSP and tree-sitter cover like 90% of what my old config was doing out of the box, and the kakoune inspired key bindings just felt so natural. I feel at home without the overhead of configuration paralysis.
Don’t get me wrong, helix has plenty of room to grow, but I’m excited to grow with it.
Been using it on all my machines for many months now. Replaced all my basic usage that I had of vim/neovim and all the attempted and failed customisations and plugins I had tried to install. It works very well for console editing any file I need to reach without being overwhelming with weird short cuts I'll never be able to learn and with nice enough UI/UX that guides and teaches. Even better the integration with lsp allows to launch some project files and have the basics like go to definition kinda work.
Tried to learn vim for many years without being succefull in doing much more than just moving around and inserting/deleting text with the most basic commands.
It's great for anyone that doesn't want to go the vim route but still get a powerful editor to learn.
While I totally understand the struggle of learning Vim, I would still recommend it over Helix for the fact that most popular IDE support "vim mode" or "vim plugin", making vim not only a text editor but also a popular workflow across development environments. I would totally try out Helix if the key memory isn't only restricted to the Helix program
I sometimes play around with Helix and I almost always have a good time, but there are too many vim features that I have integrated in my workflow that there isn't any good equivalent to in Helix. I use ex commands, the quickfix list, snippets, the fugitive plugin and just little custom commands and mappings that I've accumulated. I don't see myself switching to any editor full time that doesn't have a replacement for most of these features, but Helix is very nice and fun to use occasionally.
ex commands
Are these for scripting outside of vim (but using vim)? If so you can probably still use these with vim and helix for interactive editing. Unless I am misunderstanding what you mean by that feature.
quickfix list
<space>d (current file) and <space>D open a window of issues as reported by the current LSP which you can use to jump to the selected issue (with fuzzy filtering).
snippets
Looks like there is some basic support for lsp snippets which looks like you can add your own but a wider issue for better snippet support is being tracked here. So not ideal yet, but will hopefully improve over time.
fugitive plugin
It does have git gutter support and the :reset-diff-change command currently. And you can run git commands with :sh git ... though that experience could be improved. Staging changes is still pending here as is diffing changes here which look like there is work slowly being done on these.
So there are some workarounds for some of the things you need - and improvements being made to those that are missing. Might take some time for these areas to improve though and it depends on how you use those features as if/when things are good enough for your usecase.
There are many cases I actually prefer the quickfix list to an interactive picker:
- When working on a very large project, such as my $DAYJOB, interactiveness gets in the way more than it helps if you're running a slow command (like greping a large number of files)
- You can use
:Cfilterto filter things matched in the quickfix list and:colder/:cnewerto navigate the history of the quickfix list without having to rerun the command - You can run ex commands on the items in the quickfix list, like
:cdo norm gccto comment the matched lines (with the vim-commentary plugin), run a macro with:cdo norm @q, or:cdo yank Ato put all the matched lines in thearegister for example. You can also do stuff like:cdo -10,+10g/re/pto print all lines matching some regular expressionrewithin the range of 10 lines before to 10 lines after the match. - You can put more things in the quickfix list than you can with interactive pickers, like
:Git diftoolto get diffs. Vim also has support for parsing the output of many compilers and linting tools so you can use e.g.:compiler cargofollowed by:maketo build the current project with cargo and get any build errors in the quickfix list.
In short, interactive pickers are better for browsing, but the quickfix list is better for scipting and holding on to data for longer without having to rerun commands, and can with some basic scripting be used for more things.
Afaik helix doesn't have diff capabilities which is also a major thing missing from my git workflow.
I expect some of these things to make it into helix eventually, particularly git stuff, but I would be surprised if they add support for more weird janky vim stuff like the quickfix list and ex commands, which is a valid design decision, but they are also very useful tools once you get your head around them.
I kinda like Helix, I just don't really know what's the point of it. Some of the Kakoune bindings are marginally better than the vim default but any efficency I might get with it I instantly lose when trying to re-learn things or getting confused when I hop on a vim terminal on an other machine.
Kind of the same with the editor, it's like a 'batteries included vim' but I can just get that with a really light vim config and not mess up my workflow.
I guess it's might be cool if you are getting into it as your first modal editor but even then, if you want to use other stuff or need to use some different tools getting a vim extension will probably be easier than getting a Kakoune one.
I love the treesitter based movement (allows to move to beginning/end of a function), and the jump list (list of the locations where the cursor went, cross files and easy to navigate... Vscode really misses this).
I miss a debugging experience at least comparable to Vscode's with rust analyzer (ability to start the debugger on a single test case without having to look for the executable's path) to be able to use it day to day. To be honest, competing with vscode is always going to be difficult
I downloaded it and it's pretty good, but even as someone who only uses vim / nvim on a needs basis I'm not sure I have the willpower to learn these new shortcuts.
I want to like it but I just don't... I hate that it has words selected all the time, doesn't look clean and makes it all feel slower.
I love Helix! It's pretty much replaced Vim for me, which was previously my preferred editor for quick changes, as opposed to loading up VSCode for when I'm putting in some sustained work.
Helix required a small amount muscle memory change, but nothing major, and in return I have a text editor which, due to sensible defaults, is exactly the same on all of my devices. I don't need to mess around with plugins (Vim plugins are fun, mind, but it's kind of a waste of time if Helix meets my needs out of the box.)
There's also Lapce which will hopefully implement Helix's editing model too: https://github.com/lapce/lapce/issues/281
view more: next ›