ERRATA: Around 5:15 I mention that deleting a previous word is easier in Helix because in vim you'd have to do 'bdiw'. But it turns out in vim you can actually just do 'db' to achieve the same thing as 'bd' in Helix! Thanks to Pranav P.A for pointing this out.
I'm so tired of vim configuration and plugins. Now it's the right time to bin it. You create such a useful and informative content - it's even hard to describe. Thanks for that and wish you and your channel to grow!🎉
Appreciate this video getting more visibility on Helix -- I have used it periodically and have a history with Neovim, this editor is insanely good and deserves attention.
Thank you so much! I wanted to have a non-gui text editor that I could use, but I didn't have the time to learn vim/other editors, this seems like the perfect one!
Nice! Yeah I think this might be a good place to start. Internalizing the motions will still take some time but at least you don't have to worry about configuration
@@codetothemoon I actually agree with this. I haven't been interested in vim or neovim since the beggining, but I might try this out. This seems very intuitive to me actually after fiddling around with it.
@@scion911 You should try vim some day too! It has a less intuitive act first, highlight later system but has a larger ecosystem and I find it more preferable until helix grows. PS: If you use any app, there's either vim keybinds for it or an alternative based on vim keybinds. It makes the vim experience really worth it.
@@casualoutlaw540 I understand your point, I was looking for file tree if it was implemented... Fuzzy search is fine but I like seeing file tree sometimes. Ecosystem is pretty new I guess, and it will take time. I actually tried spacemac before but didn't like the default keybindings. I actually haven't tried neovim in real projects... Just fiddling around, I honestly hate setting up everything, I know there must be ways of pre-configured vim varients but haven't explored it. I am pretty good at doing things without mouse in general gui ide's so I wouldn't want to sink time into configuration of terminal based editors... Do you know any good ways to have it in vim/neovim?
@@scion911I've been using LunarVim for around 6 months and I really like it. Right now I'm considering switching to Helix. Being easy to configure was a really good selling point, and it's blazingly fast for real.
Using vim for 25 years now. An in my opinion, the people behind helix made some very good decisions. The philosophy selection>action really makes sense. The editor is a joy to use.
Nice, I was pleasantly surprised by it as well. It's great to hear from folks with your experience, as I'm still a vim newbie so my perspective is a bit limited!
-book-videomarks: 0:48 [editor] line-number = "relative" 1:30 Modes in hx (missed: view mode with z) 2:21 vertical split with C-v (how to close that?) 3:48 b for back word 5:07 alt dot to redo 6:24 , to go back to single cursor 7:29 copy-paste in hx 7:56 syntax aware motions in hx 9:22 rename a symbol in space mode 9:43 applying code actions suggestions from the LSP 10:34 jump points: C-o, C-i 11:12 R to replace selection with yanking 11:49 registers there should have been some option to preview register
I've been playing around with Helix based on this video, and I'd say this is the experience that I expected with nvim + kickstart. There were lag + lsp issues with that though, whereas this has been relatively straight-forward. I'm having to learn some new motions that I've been using for the past decade, but those kinds of things are acceptable (probably good actually for the old brain). But it hasn't been erroring or crashing with a large project. So, so far so good 🤞🙏 Thanks for the video!
If you're used to vim/nvim, helix is simply a downgrade. What really would have potential is if they made a fork of helix and upgraded it to standard vi motions.
@@LuismaLorca Why fork instead of allowing configuration to set other key maps? Also, I don't see why that would be an improvement, but if you want vi motions, there are plenty of editors with them. At any rate, supporting them probably would expand adoption, but a fork is definitely not required.
@@theherk It would need to support a single config line to switch from kakoune to vi. If we had to write an entire config only to use vim, it would defeat the purpose of minimal config alternative... The problem is, the authors are very committed to kakoune keybinds, so I don't see such thing happening. It's respectable and it's their project, but it will never become as popular as it could have been with their philosophy...
@@LuismaLorca that is what I mean; a config to select which set of keybinds, not rebinding all individually. And I think it is possible it will come to that once plugins are supported and the community is a bit larger, but only time will tell. There has been some discussion about this exact topic, so there are others interested too.
Started using helix because Vs Code was getting slow. Got used to using a modal editor, and now I use nvim (lunarVim) as my editor of choice because of better plugin support.
Great video! I keep watching Helix content and playing with it and the thought I'm left with is "hmm this is basically neovim with no additional plugins available, and an opinionated refreshing look on normal/visual mode, that can easily be a neovim plugin..." So I'm thinking of Helix as a fully baked kickstarter neovim falvor with a slightly different approach to motions. Even the mentioned move between functions and structs is becoming very popular with text objects used by (most?) of the neovim community. What do you think? It kind of blows my mind that someone would sit an re-write Neovim from the ground in Rust just for that one tweak...
I would *love* to see a scientific study to investigate the claim that non-graphical editors are more productive than graphical ones. For example, take a representative group of beginner, experienced and veteran users for both, then give both groups representative work and measure how long they take. My gut feeling is that it will likely be that in the beginner bracket, graphical editors will show a clear advantage. In the experienced bracket, graphical will still have a slight but less noticeable advantage. And in the veteran bracket, non-graphical will show a slight but noticeable advantage.
I would love to see this study as well, and I agree with your intuition about what the result would likely be. My use of the word “can” was very deliberate given that I don’t think there has been such a study 😎
I had the same thought and I find it good that the word "can" has been used, as this almost goes back to the emacs wars! I think it has a lot to do however what you are used to. I grew up with mouse usage and as a gamer I am quick to handle the mouse, and I would not say that I am slower with graphicals than my collegues with vim, except in multi line editing, which however not all of them can do. The speed of the graphical editor can be an issue, and with visual studio code, I feel like you constantly have to actually also ignore clutter on the screen while you type, because it is already super smart. So any study would really have to find a lot of participants and judge their experience! However I am probably in the minority here, as a non-vim user. For C# I switched back to VS, and for python I will probably stick with eclipse (don't laugh, pydev is faster than pycharm and vscode, so yes, eclipse is actually by now "light weight" holy moly), but in rust, I might even try helix, but there I am currently using vscode. I actually hope one day there will also be a graphical editor coming from the rust scene.
So far I like it as a reprive from neovim. I do not think I will completly switch since there are some 'quality of life' items that I have configured for myself and gotten used to, but if I was faced with the option of starting over with neovim or use Helix I would probably go with Helix if for no other reason then to reduce my dependance on plugins.
oh man i am so happy that you finally arrived at helix, i tried it for sometime but couldn't stick to it. I loved the editor though. I will try it again because now i know there is someone i can ask questions to ;) As usual love you content. keep it up. let me know if you are on discord or any other means of communication.
Glad you liked it! Thanks for the kind words. I've been thinking about maybe making a Discord server, but I keep thinking it might be redundant with all the great Discord servers already out there, like Primeagen has created. Do you think a CTTM Discord server would be valuable?
@@codetothemoon You shd wait and see if more ppl ask then great. Primeagen doesn't have helix related discussions. There is a matrix chat but i have to download a separate extension for that.
The one thing I can't figure out, and maybe it's because I'm on Windows and installed it the way I would any program, by unzipping the release folder somewhere, is how to actually find files. I cannot seem to explore the filesystem at all except maybe if I put a copy of Helix in the top level folder of whatever I'm trying to edit, which really doesn't work in practice.
@@codetothemoon yes! that and snippets and soft-wrapping the text, both of which are also missing. Three more things needed before being able to switch from Vim or VS Code, but looking good though.
I'd like to use this as my daily editor, but I can't make it to work properly for React (autocompletion on HTML / JSX / TSX element properties doesn't work at all). Maybe it's me being ignorant, but in the meantime I'll keep using Neovim.
I had to switch back to Neovim as well, despite Helix working really well for Rust. I found that for my workflow I was using slightly more keystrokes with Helix - especially because it didn't support the `ci"` motion that replaces the content inside the next set of double quotes. I still hope to return to it, especially after plugins are implemented.
@@codetothemoon Exactly. I think it leans more towards backend development at the moment. The surround feature needs more work as well (for tags, etc). I look forward for future updates, as I really like the idea of this editor.
Helix definitely has some ground to cover before it can be a mainstream alternative to emacs/nvim - namely plugin support.... But I think it has a promising start and can probably already serve as a daily driver for some folks (not me quite yet though)
not 100% sure but I believe this term comes from the original vi editor which was released in 1976 - not sure if the term came about at release or sometime after that
I don't use it as a daily driver yet, so its hard to say. I did like the idea of highlighting prior to performing an action, but I'm waiting for plugin support before using it as a daily driver.
Certainly better than vim, but still not comparable with the Intellij platform. Nice text editor for the terminal, but I would not use it for any serious development.
@@codetothemoon - On the fly analysis - Macro expansion - Code generation - Code completion - Integration with Cargo - Breakpoints, stepping through, watches, raw memory, tree views for most of rust types - Project-wide refactoring - The possibility to keep a number of files open - Integrated version control - GitHub support - Docker - The ability to create http files and run them etc.
"It's pretty well known that non-graphical text editors that free from the mouse can be more productive and ergonomic than their counterpart like vs code and IntelliJ" - any reference to backup that claim? For the ergonomic of shortcut vs mouse, I have no issue, but being graphical has nothing to do with being counter-productive, and it's actually more ergonomic thanks to the formatting and overall awareness improvement (besides, I wouldn't mention ergonomics with a dark theme that is known to be bad for the eyes, and references to that abound). Fact is IntelliJ is entirely driven by shortcuts so there is no obligation to use the mouse at all. I wouldn't know about VS Code which is only a fine editor but not an IDE, just like Vim. Then you don't have to struggle installing a lot of add-ons and other programs running in the background to get almost the same functionality (but not quite).
It s not that hard. I basically just started last night by editing my softs. Trying to setup master them. TNice tutorialngs cos in slowly. But it ain't that
This kind of video is extremely useful. It’s like someone is chewing hard to digest food for you. Seriously, I tried Helix a couple of weeks back but didn’t have the patience to stick to it. This made me want to give it a shot again. Thank you for this and for all the videos you do, they honestly do a lot of difference. Keep it coming and thank you so so much for what you do.
edgeeffect I think editors should always make a best effort to reduce friction for newcomers, but I think the most productive / ergonomic editors will deliberately trade "beginner friendliness" for said productivity and ergonomics, because in many cases you can't have both.
I've configured (like 3 lines so far, as well as installing a bunch of language servers) helix actually just last weekend. While I tested it, I never really committed to Vim long enough to see benefits, and Helix seems a lot harder to misuse, and as you said, it's a lot easier to configure. The only negative thing I've to say so far is that the default theme is IMO ugly and also not very helpful. But they have a bunch of default themes installed (which they should refer to in the documentation, I might create a pull for that) which include some nice and helpful ones.
Nice! Yeah I agree the default theme is not something I would actually use, but it sure gives the feeling of "this is something completely different" in the promo material and screenshots. There are a TON of default themes included, I'd be shocked if you didn't find something you like.
It's worth mentioning that language support depends a bit on the richness and out-of-the-box useability of the associated LSP - e.g. Rust/Go/Python/Js is amazing, Java/Scala not so much (though I did eventually get Metals working once...).
I used helix for a long time and still love so many aspects of it, there were just some annoyance I had that I didn’t know how to fix due to lack of plugin support. It’s still my favorite way of using multiple cursors by far though, and a great project
@@katech6020 Maybe you are correct, but I'm not certain they've settled on wasm, though it is a top contender. There are three open topics anybody interested can check out: #122, #2949, and #3806.
This is definitely true. Can confirm. Weak computers don't even hold it back. I've seen 1500 loc lagging weak computers on vscode and even a bit of lag with nvim while Helix acts like it's just 15 loc.
@@fudgepuppy9683 I haven't used a particularly weak computer. Good to hear! I assume a potential issue would be running the LSP(s) though. Not to mention installing them. I know rust-analyzer will eat up all my computers resources, so I could see that one being particularly annoying.
Totally understandable - the thing I really struggled with when starting out was x and d - In vim x deletes a character, in Helix it highlights a line...
@@codetothemoon I've been arguing with contributors for some time and gave up coz they stick to kakoune editing model too hard and don't seem to leave it.
@@adsick_ua They made a decision for a highlight driven editing model at the very start of the project, so it's pretty understandable that they won't change it.
@@dpgwalter In vim you can also highlight first. For example compare vi)c with helix mi)c. Except in vim you can also simply do ci), ciw, cip, etc. Doing highlight first would be doing i)c, iwc, etc. It doesn't need to be inconsistent for the sake of copying vim while reinventing the wheel.
the part with yanking someone else's config in (neo)vim isn't right in my opinion. When I started out using neovim I just started building mine. Using someone else's just doesn't work
yeah maybe not everyone does that. Either way, I personally found (and I can't be the only one) setting up the config file to be a huge source of friction when first learning vim, when you're already struggling to learn all the motions.
Yeah, there's no way I could follow what I'm doing if I just copied someone's config. Still, something to be said that for (neo)vim, several hours dedicated to configuring, researching and installing plugins get you close to the functionality that VSCode (or Helix) have out of the box. Even if after config your setup is superior to those, that investment is a pretty huge barrier that vim advocates don't often talk about
That register yank/paste behavior is identical to vim, but you didn't mention thet double-quote pops up a window which _shows_ the value of all your registers. That is amazing. Thanks for the overview, I'd spent some time trying to learn kakoune and eventually given up as it was quite far from vim and I wasn't able to get fast at it. Helix seems like a better compromise in basing so much on vim, except the key bits they wanted to improve on and baking in a ton of good defaults. Great video!
I'm tired of switching modes, thinking about the current mode, thinking about the clipboard before copy paste something from the web browser, or to the web browser... Finally I just bound the hjkl keys to cursor moves in my Howl editor, and I'm happy !
This looks cool. I use SpaceVim (on top of neovim) and am happy. No reason for me to switch, but helix could be good for new users or those interested in learning stuff.
Great video! I would love to see another where you demonstrate your development workflow with Helix. Specifically check out a main branch, create a dev branch, stage, commit and push. Possibly show some unit tests and debugging scenarios? At the time of writing this, Helix doesnt have a folder view like nvim-tree. Nor does it have a builtin terminal. Helix is going in the right directions but not ready for my use case.
Thanks fabyao! as far as I know there is currently no git integration in Helix - that's being deferred to a plugin when the plugin infrastructure is in place. Same thing with debugging afaik. Generally speaking and to your point - until Helix plugins are a thing I think it's going to be missing some of the core non negotiable features many people need
I am very interested in learning a modal editor, but every time I try, it seem so daunting and overwhelming, I have to give up because I simply don't have time to spend relearning how to use an editor. One day, though.
No offense, but not only this editor didn't pick my rust project out of the box, but the default extensions provided by visual studio code are way more informative and helpful, than what I see on the video To be honest, I would rather be able to use f12, ctrl+f12 and shift+f12 to go to source/implementation and usings of a symbol, than have a hotkey to jump from one symbol to another inside of a file
The presentation is amazing! I wish people were introduced to programming tools this way in general. Anything non 100% essential is associated with elitists. Helix looks catchy, it puts up front what one would need. It gives me ideas on how to configure NeoVim better. The Toml configuration convinces me to refactor my NeoVim configuration to make it more similar. And why haven't I made key bindings for going to common configuration files
@@codetothemoon Yeah. I noticed though, LUA's local loop_these_leader_maps = { e = ':cd ~', t = 'a{}O', } can look similar to a Toml. Except the commas, and the loop that will be in the end. So that's what I ended up doing. I'm not saying it's superior. Helix took the slick and fool proof approach. Though I would vote for an init like script... But Toml works.
Ok, you've convinced me to give helix a try, I have to say I like that you have space mode and goto mode since they show you what you can do, whereas (n)vim requires a plugin or some other potentially action to get vim to display a list of what commands you can do.
nice, yeah it's worth taking for a spin. I love the visual reference as well - it really helps soften the learning curve because you don't have to constantly Google how to do things
I wish I knew how it was possible to remember 100's of keybindings like this. I would have to print them all out & plaster all over my walls (which defeats the purpose, as I would be 100x slower). Guess I am just slow.. lol
you'd be surprised at how quickly you wind up retaining them. There are really only a handful of "essential" bindings, and they become second nature after just a few hours of use. then you can practice new bindings as you get comfortable with those, so on and so forth - and before you know it everything you need is in muscle memory.
I hope this comment to be a respectful provocation. If helix is good why don't you use it on your videos? I liked hx a lot, it is fast, responsive some usages are great but the mnemonics for commands are horrible by default Why x select a line? I know vim have some of them too, but hx semi compatible layer makes me confused. It is easier to switch between Emacs and vim than from vim to hx because I need a different mindset
very valid question! the reason is although I like it a lot, it is not currently my favorite editor. That would be DOOM Emacs. both problems you point out resonate with me. vim keybindings are implemented by many editors, so becoming familiar with them is going to incur much less risk of "editor lock-in" than learning the Helix bindings, as similar as they may be. beyond that, the main issue I had with Helix which I'm not sure if they've fixed - doing "ci(" at the beginning of a line that contains a set of parenthesis did not automatically move the cursor inside the parenthesis and remove everything inside. That was one of the main things I was missing from vim. Also, I found the Helix equivalent of my most commonly used motions often required 1-2 extra key presses than they did in neovim/evil-mode. All this said, I haven't used Helix much since making this video and I intend on circling back to it at some point.
@@codetothemoon same feeling. Though helix is neat I also find pressing more keys either because the command is longer it because I am not smart 😆 I would definitely use hx as main editor if they added a vim mode to it. I use vim mode in pycharm because it become too mechanical by now. (It also gives me an extra clipboard layer which is convenient)
I wish I could switch back to helix (it was my first tui text editor), but I cannot handle two sets of keybindings at once. and I need to use neovim because vim is the only text editors on things I ssh into
I strugle to adapt to vim, mainly because I have to use eclipse at work... pflew... My main issues are: 1 highlighting before editing is my thing 2 I love multicursors 3 I do want to copy and paste from/to other sources/targets using my mouse 4 Costumizing is painful, copying someone elses confing also painful, cos its imposible to know their workflow. 5 normal regex search? From the video helix could be my thing :D
Nice yeah re: #1 you'll definitely like Helix better. Everything else on your list I think is covered by Helix. Re: #3 space mode has motions to copy/paste to and from the system clipboard, so you should be good there as well.
this is a tough one. The good thing is that there's tons of overlap between the two in terms of muscle memory, the main differences are the order in which you type things. So going one way or the other isn't a massive commitment like choosing between learning emacs (the defaults) or vim bindings is. If I had to choose, I'd err on the side of caution and start with the vim bindings, just because those are so much more ubiquitous at the moment (and will allow you to easily switch to something like emacs in evil mode if you'd like to). I'm still hopeful that Helix will implement a "vim mode", but last I checked there seemed to be vehement resistance to this amongst the maintainers.
"more productive". Maybe faster typing. I predate "graphical" dev environments, and productivity is about a lot more than faster typing. Have a preference, but c'mon.
I think we're actually on the same page here - in the video I say that non graphical editors "can be more productive". It depends on the person. Out of curiosity, being that you were around before graphical dev environments, what sort of setup are you using these days?
@@codetothemoon I've been an Apple dev for a long-ass time. So Xcode. Before that, Project Builder. And yes, I miss Interface Builder and Storyboards. I'm still utterly baffled that people want to do 2D programming in 1D.
Informative video. But ngl, there is some shade you are throwing on vim. Especially in the helix mindset section around 5:30 when you delete a word backwards. In vim u just do db to delete a word back words, so two key presses just as helix, so equally efficient.
You're absolutely right! I use 'dw' all the time but I actually hadn't ever thought to use 'db'. I'll add this to a pinned errata post, thanks for pointing it out!
i've spent far too much time troubleshooting my nvim config when a lsp or plugin changes behaviour or poops the bed that i'm so grateful they exist. I admire the defaults set by the team too, there's no longer a need to reach for Jetbrains / vscode when something breaks while needing to be productive
I tried Helix out for a bit when I first saw this video a few weeks ago. I thought it did some cool stuff but I stuck to vim. Today, I ditched vim. Love for the OG but Helix is just far more ergonomic to me.
nice! I sort of have my feet in helix and emacs right now, waiting to see how Helix plugin support turns out. Really excited as it seems like they might take the WebAssembly route, which would make plugin development a dream...
@@codetothemoon I feel you on the plugin support. I'm waiting on that and snippets. Hell, I'm currently running an unmerged feature branch just so I can label the items in the space menu. 😁
@@codetothemoon Well, without including emacs, I believe you are looking for the term "command-line editors" or "CLI editors". The command-line supports the mouse, so being command-line does not mean mouseless. There is just no correlation there. All I was highlighting is you were probably influenced by the thinking that "command-line is faster because it doesn't use the mouse" and you ended up conflating the two concepts. The command-line allows you to not use the mouse for lots of things, maybe for everything, but again, it is not a "no mouse" interface. Both vim and emacs support the mouse in their CLI versions. This is all I wanted to highlight. Emacs classification is more complex and beyond the scope of this answer. It is programmed as a GUI application that predated current GUI systems, so it turns out its GUI can run in the CLI.
It's great at what it does do, but I ultimately quit using it because there is no integrated terminal and no copilot support(as silly as it sounds, both is important for me, I use windows sometimes, so there is no tmux or whatnot, copilot is a massive help for boilerplate).
not silly at all - totally understandable. It seems like they have a solid foundation going but most folks (including myself) can't make the switch due to some missing features on the periphery
line-number: relative I *hate* this config setting when I'm trying to pair program with someone. Does anyone have a solution?? Scenario: Ok, one line 12, can you change the ... wait, I mean line 10, no, now it's line 18. Can you stop moving around please!??
I tried it, but make me unlearn vim so I went right back to neovim and continued there. It's still a good idea to have an alternative though. Great content.
20 Neither pray I for these alone, but for them also which shall believe on me through their word; 21 That they all may be one; as thou, Father, art in me, and I in thee, that they also may be one in us: that the world may believe that thou hast sent me. 22 And the glory which thou gavest me I have given them; that they may be one, even as we are one: 23 I in them, and thou in me, that they may be made perfect in one; and that the world may know that thou hast sent me, and hast loved them, as thou hast loved me. 24 Father, I will that they also, whom thou hast given me, be with me where I am; that they may behold my glory, which thou hast given me: for thou lovedst me before the foundation of the world. 25 O righteous Father, the world hath not known thee: but I have known thee, and these have known that thou hast sent me. 26 And I have declared unto them thy name, and will declare it: that the love wherewith thou hast loved me may be in them, and I in them. (Jn.17:20-26)
i rly like that Helix just offers lsp and good UX right out of the box.. when helix includes a plugin system i will try it and maybe move over. for now tho i rly do like how configurable and expandable Neovim is.
Thank you for this video! I learned some new stuff (and refreshed existing memories (DRAM pun, haha)) even after reading the docs and using `--tutor` (I've practiced until the end of chapter 4, so I was missing out on a lot of stuff)
Welp allow me to correct you about the first 20 seconds of the video As leet developer and expert in none graphical editor myself I wanna say that it doesn't make any difference, it's even counterproductive. I have used pycharm, vscode, emacs, and neovim and through out my experience I had no instance where I needed to switch editor just because I felt like not productive enough. While working with the terminal maybe it makes sense I don't need to open visual studio just to edit 2 lines of C, otherwise it makes no difference don't waste time trying to optimize beyond good enough. Like seriously it's the number one rule of programming "if it works don't fuck with it!" Now that I said what's on my heart I can continue watching normally
I was trying out some simple projects with golang with helix...(really love the Bindings and processes).... though i have enabled the lsp support for in the config(overriding default true),, i was previously getting some common snippets. like main snippets for the whole function body.... or fp for fmt.println(), but suddenly i could get those... i have save, refreshed and even commanded the lsp-restart... but no response...... any thing bad happened on my site or is snippets are really hard to find in helix yet...
I'm on my first steps on Odin Project. This stuff will be very useful soon. Thanks. This geometric animated desktop of yours is awesome. Would you mind to tell how to do it? Big hug from Brazil. Thanks for the vídeos.
So I'm curious about the "out of the box" syntax highlighting. On my machine I did have to install an lsp, but helix did recognize it without any configuration. I'm assuming you already had rust-analyzer installed? I bring this up because it was a point of confusion for me when trying this for the first time. This video is honestly a great reference.
actually landed on DOOM emacs with no immediate plans to switch to anything else. I still think Helix is great, but like many others at this point I'm waiting for the plugin narrative to mature a bit
Installed it: tried to fetch grammars, the fetch failed. Stdout: Stderr: error: The following untracked working tree files would be overwritten by checkout: I tried again. It fails because of a branch switch and it can not override changes. It does not log where it is checking out those files. I tried to find them. I did not find them. Gave up. Back to neovim in less than an hour.
This character movement stuff is so weird to me, because that's not how I write code. I use the mouse constantly. I copy and past constantly. I sometimes jump into nodejs, past code into it, and use splits, joins, maps, etc to transform that copied text into the code I want. I don't tap away at keys constantly.
I’m looking at the site and I can’t even find out if it’s native on Mac Apple silicon, or uses Rosetta. Such a fundamental question. No use googling because it has such a generic name, other software products called helix. Given up.
0:13 productivity of nongraphical editors [citation needed]. For me it is the exact opposite so that I don't spend weeks of tweaking of a glorified notepad
are you referring to the open file dialog? if so it's because there is a fuzzy search box, so if you type regular characters they will be typed into that box.
@@codetothemoon Yeah, I mean that the box could also have normal and insert mode, so if you wanted to type into the search box, you would have to type i to get into insert mode first. This would make typing to the search box a keystroke further, in return you will get hjkl motions to navigate. It's a subjective thing, I liked to see if there is a way to get this in helix?
Really like the highlighting by default meta. Other than that looks pretty similar to nvim, especially all the moon related vims coming out lately. I just wish one of these vim revamps a built in debugger and built in git diffs. Having different terminals open for lazygit and whatever debugger always ends up being too messy when I'm working across two or three repos simultaneously (gotta love microservice architectures) and the mental overhead is too much. I'd like a real ide in a terminal. Maybe i oughta check out that whole emacs thing...
@@codetothemoon Well there is nvim-dap and nvim-dap-ui. I use it on a daily basis and it's not bad at all. You can even reuse your existing launch.json file from VS Code.
A combo of harpoon.nvim for terminal management and fugitive/lazygit makes one nvim instance per repo in a collection of tmux tabs pretty ergonomic for me. +1 on nvim dap ui. I hit space h g to navigate to lazygit terminal (or create if it isnt running yet), then I can c-q for normal mode and either c-6 to go-to previous buffer I was editing or harpoon to marked files with space 1-6.
For anyone that tried copying his config, helix now throws an error if you have multiple lines that have "backspace". To fix this you do this instead: [keys.normal] "backspace" = { c = [":config-open"], s = [":w", ":config-reload"]}
There's one downside to using Helix in 2023 and beyond. The maintainer doesn't want to include support for tools like copilot because it's a commercial offering. It's something that seems really important now.
i agree that is really important. they do still plan to have plugin infrastructure thought right? so theoretically we should be able to have it even if the maintainers disagree with it?
