[HN Gopher] Helix: A Neovim inspired editor, written in Rust
___________________________________________________________________
Helix: A Neovim inspired editor, written in Rust
Author : behnamoh
Score : 396 points
Date : 2022-10-10 02:45 UTC (20 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Q-and-A wrote:
| Does anyone happen to know if there is a terminal IDE that more
| or less operates like the very basics of popular GUI IDEs? By
| this I mean has a file manager pane which can be manipulated by
| mouse, allows multiple open tabs which are selectable and
| closable by mouse, is generally mouse-aware with regard to cursor
| activity on the text, and operates as a regular user would expect
| (not modal)? The closest thing I've found to this is Micro, but
| the full IDE experience is missing.
|
| I know mouse-aware file manager and tab capabilities are possible
| in terminal IDEs, but I haven't seen anything that simply put it
| all together as a cohesive and easy-to-use whole that anyone who
| has used VSCode could quickly start using for basic editing of
| multiple files in a project.
| sanxiyn wrote:
| You may want to try Warp: https://www.warp.dev/
| __warlord__ wrote:
| You require to log in to use this. For me is a no no.
|
| Next thing you know... you have warp stories in your
| terminal.
| bartq wrote:
| Try https://github.com/AstroNvim/AstroNvim, mouse works nicely
| out of the box, there is also a files tree.
| anthomtb wrote:
| Can I ask why you would want such a mouse-aware terminal-based
| IDE? Because it sounds like an oxymoron.
| davidatbu wrote:
| Not OP, but I get their frustration. File browsing is not
| very amenable to keyboard based navigation IMO. I'm currently
| using fdfind through telescope.nvim as well as another neovim
| plugin for this, but I can easily see why someone would want
| to use a terminal based text editor, with a mouse based file
| navigation tool.
| Test0129 wrote:
| Not to shove Emacs into a Vim thread but Emacs file
| browsing is actually pleasurable. You can have a tree if
| you want (neotree) but C-x C-f with Ivy fuzzy search makes
| navigating really easy. It's one of the things I wish Vim
| had for a long time and one of the things that eventually
| drew me away from Vim to Emacs.
|
| Anyway, to add to your point there are also cases where
| highlighting a large chunk of code is often easier with
| mouse based nav.
| drekipus wrote:
| Emacs
| buf wrote:
| If people want to replace vim, they should not change the
| keybindings.
| exDM69 wrote:
| They not only change the keybindings, they change the editor
| paradigm from a verb-noun model (dw = delete word) to a noun-
| verb (wd = select word, then delete) model. Multiple cursors
| also have an effect.
|
| It's pretty close to vim keybindings, but the paradigm change
| makes it incompatible with 1:1 keybindings.
|
| That said, coming from 15+ years of Vim, I was felt pretty much
| immediately at home with Kakoune, and dropped right in to Helix
| with comfort.
| dm319 wrote:
| What do you think about beginning of line and end of line
| movements? Is it really home/end? Seems like a common
| movement to assign to far-away keys?
| kybernetikos wrote:
| gh beginning of line
|
| gl end of line
|
| Both key presses are home row, and as soon as you press the
| 'g', you get a little pop up telling you about them.
| scblock wrote:
| I gave Helix a try last week and I think there are a lot of
| things to like about it, but until it supports soft text wrapping
| for prose documents it's effectively useless to me. I'm not going
| to bounce back and forth between neovim and helix depending on
| whether I'm editing code, documentation, or personal notes.
|
| The comments on the open issue in Github are not particularly
| encouraging.
|
| https://github.com/helix-editor/helix/issues/136
| bobbyskelton41 wrote:
| I would say they're pretty encouraging. There's a
| straightforward path to implement it, and some work is being
| done on that front.
| aussiesnack wrote:
| As far as I understand from scanning the PR, there's been
| more than a year of discussion with no actual progress on a
| basic (if not in this case simple to implement) feature which
| is universally available in text editors. Helix looks nice in
| many ways (I installed it last night and have worked with it
| on a couple of Rust projects today) but it's clearly more of
| a research project with potential than current practical
| tool.
| bobbyskelton41 wrote:
| I wouldn't say so. It's taken so long because it hasn't
| been a priority for the developers, and nobody else picked
| it up.
| maxhille wrote:
| Quickly tried it out and feels quite good. Unfortunately I also
| have to use IntelliJ, where I use the Vim-Mode (IDEAVim plugin)
| and I would have a hard time toggling my muscle-memory multiple
| times a day...
| marliechiller wrote:
| does anyone know of any plugin which does the same as the
| IDEAVim plugin? I'd like to try this kakoune based layout in
| intellij for the same reasons but this is a bit of a blocker if
| I have to keep flipping between vim and kakoune bindings.
| bestouff wrote:
| Yes Helix has its own keybidings which may be nicer but need
| learning. I would have made it my daily driver if it had
| classic (n)vim bidings.
| plaguepilled wrote:
| Glad they had the nerve to diverge from the standard vim
| keybinds.
|
| (For those who like the traditional vim binds, I salute you, but
| I have craved an upgrade for a while now)
| aussiesnack wrote:
| I don't particularly like vim keybindings - actually the very
| fact that they become so much of a consuming hobby for many
| people speaks to me of real problems with them. But their
| availability in so many tools aside from vim/nvim makes them
| very practical, given things as they are. It's a bit like
| QWERTY. Ubiquitious presence can be more practically useful
| than intrinsic advantages.
| ziftface wrote:
| I wouldn't even say 'like', it's just that I don't see a big
| enough advantage to switch. I built up enough muscle memory
| over the years and while helix might be slightly better (I
| don't actually know how much better, but I tried it and the
| impression I got was that it was at most only slightly better),
| that slight improvement doesn't really make up for the cost,
| which is being really slow for a while until you get used to
| it. Also you're giving up all your plugins. Also, you're giving
| up universal support in pretty much every other editor, since
| there are vim bindings in emacs, vscode, visual studio, jet
| brains ides, xcode, etc.
|
| Vim isn't going anywhere, so it just makes more sense for me to
| continue using it. Maybe for new people they could get into
| helix? I love that there's more options for people and I hope
| they can cross-pollinate ideas. But it's a hard sell to be
| honest.
| plaguepilled wrote:
| Seems like we agree! I don't think there's much need for
| people happy with the existing Vim layout to switch, and Vim
| is still a very serviceable editor. My comment more spoke to
| my personal tastes around editors. :)
| stoeckley wrote:
| Helix is great! The out-of-the-box LSP for C++ is a major
| strength, no config needed for me compared to 100% of all other
| editors I've used. The context-aware popups are nice too, and the
| overall UI is snappy and fresh. Highly recommend if you are a fan
| of modal editing and willing to try something new.
| seagoj wrote:
| If it had vim key bindings, I might try it, but without them, I
| don't see how it's worth the effort to switch.
| psuresh wrote:
| Does this 'written in Rust, written in Zig, written in Go' make
| any difference in the user experience? See this often nowadays.
| the_mitsuhiko wrote:
| If "contributing to the project" is part of the user experience
| then yes.
| slazaro wrote:
| I assume, besides looking for contributors, that not being
| based on Atom or similar is a selling point.
| allisdust wrote:
| For an editor? Makes a lot of difference. The day intellij ide
| is rewriten in non gc/dynamic language, there will be a
| noticeable improvement in performance and number of times the
| ide has to be restarted because it ate all the memory.
| nkozyra wrote:
| If IntelliJ stuff were not GUIs and instead terminal apps I
| suspect that would be a pretty big performance boost, too.
| phao wrote:
| Directly, I believe this has more to do with people interested
| in the language seeing it being used in actual projects.
|
| Indirectly (a lot indirectly), sure. Maybe the software should
| perform better or maybe have fewer bugs because programming
| language X or Y is understood to help with those things. Maybe
| it showcases a more flexible architectural design, which leads
| to more potential features in future versions, etc.
| galangalalgol wrote:
| It also hints at the mindset and values of the creator.
| Communities around languages value things that may or may not
| line up with the qualities of the language they form around,
| but simply the fact they value those things is reflected by
| rhe things they produce. If people think a language is
| performant, then performance will be something their
| community values. If it is known for having a learning curve,
| their product might too.
| acje wrote:
| A bit like seeing <<car built in carbon fiber". May poke the
| interest in materials or imply different quality attributes
| and design intent.
| stonogo wrote:
| Yes, it's a useful indicator of how portable the software is. I
| can ignore systems software written in Rust because it only
| works in places that LLVM targets, and extending LLVM is a
| nightmarish process. I can ignore software written in Zig
| because until this year (or arguably last year) it's been a
| one-man hobby project, worth checking on again in about a
| decade. For now there are too many weird bugs that pop up if
| you use platforms different from the main developer. "Written
| in Go" means I at least have a chance of fixing deployment
| problems, becausae crosscompiling is easy and the language is
| fully self-hosted.
| Voklen wrote:
| Yes, because if it's a language I'm comfortable in, if there's
| a bug I can hop into the code and try fix it myself. I find
| this happens most often for me with Flutter projects to be
| fair.
| packetlost wrote:
| Yeah, it's a tool targeting developers. The language matters
| to a certain subset of people who don't throw their arms up
| and move on when they encounter a bug.
| ncmncm wrote:
| Right, except for libraries or language-specific toolchain, the
| only legitimate reason to mention language in the title is to
| suggest doubt it was possible.
| mvelbaum wrote:
| Hey ncmncm, I know this is off-topic, but I just wanted to
| say that I really enjoyed your informative comments on high
| performance low-latency architectures. I was wondering, could
| I ask you a question via email?
| flohofwoe wrote:
| Technically no, but quite often they are easier to install and
| tinker with than C/C++ projects (for instance usually you just
| need to clone the repo and run either 'cargo build' or 'zig
| build', and it mostly 'just works' no matter the platform).
|
| Some C/C++ projects which have switched to cmake are equally
| easy to build (well not quite: "mkdir build && cd build &&
| cmake .. && cmake --build ."), but it's definitely not the
| norm.
| davidkunz wrote:
| Yes it does:
|
| - Rust is a systems-level language and requires developers to
| be experienced in order to create big software components. This
| usually leads to better quality.
|
| - Rust rewards putting effort upfront (e.g. error handling,
| Option<T>, ...) leading to less bugs than more forgiving
| languages.
|
| - Rust uses zero-cost abstractions which enables efficient
| code. In other languages it's a lot easier to degrade your
| performance by accident.
|
| - Rust can easily create binaries for the most relevant
| architectures, so your programs tend to be portable.
|
| - The contribution story is great, your code tends to be
| correct and you don't need to watch out for many foot guns.
| I've done it myself for Helix and the experience was awesome
| [1].
|
| But take everything with a grain of salt, you can create bad
| software in every programming language.
|
| [1]: https://github.com/helix-editor/helix/pull/1967
| flohofwoe wrote:
| > and requires developers to be experienced
|
| Ah the old PS3 argument ;) We don't provide
| the 'easy to program for' console that (developers) want,
| because 'easy to program for' means that anybody will
| be able to take advantage of pretty much what the
| hardware can do, so then the question is, what do you do for
| the rest of the nine-and-a-half years?
| bitexploder wrote:
| Rust isn't easier for good reasons. Sony was just lazy.
| gnulynnux wrote:
| Yes. In my experience, Rust projects are always easy to
| install. Cargo is much nicer than, say, npm or conda.
| JaggerFoo wrote:
| I've used vi from Linux terminal sessions for more than a decade,
| and VS Code as a GUI editor now most times when not in a terminal
| session.
|
| Am I missing something not using a GUI vi editor? I came across
| some dude on YouTube that calls himself "The Primeagen" that
| swears by VIM, but I couldn't follow his use of it.
| p2hari wrote:
| Really like the sane defaults with Helix, just waiting like many
| users for the copilot integration. (https://github.com/helix-
| editor/helix/issues/1927)
| lampe3 wrote:
| On of the things with vim/neovim for me what was a deal breaker
| is that you could not turn off/on LSP's for different projects.
| So neovim got slow for me. I also don't wanted to copy my config
| for each project.
|
| Does Helix have a solution for this?
| nerdponx wrote:
| For what it's worth, you can definitely disable autostart
| conditionally in nvim-lspconfig, maybe using on_new_config and
| setting autostart=false therein.
| canMarsHaveLife wrote:
| How does it compare to LunarVim (https://www.lunarvim.org)?
| ar_lan wrote:
| LunarVim is entirely NeoVim with default plugins baked in and
| maintained. I would translate this back to just debating Helix
| vs NeoVim.
| RapperWhoMadeIt wrote:
| I am currently almost entirely developing in Go. And for that I
| have a highly customized Vim environment, which really took me a
| while to get to where it is right now (it works very well, thanks
| to the great 'vim-go' plugin). Nonetheless, I am starting to have
| to develop more stuff in other languages like js and Elixir, and
| I definitely do not want to invest all that time tweaking my
| vimrc to have all the IDE bare functionality that works so well
| in Go. I was starting to consider making the transition into
| neovim, but Helix sounds almost like a plug-and-play solution
| with sane defaults (which is exactly what I would like to have).
| Is it better that I go for Helix, or is LunarVim or AstroVim
| actually what I am looking for?
| stoeckley wrote:
| Helix is a simple install, easy to give it a try and see what
| you think. For most people, there's no configuration necessary
| to get started. I jumped through the hoops to get C++ tools in
| a variety of editors, and nothing was as simple as Helix for
| me.
| djaouen wrote:
| Without macros, I won't be switching anytime soon.
| AndrewVos wrote:
| You can record macros in helix.
| gnuvince wrote:
| It has macros.
| benvds wrote:
| Played around with a bit. In my experience compared to a
| configured vim:
|
| - once you have your local language servers available it works
| quite nicely out of the box. syntax highlighting, file finder,
| lsp navigation, formatting, etc. just works
|
| - its fast
|
| - i really like having the order of selection->action instead of
| action->movement
|
| - im still missing some features like a navigation tree and a
| quickfix list or something to do project wide find/replace.
| betwixthewires wrote:
| I already use this as my daily driver for everything, especially
| writing code. Have been using it for a few months. It gets better
| with every release. I love it.
|
| It's got a few quirks. Trying to navigate while in insert mode (I
| know bad habits die hard) will have you undoing a lot of
| unintended autocompletes unless you turn LSP off. Tab to complete
| is a _must_ for autocomplete features, and it should never
| autocomplete in comments or a completed line of code.
|
| So a little rough around the edges, but still wonderful to use.
| gnull wrote:
| I'm a Kakoune user. What will change in my life if I move to
| Helix?
| exDM69 wrote:
| I've used Helix for all my recreational programming projects (in
| Rust) for about 6 months and I've written about 10kLOC of code
| with it. Still using vim at $WORK for a variety of reasons (giant
| c++ codebase that does not easily plug in to clangd/LSP), but I
| might be doing the switch soon.
|
| Installation was easy and the default configuration is good.
| Plugging in rust-analyzer still needed a line or two of config
| file editing, but that should not be necessary for very long.
| Hint: use `hx --health` to check that all the tools are properly
| installed and configured (it shows a matrix of programming
| languages and their associated tooling, with red/green check
| marks).
|
| My Helix config file is about 5 lines long, but my Vim config is
| in the hundreds of lines.
|
| I had very little friction coming from Vim and a little bit of
| Kakoune.
|
| I particularly like the fact that all the important features are
| built-in and not half baked scripts with unintended side effects
| (e.g. opening a Makefile in Vim triggers a ftplugin script that
| messes editor-global config instead of buffer-local, with the
| default out of the box scripts).
|
| Lots of people are requesting a plugin extension system, which is
| kinda understandable since every editor seems to have one. But I
| haven't had a need to add any kind of plugin, and it's easy
| enough to fork a shell for an external process if needed.
|
| It's still rough around the edges, but good enough for a daily
| driver.
|
| Thanks to everyone working on the project.
| harryposner wrote:
| > But I haven't had a need to add any kind of plugin, and it's
| easy enough to fork a shell for an external process if needed.
|
| For me, coming from writing Clojure with Neovim + vim-sexp +
| vim-fireplace, I would need Paredit and REPL integration.
|
| Paredit is doable with Treesitter, and I'm actually really
| excited about Helix's Treesitter integration--- every time I
| write a non-Lisp language, I miss structural editing, so it'll
| be nice for other languages catch up to Lisp on that front. It
| doesn't really look like it's quite there yet, though. The
| built-operations that use Treesitter are spare [0], and while
| you could implement operations like promote, slurp, and barf
| with them, you'd have to clobber some register. I don't see at
| all how you could implement splice without an actual language,
| since you would need a way to select all siblings of the
| current node.
|
| REPL integration absolutely needs a plugin language. Unlike the
| LSP, there isn't a standard protocol for communicating with a
| REPL, so each language requires its own REPL client. Unless
| they want to ship a REPL client for every language under the
| sun, they'll have to provide some way for users to implement
| their own clients. That said, every time I look at Conjure,
| they've added REPL clients for more and more languages [1], so
| maybe it is feasible to have it built into the editor.
|
| [0] https://docs.helix-editor.com/keymap.html
|
| [1] https://github.com/Olical/conjure/
| exDM69 wrote:
| > Paredit is doable with Treesitter
|
| Yes, indeed.
|
| Helix has built-in paredit-like navigation using tree-sitter,
| the default keybindings are alt-i, alt-o, alt-n and alt-p.
|
| Maybe the Debug Adapter Protocol (DAP) used by vscode will
| solve the REPL issue in the future. Helix has experimental
| DAP support but it's still quite rough (but no Clojure DAP
| server yet).
| MontyCarloHall wrote:
| >I've used Helix for all my recreational programming projects
| (in Rust) for about 6 months and I've written about 10kLOC of
| code with it. Still using vim at $WORK for a variety of reasons
| (giant c++ codebase that does not easily plug in to
| clangd/LSP), but I might be doing the switch soon.
|
| Do you have some supernatural ability to quickly (re)learn
| muscle memory for new keybindings? I'd consider myself a fairly
| advanced vim user, and it took me literally a couple years to
| get to the point of fluently using complex navigation/editing
| commands.
|
| I took a look at the Helix documentation, and while it's
| definitely "vim inspired," it's different enough [0] that I
| would have to rewire years of muscle memory to be as productive
| as I am in vim. There are some very fundamental differences,
| e.g. the verb/object syntax is reversed in Helix; `dw` in vim
| is `wd` in Helix. When I want to rewrite a string in vim, I
| unconsciously type `ci"`; it would take me a long time with
| Helix to regain that level of fluency.
|
| [0] https://github.com/helix-editor/helix/wiki/Migrating-from-
| Vi...
| jerpint wrote:
| This was my same impression when trying out helix. Really
| nice and shiny, but all the shortcuts I've spent time
| creating over the years are gone and not easily reconfigured.
| Casperin wrote:
| Don't even try to reconfigure them. Try to learn the editor
| first as it is.
|
| If you think that's crazy-talk, then imagine someone saying
| they'd like to learn vim, but they find it hard to
| configure the shortcuts to be like Eclipse. They aren't
| wrong, but it also doesn't seem like the right approach to
| learn vim either.
| pigcat wrote:
| what does `ci"` do in vim? I'm decent with vim, but it didn't
| make sense to me - then I tried it and it didn't do anything.
| Agentlien wrote:
| ci is "change inner ..."
|
| If we use | to mark our cursor, and you have your cursor
| inside quote: '"he|re"'
|
| ci" would replace everything inside giving you '"|"' and
| putting you in insert mode.
|
| cab would aso remove the quotation marks and give you '|'
|
| With ce or cw you'd get '"he"' and cE or cW would give you
| '"he'
| thegeomaster wrote:
| Deletes text inside the nearest quotes and puts you in
| insert mode. You probably tried it without being inside a
| quoted string, that's why it did nothing.
| torarvid wrote:
| Change inside doublequotes. You can also do `ci{` or
| similar to Change inside curly-braces or `di[` to Delete
| inside square brackets
| exDM69 wrote:
| Cursor needs to be between double quotes (e.g. inside
| string literal) for ci" to work. See `:help text-objects`.
| Casperin wrote:
| After 20 years of vim I decided to try out Helix back in Feb
| and never looked back, so I guess I can chime in here.
|
| Sure, it took a few days (maybe weeks?) of feeling
| uncomfortable, but unlike vim, Helix is very approachable. I
| think you have to be okay with a certain level of feeling
| uncomfortable if you want to do or learn anything new though.
| If learning a new editor isn't your thing, then don't. :)
|
| I get this same question a lot when people realize that I use
| Dvorak layout. Sure, yes, it took time to learn. But I was
| curious if there was something better for me on the other
| side. It seemed plausible that there would be, so I gave it a
| shot. In both cases I have been happy with my investment.
| exDM69 wrote:
| The keybindings are pretty similar, the paradigm change from
| verb-noun to noun-verb and the multiple cursor paradigm are
| bigger changes. I got used to it with my brief affair with
| Kakoune.
|
| The Vim muscle memory will be quite helpful and not a whole
| lot of unlearning is necessary. hjkl navigation and other
| familiar concepts are similar in Helix and Vim.
|
| Vim ci" translates to Helix mi"c. After the first key press
| (m), a help dialog pops up.
| hamburglar wrote:
| hjkl are definitely table stakes for a vim-ish editor, but
| I also can't live without 0 and $. Making me move my hand
| over to find home and end misses the point of hjkl
| entirely.
| smsx wrote:
| I'm just learning helix, but I believe you can move to
| the end of the line with gl, and i'm sure there's an
| equivalent for the beginning.
| halikular wrote:
| Is there an alternative for g0, g$ and gj, gk? It will
| act on wrapped lines like they're separate.
| Casperin wrote:
| I opened helix to check it for you. Pressed `g` and had a
| little popup tell me that following with `h` = line
| start, `l` = line end, `s` first non-blank in line (plus
| ~15 other options).
|
| My hx doesn't wrap lines, so didn't check `gj` and `gk`.
| halikular wrote:
| If you don't wrap lines how do you write text?
| Casperin wrote:
| Good question, and I don't think my answer will satisfy
| your needs, but it does mine.
|
| The only long form text that I ever write is in markdown.
| I do miss the `gq` command from vim, but in general I
| just do a single line break after every dot. Markdown
| ignores a single line break in the middle of a paragraph,
| so it works out okay. I even found it almost convenient
| to edit text like that because it's easy to move lines
| around.
|
| In code documentation (which I do a lot of), I have to
| manually wrap the lines of course (just like anyone
| else). That's where I miss `gq` the most. :)
| [deleted]
| jarbus wrote:
| I've got the same question. One of the major reasons I invest
| time into vim is because it's everywhere and so powerful. If
| I invested time into learning a different set of keys for an
| editor that isn't always available, I wouldn't be able to
| leverage that power and fluency all the time, and
| furthermore, would need to switch back and forth between vim
| and helix keys
| haarts wrote:
| I've switch from years of Vim to years of Kakoune and am
| now trying Helix. While annoying I find I pick up the right
| keys fairly quick. A week until I get decent productivity
| back and a couple of months tops to truly get the hang of
| it.
|
| I find it immensely helpful that Kakoune and Helix _make
| sense_. It is also a great boon that there's visual
| feedback.
| jzm2k wrote:
| Seconding this. I had used Vim for nearly 8 years and
| felt very comfortable with all the crazy tricks you could
| do with modal editing but I genuinely felt Kakoune's way
| of doing modal editing was an improvement so I committed
| to learning it and it took maybe a month to get
| comfortable with the new way of editing. I'm really glad
| I took the plunge because I'm a really happy Kakoune user
| and I can't think of anything that I miss from Vim.
| halikular wrote:
| How does it improve on neovim? Seems to me like slightly
| different keybindings to do the exact same thing, you're
| not saving any keystrokes or fatigue as far as I can
| tell.
| eating555 wrote:
| I think the fact that helix doesn't really need a
| plugin/extension system is beautiful. It means that it's simple
| enough to config yet still powerful. Helix smooth out the
| learning curve in this good way and I hope it won't become
| complicated and make learning curve as deep as vim/nvim.
| Protostome wrote:
| I'm a big fan of open source software and have tons of respect
| for any OSS developer, regardless of the software he/she
| develops.
|
| But I have to say, as a developer who has been taking part in the
| OSS scence for the last 20 years, it is very strange to me that
| some developers feel obliged to indicate they wrote a piece of
| code with Rust.
|
| If I'm a user, I care much more that this is a usable software
| than what kind of programming language was used. For all I care,
| write it in binary. Rust may be a great programming language, but
| it is only a mean to an end.
| chatterhead wrote:
| Pretty sure the Rust nod is for the HN audience; not just a
| nebulous end user.
| cactus2093 wrote:
| I can think of several ways this is useful to know:
|
| 1. As OSS software, some users will want to edit the code and
| add features, and knowing what language it's written in is a
| pre-requisite to doing that.
|
| 2. The developer community is an important factor in making OSS
| projects successful. If I'm going to take a chance on a young
| project, I want to know that it is set up to have a strong
| community and continue to be improved over time. If it was
| hand-written in binary or assembly as you suggest, there is no
| chance it would grow a popular community of developer
| contributions.
|
| 3. Like it or not, different programming language communities
| have developed around different values in how to build
| software. The Rust community generally promotes strong type
| safety that makes entire classes of bugs much less likely which
| is a plus to me as a user.
|
| 4. With editors in particular, the language it's written in
| often leaks into the user experience. E.g. Emacs is written and
| configured in Lisp, Vim has a ton of legacy cruft in the C and
| vimscript codebase that can make it annoying to
| compile/install, annoying to build plugins for, and has made
| modern features like asynchronous tasks difficult to add, which
| was the whole reason for neovim existing. VSCode has plugins
| written in JavaScript. Knowing this project is written in Rust
| gives me some hints that it probably won't share any of these
| similarities with these other editors.
| hit8run wrote:
| Tried it a year ago or so and liked it. Offers smart defaults.
| contingencies wrote:
| Low contrast default color scheme = non-starter
| Casperin wrote:
| I got you. Put this in your ~/.config/helix/config.toml.
| theme = "bogster"
|
| Or type `:theme` and use tab to cycle through the themes (it'll
| apply the theme to the current file while you cycle, no need to
| hit enter).
| superkuh wrote:
| I don't understand why "in Rust" makes these irrelevant posts
| somethign worth of the HN frontpage. All it means is that you
| won't be able to compile it yourself unless you use a fast
| rolling distro or out of repository tools to get this month's
| compatible rustc with rustup or curl|sh, etc.
| bobbyskelton41 wrote:
| It sticks with the MSRV of Firefox, which is currently 1.61.
| rami3l wrote:
| I love to see that Helix tries its best to ensure an out-of-the-
| box experience, as well as to add so many interactive hints for
| key combinations (for example when you want to paste in insert
| mode with C-R it'll immediately list a set of registers that you
| can paste from).
|
| However Vim is much more to me. It's not just an editor, but a
| keybinding that I can use not only in nain, but also in VSCode,
| in fish shell, and even in GHCi REPL.
|
| How long would it take to make them all support (some reasonable
| subset of) Helix?
| cloverr20 wrote:
| I have not tried the editor itself, but one thing that puts me
| off is how some people are claiming its going to replace
| vim/nevoim and others by the virtue of its great LSP and tree
| sitter support. I am working as a full time developer for the
| last 4-5 years and I never needed to use auto complete (for long
| words C-x n is there) and the current syntax highlighting seems
| fine. Vim is working great for me and I don't feel any reason to
| switch to others. Instead of bashing other editors, maybe just
| tell what makes your editor unique and why people would want to
| use it?
| oefrha wrote:
| > by the virtue of its great LSP and tree sitter support.
|
| > maybe just tell ... why people would want to use it?
|
| Apparently they did tell you, and you're not interested. Fine,
| but what a pointless comment. Rob Pike will also tell you how
| he loves coding without syntax highlighting, which you
| apparently find useful.
| mpalmer wrote:
| It's not a "pointless comment". Why would someone want to use
| it _every day_ over Vim or Neovim? The only benefit of Helix
| specific to LSP and tree-sitter is the ease of configuration,
| a mostly fixed cost. Then what?
| oefrha wrote:
| That would be a reasonable comment, and people have been
| discussing that in this very thread. The one I replied to
| is "I don't use autocomplete, so you didn't tell me what's
| good about this editor, except you actually did and I even
| acknowledged that". Pointless.
| spion wrote:
| When you say you never needed LSP, do you mean you've tried it
| and found no benefit to having it, or do you mean you're doing
| just fine without it? (Because its possible to do just fine
| without it yet still find significant benefit to having it).
|
| What LSP does for me is instant documentation integrated into
| the editor and getting constant feedback if you get it wrong
| (at least from a typechecking perspective). I guess that in
| many cases, you can get something similar by having a
| documentation window open on the side as well as automated unit
| tests in a second terminal re-running on every save.
| cloverr20 wrote:
| I have tried using it few times but I didn't see much benefit
| of using it, I am mostly working with
| python/django/javascript/react and by now most of the common
| functions I already know, so I didn't see much use of it and
| tbh it felt a bit distracting to me when a big hover
| definition came when I am typing something.
|
| The times when I don't remember how something works, usually
| I have to go the stackoverflow answers/documentation to read
| on how it works, maybe try it out a few times in the shell,
| before writing the code. For typechecking and errors I have
| been using ALE and it does give a warning if there's
| something wrong and this setup is working fine for me.
| [deleted]
| awestroke wrote:
| Do you feel personally attacked by these people when they
| prefer newer, better tools?
| cloverr20 wrote:
| See I am not against newer tools, I am using a lot of newer
| tools myself like fd/rg. What I am against is claims like
| "Ths new tool will replace everything else that has been
| made". Let people decide what works for them and choose
| accordingly.
| tnfru wrote:
| He very explicitly stated what about the post was off-putting
| to him. You made a comment about being personally attacked
| while repeating the tool is better without any argument
| whatsoever. You're exactly proving the point of the comment.
| coldtea wrote:
| > _what about the post was off-putting to him_
|
| And the part that they listed as "off-putting" was a very
| tame and popular sentiment, to the point that it's off-
| putting itself (or at least bizarre) to be "off-put" by it.
|
| Not to mention that the whole comment is based on a bizarro
| claim amounting to "who needs LSP/treesitter anyway" and
| how they can't see the point of those (probably the most
| requested features from any new editor), since he "never
| uses autocomplete".
|
| Still, "I can't see the point for feature X" and "I never
| use X" are totally fine. But saying that people saying they
| appreciate them and consider them important is "off-
| putting"?
| awestroke wrote:
| No, they stated that they personally have no interest in
| using better tools (lsp, autocomplete etc).
| 411111111111111 wrote:
| No, they contextualized that these improvements aren't
| actually improving anything for them, as they're not
| actually interested in using these features. And thus,
| it's no longer a better tool _for them_.
| [deleted]
| tnfru wrote:
| He is saying that these tools aren't improving his dev
| process and therefore are not better for him.
|
| Better is also such a subjective feeling - please either
| quantify the improvement or don't present it as an
| objective truth.
| coldtea wrote:
| > _He is saying that these tools aren 't improving his
| dev process and therefore are not better for him._
|
| That would just be a personal preference thing, and it
| would be fine if they just stated that and left it at
| that.
|
| But they also mention how they are "put off" (wtf) from
| people who claim that the LSP/tree-sitter support makes
| this a viable candidate to replace vim/neovim.
|
| Saying you're being "put off" by what others use, is no
| longer a "this is what works for me" claim. In this
| context, the "I never needed to use autocomplete" sounds
| like some ill-conceived bragging point.
| kazinator wrote:
| The commenter stated clearly that they are not put off by
| what others use but their _claims_ that their shiny new
| toy is going to replace everything in a couple of years.
| Those people are just trolling; trolls are off-putting.
| coldtea wrote:
| > _Those people are just trolling; trolls are off-
| putting._
|
| Trolling means saying something you don't believe in to
| start a ruckus/annoy people/make a flame war.
|
| People saying that an editor done in the spirit of vim
| can replace vim/neovim, since it has LSP/tree-sitter
| support (which translates to: since it, on top of what it
| inherently has, automatically gets auto-complete/lint/etc
| support for all kinds of languages) is perhaps a little
| over-optimistic but in absolutely no way does it
| constitute trolling.
|
| Now, the commenter would be fine to state that they're
| put-off by claims that "this is going to replace
| everything in a couple of years".
|
| But, for starters, nobody stated that "it is going to
| replace everything in a couple of years". Just that it
| could, over due time (not "a couple of years") gain
| traction over vim/neovim and perhaps others for users
| wanting a vim-like editor.
|
| Besides, he explicitly wrote that what puts him off is
| not that claim alone, but "how some people are claiming
| its going to replace vim/nevoim and others by the virtue
| of its great LSP and tree sitter support".
|
| -- that is, he is put off people touting "LSP/tree-
| sitter" as features relevant to this editor gaining
| popularity. He even uses "I never needed to use auto
| complete" as some kind of supporting argument that others
| shouldn't consider those features important either...
| kazinator wrote:
| > _Trolling means saying something you don 't believe in
| to start a ruckus/annoy people/make a flame war._
|
| No it doesn't; please don't make up word semantics to try
| to make people look wrong. It's childish and pointless.
|
| A disruptor cannot be absolved of trolling by it being
| confirmed that they believe in their own statements; a
| good many trolls are invested in their message, not just
| in disruption activity.
|
| > _nobody stated that_
|
| The put-off person was relating experiences from
| elsewhere to which you have no access to be able to say
| that. But in fact, I think I saw very similar remarks in
| comments under this very HN submission.
|
| Some people are put off by trollish
| OS/language/editor/hardware/whatever advocacy. And water
| is wet, and dogs bark.
|
| > _how some people are claiming its going to replace vim
| /nevoim and others by the virtue of its great LSP and
| tree sitter suppor_
|
| That literally means "the outdated shit you're using
| ain't gonna be here before long, now that we have this",
| which is trolling even by your definition that
| incorporates disbelief in one's own statements.
| pornel wrote:
| For a long time I had the same opinion (using Sublime Text with
| its plain same-file autocomplete). It's okay, but after using
| LSP for a while, I'm sold on it. It really is nicer, and I
| wouldn't go back to my pre-LSP times.
|
| "Go to definition" and "Find references" is faster and more
| precise than grepping, especially for common function names.
| This lets me browse larger codebases, even if I don't remember
| their layout.
|
| Being able to peek at actual types of variables is quite useful
| in Rust which has type inference. I can check types instead of
| deducing issues out of compile errors.
|
| LSP support for like "Extract into function/module" are great
| for refactoring eliminating most of the busywork. Renames are
| also more reliable than find'n'replace, especially when I'm
| renaming because the name is ambiguous.
| kkkrist wrote:
| I feel you. Vim has been such a staple in my dev life. So much
| that switching felt like betraying sweet uncle Bram ;-) And
| without the need to write typescript, I probably wouldn't have
| switched. But what made me stay even for non-typescript work
| were the little things, like the positions in the location and
| quickfix list being auto-updated while editing, being
| (feeling?) faster and more responsive, the saner default
| settings (server usage) etc.
|
| Regarding lsp integration, it's just nice to have project-based
| instead of buffer-based auto-completion, auto-insertion of
| import statements etc. Definitely makes me more productive.
| Setting it up the way I wanted (non-obstrusive, on-demand) was
| a bit of pain though.
| lancebeet wrote:
| I use vim with ale. Linting, go-to- definition etc. for
| typescript (or really any other language I use) just works
| automagically. It took more effort to get it working in
| vscode. I haven't tried neovim or helix yet. They both seem
| great, but it seems to me that people here might be slightly
| exaggerating the difficulty of getting this working with
| regular old vim.
| kkkrist wrote:
| Well, I tried ALE and it worked ok. Compared to the neovim
| built-in lsp client it just doesn't display as much info
| and does not support multiple hints per line. There's also
| CoC which should also work with regular vim and which I've
| used for a while, but it wasn't very stable for me (the
| auto-insertion of import statements made it crash
| frequently for example). The built-in lsp client seems to
| be the cleanest, fastest and most stable implementation.
| Using nvim-lspconfig it was fairly easy to set as well. It
| just took me a while to find out how to disable all the
| distracting live-/auto- completion, underlining, inline-
| hints etc. (vim.diagnostic.config)
| tiffanyh wrote:
| Some interesting stats:
|
| - Helix has 624 open issues (1,103 closed) [0]
|
| - Vim has 1,172 open issues (5,518 closed)[1]
|
| - NeoVim has 1,258 open issues (7,496 closed)[2]
|
| - VSCode has 7,463 open issues (136,638 closed) [3]
|
| [0] https://github.com/helix-editor/helix/issues
|
| [1] https://github.com/vim/vim/issues
|
| [2] https://github.com/neovim/neovim/issues
|
| [3] https://github.com/microsoft/vscode/issues
| darkwinx wrote:
| could you explain what you find interesting from this stats?
| totetsu wrote:
| how is this pronounced? H E double hocky stix?
| nerdponx wrote:
| I assumed it was just the English word "helix", which in AmE is
| pronounced like "he licks".
| aussiesnack wrote:
| I gave it a try out of curiosity with Rust, which you might
| reasonably expect to be well supported. But it didn't start a
| language server. So I followed the docs to find out how and was
| none the wiser. A tad undercooked, I'd say.
| Acur wrote:
| The language server should work by just having rust-analyzer in
| you path. You can check with 'hx --health rust'.
|
| It also only works on Rust projects, not single files. You have
| to open helix with the path to the project folder for it to
| work.
| aussiesnack wrote:
| Yep thanks that does the trick.
| newaccount2021 wrote:
| exDM69 wrote:
| Make sure you have rust-analyzer installed, and check `hx
| --health` to see that Helix finds it.
|
| Not sure if this is still necessary, but I needed this
| workaround in ~/.config/helix/languages.toml:
| language-server = { command = "rustup", args = ["run",
| "nightly", "rust-analyzer"]}
|
| This should not be necessary when rust-analyzer is stabilized
| (may be already), but last time I tried it still needed
| nightly.
| aussiesnack wrote:
| Thanks. Hadn't realised I needed to have the lsp server
| binary on the path. I think nvim-lspconfig takes care of that
| for me in nvim.
|
| From a brief experiment basic lsp usage seems to work in
| helix without any config changes, so perhaps that's changed
| since you set it up.
| drekipus wrote:
| This, people say it's no configuration but I had no idea how to
| make python work, and that's even after I got l figured out I
| had to --install-grammars our whatever the command was.
|
| Documentation is missing, it's a bit scattered
| newaccount2021 wrote:
| phao wrote:
| By the way... which font is being used in the readme screenshot?
|
| https://github.com/helix-editor/helix/blob/master/screenshot...
| quic5 wrote:
| Looks a lot like JetBrains Mono but I'm not 100% sure
| cercatrova wrote:
| See also Lapce, an editor also written in Rust although it's
| trying to compete more with VSCode rather than Vim.
|
| Also, RIP OniVim 2, it was great having been written in a
| similarly fast ReasonML/OCaml but the creator ran out of funding
| and had to get a job. A shame, it even had compatibility with
| VSCode extensions.
| skavi wrote:
| Does anyone know what happened to Zas editor [0]? I was a huge
| fan of the concept (a mac-assed app [1] with first class Rust
| support).
|
| In fact, I was such a fan that I bought it, which has turned
| out to be a rather foolish move. The people behind it have gone
| completely silent.
|
| [0]: https://news.ycombinator.com/item?id=30952084
|
| [1]: https://daringfireball.net/linked/2020/03/20/mac-assed-
| mac-a...
| mgrandl wrote:
| Yeah seems like a scam. I paid for it, requested an invoice
| and never got a reply. Never received a single software
| update either.
| sullyj3 wrote:
| Oni was presumably dead in the water as soon as they switched
| from Neovim to vim, as the initial backers would have been
| primarily composed of neovim enthusiasts
| IshKebab wrote:
| Lapce is looking really promising IMO. It's _very_ fast, has
| single-click support for a few languages (Rust of course) and
| the UI is surprisingly complete.
|
| Obviously there are still a ton of paper cuts but it's still
| very impressive and they are very welcoming of contributions.
|
| The only thing that concerns me slightly is that they're using
| their own fork of Druid which was pretty much labelled a failed
| experiment by its primary author (though tbf he still seems to
| be working on it). On the other hand the UI mostly looks and
| works really well! I've only noticed a couple of niggles -
| misalignments, labels not linked to check boxes, ugly context
| menus on Windows etc. (and that last one is mostly Windows's
| fault).
| xigoi wrote:
| Unfortunately, it doesn't seem to be programmable yet, although
| the FAQ says there are plans for implementing a plugin system.
| ufo wrote:
| The FAQ currently mentions that they're planning on
| implementing a LISP dialect. I wonder why they chose that
| instead of an existing language (e.g. Lua, Tcl, or Guile)
| cod1r wrote:
| I've tried helix and it doesn't seem as customizable as
| neovim/vim. I also prefer neovim/vim's default keybindings much
| more. While I can't see helix replacing neovim/vim, I can see
| people using it, as it has defaults that could appeal to some
| people. It's also fast.
| coffeeblack wrote:
| Looks very interesting. But what do the "plans for a GUI" mean
| for the terminal version?
| mbStavola wrote:
| IIRC the plan is to migrate the core logic into a library that
| can be consumed by either a CLI or GUI. There were also some
| discussions of collaboration with the Neovide folks, something
| that I personally found very exciting as Neovide is an
| excellent Neovim client.
|
| However this was last year, not sure what the current status of
| all this is.
| p-e-w wrote:
| I fully expect Helix to replace Vim, Neovim, and Kakoune for most
| users in the long run.
|
| Helix is built from the ground up around Tree-Sitter and LSP.
| This means you get the best syntax highlighting available, and
| IDE-like functionality, with zero configuration required other
| than installing the appropriate language server.
|
| Those are _by far_ the most important features for a text editor
| to have, and crucially, they are fully integrated into Helix, but
| are an afterthought in (Neo)vim and Kakoune. The quality
| difference is obvious the moment you try it side by side. Nothing
| else really matters. Vim 's and Kakoune's syntax highlighting is
| terrible, and while Neovim can now use Tree-Sitter as well, there
| always seem to be some additional hoops the user needs to jump
| through in order to get it to work. Not so with Helix.
|
| Regrettably, Helix has inherited Vim's worst design flaw, namely
| being unusable with non-English keyboard layouts, but all other
| Vim derivatives share this flaw as well so I don't see that
| stopping Helix from steamrolling the competition once it matures
| and the word spreads.
| BeFlatXIII wrote:
| Even as a Colemak user, the ergonomic benefits of hjkl
| navigation are utterly lost on me. It's left me stuck as an
| arrow keys plebeian.
| TobTobXX wrote:
| Just remap them?
| WhyNotHugo wrote:
| If find motions in neovim a lot easier to reason about than
| those in helix. A lot of actions that are pretty easy on neovim
| are a huge pain on helix.
|
| I do appreciate Helix as a research project investing in new
| ideas, but I do feel it a lot more limited. Everything
| keyboard/motions related just feels much more limited than Vim.
| For example, re-doing actions makes little to no sense because
| most actions tend to be split in two. `3dw` can be redone just
| fine on neovim, but not on Helix.
| ratorx wrote:
| Do you have any specific examples of things helix does better
| than neovim?
|
| I think the neovim implementation of LSP and treesitter is
| quite nice. It was not that polished when I tried it last, but
| I think once it becomes mature, it will be really flexible.
| Tree sitter specifically is still considered experimental, but
| I think the timeline for that to be better integrated will be
| significantly faster than it takes for any new editor to get a
| decently sized community around it.
|
| The zero config part of it is nice, but I think you'd be
| competing with e.g. VSCode with modal bindings on that note.
| Vim/Neovim have always had a fairly steep learning curve, and I
| can't see that aspect of it mattering as significantly,
| especially since I only see LSP/Treesitter support improving in
| neovim.
| p-e-w wrote:
| There's a difference between having a "learning curve" and
| having to spend effort setting up things that work out of the
| box in another editor.
|
| Vim advocates generally claim that investing time learning
| the Vim keybindings pays off as saved time during later work.
| But that's not what's happening here. If LSP just works in
| Helix, and requires fiddling with config files in Neovim,
| then Neovim is wasting my time, not teaching me something
| that will be valuable later on.
| dahfizz wrote:
| This may be a factor for brand new devs, but everyone who
| uses vim already has it setup, by definition.
|
| One time setup cost is a small factor in choosing an
| editor. Stability and ubiquity are more important IMO.
| callahad wrote:
| Any sufficiently complex "one-time setup cost" quickly
| becomes an ongoing maintenance quagmire. And I say that
| as a full-time neovim user for the past seven years.
|
| Neovim is still my favorite vi, but I think I erred when
| I started bolting on so many plugins and supporting
| processes... when I want a lightweight IDE, I'll use VS
| Code.
| aussiesnack wrote:
| > One time setup cost is a small factor in choosing an
| editor.
|
| Perhaps for you, but empirically for devs as a
| population, this is very clearly false. A large part of
| the reason for VSCode's near-takeover for new devs in the
| last few years is its frictionless setup for almost
| everything.
| ratorx wrote:
| Yeah, learning curve may not be the best way to phrase it.
| But I think that is the price of flexibility to be able to
| create an editor in which you don't have to use LSP if you
| don't want to.
|
| Personally, I think keeping Neovim the editor separate from
| something like nvim-lspconfig is pretty nice right now, to
| be able to update them separately, which is nice for new
| languages and language server changes. Maybe it (and the
| broader LSP ecosystem) will eventually be mature enough to
| be included by default.
|
| I'd also say that if you want zero config, just using a
| config framework (there are a few), gets you most of the
| way there, whilst retaining more of the flexibility but
| that's not a strong point in favour of Neovim.
|
| Still, until Helix gets a comparable community and some
| features over a properly configured neovim, I think it will
| be hard to displace it (and Vim, EMacs etc.) because Helix
| doesn't currently doesn't as anything significant for
| existing users.
| norman784 wrote:
| For me personally is better because it works out of the box
| and their built in features are most of the things I need,
| fuzzy finder for files in the project, opened buffers, LSP,
| syntax highlight, etc.
|
| If you are an old vim/nvim user, you already know deeply your
| editor/ecosystem and your config file is very solid, you
| definitely won't like helix at least yet, you need to learn
| to do everything the helix way and not the vim/nvim
| customised way you build all those years.
|
| So I will say that for developers that are starting using
| terminal editors, helix is a very good starting point,
| because of the built in stuff that it seems essential at this
| point in time for an editor to already have and that might be
| what helix does better.
| rjzzleep wrote:
| Sometimes treesitter has problems. Indenting has gotten worse
| and configuration is a lot more complex.
|
| I have the same config with some neovim / vim specifics and I
| find myself using vim more often even though the neovim
| features are "cooler".
|
| I wonder if it will ever become "mature". It doesn't crash
| for that matter, but you have to keep everything updated
| constantly. Vim doesn't really have that problem.
|
| Helix looks cool too, but I was looking for what it has that
| the others don't have and I can't figure it out. The website
| just makes it seem like it's cooler than the others.
| ratorx wrote:
| Treesitter is still a bit iffy. LSP is a bit better, but is
| still not amazingly mature (but some of this is to do with
| the LSP servers themselves not being that mature).
|
| Other than that, I haven't had any problems with Neovim.
| Everything else has been rock solid, and I haven't needed
| to update frequently for anything else. Have you
| experienced other issues?
|
| However, these are the larger "killer" features of neovim,
| so at this point there's not that much over Vim. However,
| there aren't any Vim features I use that are missing in
| Neovim either. There are a couple of minor things that push
| Neovim over though (`inccommand`, Lua is marginally nicer,
| Neovim plugin scene has exploded recently).
|
| So since Neovim (for me) has feature parity and equal
| reliability, with some really nice added frills and some
| moderately reliable, but maybe not incredibly mature,
| killer features it still beats Vim in my book.
| skavi wrote:
| I like Helix, but it feels slow compared to Neovim. As in the
| actual scrolling performance. No one else has mentioned this,
| so I wonder if that's an issue on my machine.
| sph wrote:
| Might it be your terminal that too slow to render? You might
| want to try one of the many GPU accelerated terminals like
| Kitty, alacritty, wezterm, etc
| skavi wrote:
| I use alacritty. And I use Neovim on the same terminal.
| luispauloml wrote:
| >Those are by far the most important features for a text editor
| to have
|
| I'd say that those features are useful for _source code_
| editing, not text in general.
| p-e-w wrote:
| LSP goes far beyond source code. It also covers an increasing
| number of markup and configuration languages, and there are
| even language servers for prose that perform grammar checking
| and offer style suggestions.
| kazinator wrote:
| Problem is, all of that sounds like a lot of crap to have
| running, and a lot of dependencies. That is not everyone's
| thing.
|
| I like to be able to type "ps" and see one process for my
| editing session (with a low VM footprint in the low double
| digit megabytes at most, which had a startup time in the
| low hundreds of milliseconds.)
| Version467 wrote:
| I'd say that has been true in the past (and is still mostly
| true today), but I think this will change in the future. I
| have been using lsp+treesitter for markdown editing and it's
| been an excellent experience. It's still early days, but with
| treesitter and lsp being as universal as they are I've been
| seeing a lot of people just experimenting with what's
| possible.
|
| So yes, they are essential only for source code editing, but
| it's quite exciting to see what they can do for general text
| editing.
| b3morales wrote:
| I am curious, what features does an LSP server provide for
| such a simple format as markdown?
| nine_k wrote:
| I'm looking forward to seeing Org Mode implemented as a
| language server. It's unfortunate that such a great general
| text organization tool is locked into the relatively small
| Emacs user community.
| medo-bear wrote:
| orgmode is so not a markup language and cant be served
| via lsp. its a whole ecosystem built on top of emacs.
| short of rewriting it, implementing it fully in another
| editor would require a sort of virtual emacs machine
| running in the background
| nine_k wrote:
| Typescript or Rust are also not markup languages, and
| language servers for them allow for many interesting,
| non-trivial operations, so the model is capable.
|
| Ergonomic keybindings would be a challenge though.
| medo-bear wrote:
| org-mode is more a program than a language. how would you
| implement org-capture or org-agenda through lsp?
| [deleted]
| senko wrote:
| > Helix is built from the ground up around Tree-Sitter and LSP.
|
| Sadly, that achievement is compromised by having to call into
| unsafe code.
| tmdh wrote:
| Unsafe code is not bad code.
| atoav wrote:
| Have you checked what that unsafe code does? Unsafe code is
| not bad per se, there has been quite a bit of discussion
| about the naming of _unsafe_ and many are of the opinion that
| it should have better been called something like _trustme_ to
| clarify that the code must not be necessarily _unsafe_ , just
| that the borrow checker doesn't fully check here, which for
| certain core algorithms can be necessary.
|
| As long as the content of those blocks has been carefully
| checked there is no problem with using unsafe.
| funklute wrote:
| > just that the borrow checker doesn't fully check here,
| which for certain core algorithms can be necessary
|
| Why is that? Does this imply that there are certain
| algorithms you simply can't write (efficiently) when using
| the borrow-checker? (I don't know Rust btw, but have plans
| to start learning very soon)
| sushibowl wrote:
| Missing some nuance, but that description is not too far
| off. The ownership/borrowing concept is based on the idea
| that every piece of data has a single owner. Particularly
| in cyclical data structures, it's not very clear who
| should have final ownership over what. This can make
| graph-like data structures somewhat difficult to express.
| p-e-w wrote:
| > just that the borrow checker doesn't fully check here
|
| That's incorrect. The borrow checker performs the same
| checks inside `unsafe` blocks as everywhere else.
|
| `unsafe` blocks can perhaps best be summarized as areas of
| code where _memory_ safety rules are relaxed. The borrow
| checker deals with _ownership_ , and ownership rules are
| still fully enforced inside `unsafe` constructs.
| p-e-w wrote:
| Vim, being written in C, is 100% "unsafe code", so this
| doesn't bother me much.
| Test0129 wrote:
| Accacin wrote:
| I just can't see if ever taking off, if I'm honest. The people
| that use neo/vim are going to continue using it, even if Helix
| is better. The people who aren't yet using it will use vs-code
| and the few that do switch, well they might go to Helix but
| there's a lot of vim resources out there, so I'm not sure all
| of them will go to Helix.
|
| Honestly, language servers are a bit of a faff to set up, but
| that's tooling and it's getting easier and easier to get these
| installed now. I expect that will continue.
| least wrote:
| > I just can't see if ever taking off, if I'm honest. The
| people that use neo/vim are going to continue using it, even
| if Helix is better.
|
| I would think that helix probably _is_ better because I 'm
| certain that the verb->text object paradigm in vim could be
| much better. It may in fact make more sense to do the 'text
| object' first like it seems to do in both helix and kakoune.
| But is it better enough for me to switch off something that
| I've used for years now? Only if it sees mass adoption and
| you see many developers adopting it. Like if you see it in VS
| Code as an option to use helix bindings, then it is probably
| safe to consider adopting it.
|
| > Honestly, language servers are a bit of a faff to set up,
| but that's tooling and it's getting easier and easier to get
| these installed now. I expect that will continue.
|
| I've been pleasantly surprised with how much better LSP setup
| in neovim has gotten, as I've transitioned over to the native
| LSP from CoC, which is also excellent. It's still not pain-
| free to setup, but it's much easier than it was and I suspect
| you're right that it'll continue to get easier... though I
| doubt it'll get anywhere close to how easy VS Code is to use
| any time soon.
| HowardStark wrote:
| While I was going through the effort to set up DAP support,
| I discovered
| [mason.nvim](https://github.com/williamboman/mason.nvim)
| which has been a game-changer for LSP, DAP, and linter
| setups.
|
| There had previously been fragmented plugins
| (williamboman/nvim-lsp-installer was Mason's predecessor
| and is a good example) that solved the problem of
| installation and management for each of these. With Mason,
| I feel that the story for managing different language
| environments has jumped to be extremely close to VSCode's
| extensions.
| the_mitsuhiko wrote:
| > The people that use neo/vim are going to continue using it,
| even if Helix is better. The people who aren't yet using it
| will use vs-code and the few that do switch
|
| I'm not so sure. I have been using vim for years and I still
| do, but in the last few years the majority of my use has been
| vscode with the vim plugin. I have seen the same pattern in
| many others.
|
| Helix is right up my alley and I'm definitely playing with
| it. It's not a straight vim replacement for many reasons and
| it's also not yet a vscode replacement for me, but I'm very
| excited about it and I can absolutely see it replacing my use
| of vim sooner or later.
| Voklen wrote:
| I've tried to make the switch to Neovim from Vscodium before
| but there was so much configuration for all the language
| stuff (and I'm not the biggest fan of Lua). But after seeing
| this post and installing Helix it's been pretty painless so
| far and I think this can actually help me make the switch. I
| am about to try some configuration for Rust debugging but
| that shouldn't be needed once they've got full DAP support. I
| use Neovim as my standard text editor so the navigation and
| bindings aren't a problem, lets see if Helix can make my IDE
| be in the terminal too.
| rjzzleep wrote:
| For the longest time I was using YouCompleteMe with vim and
| then tried all sorts of LSP servers. And while I'm still
| using them, I feel like that YouCompleteMe solution back in
| the day had a lot less fiddling involved. Sure they have
| more features and more selection and variety nowadays, but
| I have spent so much more time configuring things that I
| kinda regret it now.
| isatty wrote:
| > Those are by far the most important features for a text
| editor to have
|
| The most important feature of a text editor is that it can edit
| text well. Vim is popular because it's the best _text editor_
| not because it has a bunch of plugins making it an IDE.
| discreteevent wrote:
| > the best _text editor_
|
| Code is text. So it is good to have a very good text editor
| for manipulating it as text. But code is also very different
| from plain text. It is highly structured. When I think about
| code I think about it as some kind of syntax tree (call
| hierarchies etc) . I don't think about it as character
| buffers. So if I am programming and I can have something that
| supports good text editing but also good tree editing then I
| will take that over something that only does good text
| editing.
| Myrmornis wrote:
| I agree with this. I have never been a vim/neovim/helix
| user, so there's little I can contribute here. But I have
| always used paredit commands as much as possible, in all
| languages, not just lisps, and that's still true now that
| I've switched to vscode from emacs. I'm curious whether any
| vim/helix editing operations are "tree-based" in a similar
| way to paredit, and also whether anyone's building a
| paredit-like editing system based on treesitter.
| alwillis wrote:
| _I fully expect Helix to replace Vim, Neovim, and Kakoune for
| most users in the long run._
|
| Yeah, that's not going to happen.
|
| It's cool to have choices, but you wouldn't be the first person
| to think a new editor is going to replace Vim/Neovim. Vim is
| literally on every Unix/Linux server; every sysadmin can count
| on it being there.
|
| I've been super impressed with the progress of Neovim and the
| team behind it. It's only at version 0.8 but they've done some
| amazing things already.
|
| I expect Neovim will get to the "batteries included" stage with
| Treesitter and LSP; it's not far from there right now. And
| there are several Neovim distributions (LunarVim, Nvchad, etc.)
| that have all of the bells and whistles included. Helix sounds
| like it's similar to one of these Neovim distributions.
|
| Again, Neovim gives you choices: you can configure and tweak it
| to your heart's content if you want or you can get something
| pre-configured with all the goodies installed and configured.
| Or you can use it headless from a different frontend (VS Code,
| browser, etc.) if that's what's needed.
|
| Perhaps the best thing about Neovim is how great it is for both
| longtime Vim/Vi users _and_ brand new users who are ready to
| graduate from Notepad and Nano.
| usrnm wrote:
| > Helix is built from the ground up around Tree-Sitter and LSP
|
| And what happens in ten or twenty years, when both are
| obsolete? I don't really care, what technologies my text editor
| is built on top of, but I sure would like to be able to still
| use it for writing my memoirs when I'm old.
| p-e-w wrote:
| LSP will not become obsolete, it will evolve. The entire
| industry is rallying around LSP, and Microsoft is constantly
| improving the protocol. In "ten or twenty years" LSP will
| have become a required feature for every programming language
| and every text editor. It will be essentially impossible to
| replace it with any other technology because of the massive
| investment already made in the ecosystem.
|
| I can imagine Tree-Sitter slowly losing importance because
| LSP is integrating semantic highlighting, but Tree-Sitter
| will still be an easy option for writing grammars in the
| absence of a full-featured language server.
| [deleted]
| daptaq wrote:
| I can easily imagine a comment like this being written 30
| years ago where "LSP" was replaced by "tags files".
| [deleted]
| bee_rider wrote:
| I mean you still wouldn't use an editor without ctags
| support, right? That's just a bad smell.
| b3morales wrote:
| Unless the protocol changes to specifically address this, I
| find it unlikely that LSP will ever be a full solution for
| real-time syntax highlighting. The amount of JSON that has
| to be slung interprocess on each edit is just too much.
| Providing _extra_ semantic highlighting on top of a built
| in option, absolutely, but I don 't think it can replace an
| in-process, specifically incremental option like Tree-
| sitter or Sublime/TextMate language defs (or a completely
| custom solution like JetBrains, Nova, etc.).
| agumonkey wrote:
| parsing is not a fad it has less chances of becoming
| obsolete, if any
| norman784 wrote:
| > And what happens in ten or twenty years, when both are
| obsolete?
|
| I assume helix will be constantly evolving those ten or
| twenty years.
| renox wrote:
| > Those are by far the most important features for a text
| editor to have
|
| The most important feature of an IDE is to be easy to use,
| having powerful functionalities is important too, but that's
| goes after.. VSCode has _nailed_ the first point. Wake me up
| when (neo)vim /kakoune/Helix has a "list of tab view" similar
| to VSCode..
| stackbutterflow wrote:
| What's a list of tabview?
| renox wrote:
| VSCode has a vertical 'subwindow' on the left which list
| all the opened tabs. I call this 'a tab view/list', I don't
| know what's the real name.
|
| Usually I have between 10 and 20 tab opened, so the tablist
| is very helpful for navigating between tabs.
|
| Unfortunately (AFAIK) the 'fast' editors (vim, kakoune,
| etc) don't provide such feature. Some have a tree list but
| not a tab list :-(
| da_rob wrote:
| Built something like this a few years ago:
| https://github.com/roblillack/vim-bufferlist
| drekipus wrote:
| (neo)vim/kakoune/Helix are not IDEs so you're going to be
| asleep for a long while yet.
| e12e wrote:
| > Regrettably, Helix has inherited Vim's worst design flaw,
| namely being unusable with non-English keyboard layouts
|
| How so? I find the default helix shorcuts to be generally quite
| close to "ascii text input" - that is: ctrl, shift, alt, a-z
| and regular punctation?
|
| FWIW I work on a Norwegian layout on a Mac, which is rather
| horrible for programming and shell use (option-7 for pipe,
| shift-option-k+space for tilde (!?), shift-option-7 for
| backslash, shift/option/alt + 8,9 for brackets ...).
|
| I do miss "leader" from vim/neovim - and autocompletion from
| buffer (when there is no language support, like configuration
| files).
| Liquid_Fire wrote:
| > How so? I find the default helix shorcuts to be generally
| quite close to "ascii text input" - that is: ctrl, shift,
| alt, a-z and regular punctation?
|
| Try it with a non-Latin script language. It's borderline
| unusable.
|
| Nothing works in Normal mode. You have to manually switch
| back to English any time you switch to Normal mode and back
| to the other language in Insert/Replace mode, or when typing
| parameters to things like :s.
|
| No other editor requires you to switch language back and
| forth just to use the editor's commands.
| darrenf wrote:
| > _I fully expect Helix to replace Vim, Neovim, and Kakoune for
| most users in the long run._
|
| I feel like I am definitely not in the "most users" group here.
|
| > _syntax highlighting_ ... _IDE-like functionality_
|
| > _Those are by far the most important features for a text
| editor to have._
|
| The most important features for me are the ability to navigate
| around and manipulate whatever's in the buffer(s) efficiently.
| I'm a 30 year vi/elvis/vim user and ... I'm not going to be
| able to use this. The deviations from vim's keybindings are
| much too widespread and tbh I find improved syntax highlighting
| and (especially) IDE-like functionality significantly too weak
| a draw to invest any effort in learning the Helix way - only to
| context switch between local Helix and remote vi(m) throughout
| my day anyway.
|
| I tried, really I did. Opened up a file I'm actively working
| on. First thing I needed was `dd` and to my horror it didn't
| delete a line, but two characters. Turns out vim's `x` is
| Helix's `d` - except not quite; `5d` doesn't do what `5x` did,
| in fact the 5 does ... nothing?
|
| OK fine, well, I regularly use `V` to highlight groups lines
| and delete those (or pipe them through my equalprg, or
| `:'<,'>!`) so I tried that ... nope. Though imagine my surprise
| when I tried `5x` and it highlighted 5 lines. Why didn't 5
| apply to `d` but did to `x`?
|
| I tried `:r!<some cmd>` but alas, no `:r` and in fact no `:!`.
| All these examples are things I do _tons of times every day_.
| So I read the "Migrating from vim"[0] document really hoping
| there was a "activate vim compatibility mode" thing but instead
| all I saw were the new sequences I'd need to learn, especially
| ones which require more keypresses such as:
|
| go to line first non-blank character: vim: ^
| helix: gs
|
| go to line end: vim: $ helix: gl
|
| delete to line end: vim: D helix:
| vgld or t<ret>d
|
| Investigating more, I found `:insert-output` is the same as
| `:r!` - tried to map the latter to the former to no avail. I
| kept finding other things that pissed me off just while I was
| editing the config file (with helix itself). I want to turn off
| all the menus which pop up everywhere as soon as I hit `:`. I
| hated that every time I typed a double quote, it inserted two -
| I literally never want that, in any language, ever.
|
| So many showstoppers for me, which is a shame. Perhaps I could
| configure the hell out of it - going against what many other
| folk are proclaiming as sensible, sane defaults - but then I'm
| back to where I came in. All the effort to make it be like vim
| except with some syntax stuff I don't really need... no sale.
|
| [0] https://github.com/helix-editor/helix/wiki/Migrating-from-
| Vi...
| fgeiger wrote:
| Two out of three examples for sequences that you provide are
| not shorter in vim.
|
| At least on my (US) keyboard, typing `^` takes two key
| presses (Shift + 6), as does typing `gs`. The same is true
| for typing `$` (Shift + 4) and `gl`.
|
| When reading the migration guide as a decade long vim user, I
| actually found myself to think that some sequences in Helix
| are improvements over the ones in vim. For instance, `gs` is
| easier than `^` because both g and s are on the home row.
|
| I do agree that going from `D` to `vgld` is a big change. If
| it is consistent throughout the UX, it might not be that big
| of a deal, though.
| darrenf wrote:
| I don't think I'd agree that two simultaneous keypresses is
| equivalent to two in sequence. But besides which, `^` and
| `$` are so ingrained with _meaning_ to this grumpy old Perl
| coder that abandoning them is an extremely hard sell.
| Perhaps I 'd be OK with `\A` and `\z`.
| e12e wrote:
| In addition to the helix resource, you may or may not want to
| look at:
|
| https://github.com/LGUG2Z/helix-vim/blob/master/config.toml
|
| I think most of the "muscle memory" bindings there are a bad
| idea (helix is _different_ from vim - if you don 't want
| that, I recommend neovim).
|
| As for "dd" - that would be (as indicated in your quote)
| select line, delete (yd) in neovim.
|
| Similar for delete to end-of-line - the second form is
| probably the "most helix like" - in being somewhat
| discoverable and "interactive" v(isual mark) return (end of
| line) d(elete).
|
| As for filtering selection through pipe, or reading command
| output - they are also different:
|
| "!" in normal mode is "insert-output" (r! in vim), while pipe
| is "filter" - eg, after selecting three lines, hit "|" then
| input "sort<enter>" - and the selection is piped through
| sort.
|
| As a long time vim user I agree that helix is alien - but I
| also think the change to selection-action is good for
| discoverability (the <space> context menu, interactive
| feedback on multiple replace) - and makes more sense.
|
| I still would like to see <leader>, and some "shortcuts" like
| "dd" (but I'm not sure what would be "best fit" in the world
| of helix for that. I don't think "dd" is a great choice.
| bsnnkv wrote:
| Always cool to see people share one of my repos in HN
| comments! I hope you're having a good Monday
| darrenf wrote:
| > https://github.com/LGUG2Z/helix-
| vim/blob/master/config.toml
|
| Thanks, I may give Helix another spin with that config. I
| saw the note about it being necessary to recompile, which I
| can't be bothered to do so I guess I won't get everything
| but it may get me through most of the day with less
| frustration (especially now I've turned mouse support off
| too; the cursor moving when I click to raise my terminal
| window was incredibly frustrating).
| e12e wrote:
| Fwiw I use some of that config with helix from macports -
| no patches.
| parentheses wrote:
| The existence of multiple editors of varying ages still in use
| today shows that tool choice is not a hard and fast X > Y
| thing. This personal choice is multi faceted and complex.
|
| In software engineering, the proliferation of OSS is at the
| heart of what makes this craft great. Many passionate people
| create and recreate tools for the same "job". All this happens
| with strong pressure towards public, inclusive and open
| communities around them. The fact that the method and medium
| require the same general skills means we can think very deeply
| about tool choice.
| jeksn wrote:
| Can someone elaborate on why Vim doesn't work well on non-
| english keyboards. I use Vim occasionally using a Nordic layout
| but would like to know why English is superior.
| mnsc wrote:
| I'm a nordic-layout user as well and whenever I look at the
| actual differences side-by-side I get reminded about how much
| easier it would be to code if I had all those symbols that
| close.
|
| https://www.farah.cl/Keyboardery/A-Visual-Comparison-of-
| Diff...
|
| And for me I'm pretty sure that this "remap everything and
| translate every tutorial" barrier is why I never have been
| able to get into vim.
| gunnihinn wrote:
| I grew up with the Icelandic layout. When I started
| programming professionally I taught myself the en-us layout
| and stared using that instead. It is much easier on my
| hands and fingers; it really does show that the people who
| came up with the syntax for most of the programming
| languages in use picked things that were easy to type on a
| US layout and didn't give any thought to the rest of us.
| gsinclair wrote:
| I'd love to know what the result might have been if they
| gave some thought to the rest of you. And if a person is
| designing a programming language syntax, I don't see why
| keyboards that are foreign, even unknown, to them merit
| much consideration.
|
| BTW I really don't think the en-us layout is actually
| nice on hands and fingers. All the programming symbols
| are a stretch. I now use Karabiner to make easy key-
| chords for all the symbols, e.g. f-j is ( and f-k is ).
| mnsc wrote:
| I tried that once, but already back then my muscle memory
| wasn't having it. Now I'm too old to put down the
| required hours to relearn and get back up to speed.
| least wrote:
| I do not think there's a particularly feasible way to
| facilitate every keyboard layout out there, so it makes
| sense that they are at least built with one keyboard
| layout in mind, much like I think it makes sense that
| programming in general is overwhelmingly done in English.
| It increases interoperability significantly.
| WhyNotHugo wrote:
| On a Latinamerican keyboard (yet, that's a thing), the
| brances are not as convenient. IIRC, the ~ symbol isn't even
| around. Semicolon is shift+right right finger -- super odd
| compared to just pinky. And ^ is behind right-alt (the one in
| the photos shows where, but many don't actually have it
| printed on the keycap).
|
| Here's a photo of the layout: https://image.shutterstock.com/
| shutterstock/photos/279261125...
|
| As an Argentinian, I've no fucking idea why we have our own
| layout instead of just using ISO Spanish.
|
| It doesn't look terrible, but believe me, switching to US
| English International was a one-way trip.
| frodetb wrote:
| Here's some advice from a Norwegian who programmed in Vim for
| years on the nordic layout: do yourself a favor and get an
| American keyboard ASAP. The brackets alone are worth it.
| luplex wrote:
| All the hotkeys are more accessible on English. Things like /
| are just one keystroke instead of two, and so on.
| unsafecast wrote:
| It's really not, so long as you map hjkl to the appropriate
| key sequence on your keyboard. Everything else is based on
| mnemonics, not locations, so I is just I.
|
| Maybe some stuff might be quicker because it's on the first
| layer, but if it's so bad you can map those specific keys.
| Test0129 wrote:
| I can see Helix replacing Vim and Neovim for the most "normal"
| user. It's great, and it's a better alternative than VSCode for
| Vim users that aren't quite power users but also not exactly
| the most basic user either.
|
| However, until I can fire up a new installation of *nix and
| type `helix` to begin editing things it will never replace good
| 'ole Vim.
| bee_rider wrote:
| I don't see it. If you want IDE features in a text editor, you
| can use VSCode, it even has vim bindings that are at least
| trying (with middling success) to match the originals. The
| addressable market for Helix seems to be (neo)vim users who
| aren't picky about keybindings and new users who want a
| terminal editor in 2022. So... on the bright side the
| developers can probably have one-to-one conversations with all
| 10 of these people.
| elromulous wrote:
| > I fully expect Helix to replace Vim, Neovim, and Kakoune for
| most users in the long run.
|
| I hope this doesn't come off as flippant: I thought your
| comment was sarcastic at first.
|
| While I love seeing newer / better software displacing the old
| and crusty, this seems a little unlikely, no? It seems like
| somewhat of a miracle that neovim has taken as much share as it
| has.
|
| P.s. I'm hoping to eat my words one day.
| p-e-w wrote:
| > It seems like somewhat of a miracle that neovim has taken
| as much share as it has.
|
| It's not a miracle but rather a testament to how much Neovim
| improves upon Vim. The number of _useful_ features, among
| them Tree-Sitter and LSP, that Neovim has introduced has
| ended what feels like decades of stagnation in Vim
| development.
|
| Now imagine an editor like Neovim, but instead of working
| through 30 years of cruft and legacy code, it's built from
| the start using modern software engineering techniques and
| incorporates such features into its core editing model.
| That's essentially what Helix is. The Vim -> Neovim
| improvement is nothing compared to what Helix will deliver
| (and already is delivering in many aspects).
| pg999w wrote:
| > Now imagine an editor like Neovim, but instead of working
| through 30 years of cruft and legacy code, it's built from
| the start using modern software engineering techniques and
| incorporates such features into its core editing model.
|
| User inertia is strong. Neovim has its success because of
| its improvement, but more importantly, the keymap and
| config language is based on Vim7. Vim7 users can painlessly
| switch to Neovim with all config preserved. That's the main
| reason why Neovim can gain a large number of users
| initially. Conversely, Helix has no keymap nor
| configuration compatibility with Vim or other mainstream
| editors. Given this, I see no hope that Helix will become
| mainstream.
| polotics wrote:
| Based on my observation of colleagues' dominant usage of
| IntelliJ-originated editors, I think that modal-editors
| users are far enough from the mainstream that some rules
| dont apply: Heliy may end up dominant in our pocket-
| universe, based on merit alone.
| thebeastie wrote:
| If by keymap you are referring to default key bindings
| then it's extremely similar. I'll definitely be giving it
| a whirl.
| bee_rider wrote:
| IMO it is not that surprising that neovim has had some
| success, in the same way that it isn't very surprising that
| SwayWM has had some success. They both have the benefit of,
| in many cases, being completely compatible with the tool they
| want to replace. Being almost completely compatible with the
| old tool, while integrating a popular new technology (LSP or
| wayland) seems to be the only way to win over users who
| already have a strong connection to their tools of choice.
|
| My vimrc already has a bunch of configuration in it, I'll
| give Helix a try when it is able to parse that (so, probably
| never, I guess).
| dahfizz wrote:
| > Those are by far the most important features for a text
| editor to have
|
| To you, maybe. The most important features of an editor for me,
| and for many people, is that it is stable, dependable, and
| ubiquitous.
|
| There is no way I am going to re-learn years of muscle memory
| for a "post-modern" editor. Cool and trendy is the exact
| opposite of what I want in my tools. What happens with the
| authors get bored and move on to the next shiny thing?
|
| Vim is available on ~every machine I could possibly interact
| with. There is a vim mode in every single mainstream editor /
| IDE. My Vim muscle memory will keep me productive for the rest
| of my life.
|
| IMO, making something slightly nicer to configure is never
| going to overcome the inertia of a project like Vim. The new
| editor would have to be like 3x better to convince everyone to
| make the switch, not 1.1x better in some specific areas.
| BanazirGalbasi wrote:
| > Vim is available on ~every machine I could possibly
| interact with.
|
| This is my exact reasoning for sticking with Vim. I use
| Neovim on my desktop, but I work with servers and have a
| homelab where I just want the greatest common factor. Nano is
| also an option, but just like you, my Vim muscle memory is
| embedded and I end up with :wq everywhere.
|
| Is Helix cool? Absolutely. Will it replace [Neo]Vim? Not
| until it's installed by default everywhere, and that won't
| happen unless it has a compatibility mode for Vim shortcuts.
| 0xbeefeed wrote:
| You're only saying this because it's written in Rust, aren't
| you?
| BaculumMeumEst wrote:
| I think you're overestimating the likelihood that Tree-sitter
| is going to gain enough traction to be reliable for general
| purpose text editing. It's great for popular modern languages,
| but not for everything, and there's no fallback in Helix. I'm
| not convinced that's ever going to change.
| p-e-w wrote:
| Reliable? I trust Tree-Sitter's grammars a hundred times more
| than the underspecified regex monstrosities that power
| highlighting in other editors.
|
| Tree-Sitter grammars are unit tested, have usable primitives
| for precedence and associativity, and are generally far more
| predictable than previous highlighting systems.
|
| Also, name a language for which there is no Tree-Sitter
| grammar yet. The only remaining ones are so obscure that the
| missing "fallback" is irrelevant for 99% of users.
| BaculumMeumEst wrote:
| Python, Janet, Haskell, and Hare were the filetypes I
| remember either being unsupported or not working well. I
| need to be able to depend on basic language support from my
| text editor, even when I work with niche languages.
| WhyNotHugo wrote:
| I've been using Python with tree-sitter on neovim for
| many months. It's great, and has a lot of improvements
| when compared with the old syntax system.
|
| Re Hare: I haven't even set that one up. Setting up a new
| tree-sitter on neovim requires extra work for each tree-
| sitter, and that's definitely a flaw that needs to be
| addressed.
| dmortin wrote:
| > I fully expect Helix to replace Vim, Neovim, and Kakoune for
| most users in the long run.
|
| Is there anything preventing other editors from integrating LSP
| and making it work out of the box without any configuration
| other than adding a language server?
| p-e-w wrote:
| What's preventing it is their existing codebases, mostly.
|
| IIRC, one of the first things Neovim did was throw out
| literally tens of thousands of lines of legacy code from Vim.
|
| Meanwhile, Helix can just add the `lsp-types` crate as a
| dependency and they're already a quarter of the way to making
| LSP work.
|
| The difference between adding something to a 30-year-old C
| project and a new Rust project is so massive that it can
| actually be the difference between "fairly straightforward"
| and "essentially impossible".
| sullyj3 wrote:
| Right, but Neovim does in fact have LSP support. That part
| is done, that's not a blocker for the It Just Works
| experience. It's that the editor currently doesn't come
| with the relevant configuration (in vimscript or lua).
| chipotle_coyote wrote:
| While the Mac-only editor BBEdit isn't open source, it _is_
| a 30-year-old C++ /Objective-C project, and BBEdit 14 added
| LSP support which is largely exactly what the comment
| you're replying to suggested: install a language server
| somewhere on your path and BBEdit will find it and use it.
| It's preconfigured for a couple dozen popular ones, and
| adding ones it doesn't know about out of the box is usually
| just as as easy as filling in a couple fields in a dialog
| box.
|
| I agree with you in principle, but in practice I'm not
| convinced this is an insurmountable hurdle for other
| editors.
| wvh wrote:
| I have been trying out Helix for the last few months as part of
| my now 24 year quest to incorporate some form of vi into my daily
| routine. This time, it's looking good. What sets it apart are the
| (zero-conf) built-in LSP and tree-sitter highlighting, and the
| select-verb modal keybindings instead of vi's verb-object syntax,
| where you see what you're about to do before you do it. Some of
| the key combinations also show a reminder menu, aiding the
| learning process, which is a nice touch over plain old vi which
| has zero discoverability. General performance is also very good,
| the editor feels a lot snappier than a fully loaded Neovim or
| Doom Emacs, or a monster like Visual Code.
|
| I think there are plans to see if a graphical editor could be
| built on top of it, which would be an interesting project. As a
| new Rust graphical tree-sitter based editor, it would probably
| rival the upcoming open-or-not Zed editor by the Atom folks.
| rjzzleep wrote:
| I actually think that the place where it could potentially
| really shine is when you have to do remote shell work. I don't
| know if you can specify the runtime folder but if you use it as
| a simple replacement for nano on old machines that don't have a
| proper editor this would be perfect.
| kamaal wrote:
| vscode is very good at this, and is the primary reason why I
| even use it.
|
| Frankly speaking the vim/emacs lines are yet to catch up with
| this sort of thinking. vscode feels like you are editing on
| the local machine. The experience is seamless and feels
| magical.
| caeril wrote:
| >> when you have to do remote shell work
|
| > vscode is very good at this
|
| I'm sorry, but what? VSCode over ssh? Huh?
| wdroz wrote:
| VSCode remote ssh extension [0] allows you to develop
| remotely almost like locally.
|
| [0] -- https://code.visualstudio.com/docs/remote/ssh
| dmillar wrote:
| It could be cleaner. My understanding is that you need
| different extension(s) to manipulate files requiring
| elevated access (e.g. sudo).
| sceadu wrote:
| You can use tramp in emacs?
| monsieurbanana wrote:
| I can't vouch too much for it as I've used it for maybe 1
| hour tops, but the remote capabilities of vscode were
| pretty seamless for that one hour.
|
| Emacs+Tramp definitely does not feel like you're editing
| locally. A surprising amount of things work, but many
| others will fail in annoying ways or are just clearly not
| supported.
| kamaal wrote:
| Tramp in all honesty was not that seamless, its just that
| these are great editors, but they were not invented in
| the context of the overall changes in how programming is
| done today. To me the biggest plus of emacs/vim is they
| make it easy to navigate and manipulate text, that's
| pretty much it.
|
| Every other feature seems to be an after thought
| therefore is not subject to the same experience the
| modern editors have. They also have a huge learning and
| set up time, and can send you down configuration hell for
| lots of things.
| mattrighetti wrote:
| Zed is more aimed towards collaborative development at the
| moment, at least this is how it's marketed on their website.
| fordsmith wrote:
| Man, I don't know what has happened but the spur for new
| editors has.been delightful. I have been using Zed for a bit
| since I made it into the closed beta, but it has been very nice
| to use. VSCode does the job pretty well, but it just feels more
| clunky to me, and I have hitches quite often. It is not bad,
| but I want something more performant while giving me the style
| of vim and emacs. Zed definitely has some rough edges and some
| sorely missing features (that are being worked on), but it just
| feels better to use.
|
| I know so many people probably discount these projects because
| of the RIIR meme, but it really has spurred more inovations
| that we should all be grateful for.
| caeril wrote:
| > Man, I don't know what has happened
|
| My guess is that 4coder kicked all this off.
| dilap wrote:
| RIIR doesn't scare me at all -- as a user, my experience has
| been the rust rewrites are usually high-quality improvements
| over the original. Ripgrep is legendary!
|
| It is a huge accomplishment of Rust to enable the creation of
| better versions of lang-standing highly-optimized-C tools.
|
| (Which inspired me to kick the tires a bit on the language;
| it felt like C++ done right to me. Being able to write
| threaded code w/o fear of data-races is very cool.)
| tambourine_man wrote:
| For the uninitiated: RIIR = Rewrite it in Rust
| dm319 wrote:
| One of the reasons I love n/vi/m is the ergonomic benefit of
| using keys that are close to your touch typing position. I'm a
| bit disappointed that beginning and end of line in helix are home
| and end.
| vulcan01 wrote:
| You can also use `gh` and `gl` for start and end of line (and
| `gs` for first non-whitespace character in line). These options
| (among others) pop up when using helix and typing `g`.
| dm319 wrote:
| Ok, so in vim I'd type 'd$' as "delete to end of line". What
| is the equivalent in helix?
|
| EDIT: while I'm here, where are the sentence and paragraph
| movements?
| [deleted]
| Acur wrote:
| The fastest way to do this in Helix would be `t<Enter>d`.
|
| edit: Paragraph and other object movement/selection is done
| by the `[`, `]` menu. `]p` for the next paragraph.
| Surrounds are done by the `m` menu.
| dm319 wrote:
| Thanks, that's helpful.
|
| I get it - so 't' is 'to' and enter is new line. Makes
| sense.
|
| The menu under `[` looks good, but very code-focused and
| lacking sentences.
|
| EDIT: I am finding it a bit weird to have 'go to's as
| different to movements. There isn't a distinction in vim,
| which is useful. I'm learning that 'ge' will take me to
| the end of file, but I can't do 'ged' to delete to there.
| bobbyskelton41 wrote:
| You can do vged. Currently ge takes you to the last line,
| but there is a change planned to take you to the absolute
| end.
| doix wrote:
| Super cool to see another competitor in this space. There's no
| support for tabs, I really hope it's coming and they implement
| them in the same way vim does. So far the buffer/window
| implementation matches vim (as far as I can tell), so I really
| hope the tab implementation matches as well.
|
| If they could implement the client/server architecture of
| kakoune, then this would really best editor (for me). It's a
| shame each editor implements a different subset of all the
| features I like and I'm always choosing between them.
|
| Edit: Looks like there's an issue for tabs:
| https://github.com/helix-editor/helix/issues/2295 , doesn't have
| too much traction. I hope someone picks it up, unfortunately my
| rust sucks far too much to get it done in any reasonable amount
| of time.
| gnull wrote:
| Tabs should be implemented by an external tool, like Tmux or
| whatever. This is how Kakoune does it.
| doix wrote:
| Kakoune has a client/server mode so that the client instances
| can talk to the same server. This way unsaved changes to a
| buffer are visible across instances + all the registers etc
| are shared.
|
| Helix doesn't have that functionality. Kakoune also doesn't
| have splits at all where as Helix does, so the design
| philosophy is different between the editors.
|
| Personally, I would prefer if tabs were first class citizens
| in the editor, but would make do with scuffed tabs if there
| was a server/client model implemented.
| [deleted]
| nine_k wrote:
| From the description, the architecture is nicely modern.
|
| It's also interesting to see a project that seems young to
| already be version 22.
|
| What I tried to find and could not was some built-in language,
| more expressive than the one used to describe syntax
| highlighting. This means that extensibility is at best not a
| priority,
| davidatbu wrote:
| FWIW, the maintainers have been exploring various extensibility
| solutions. For e.g., I remember seeing a PR to allow a WASM-
| based plugin system, though I think it was abandoned because of
| the tradeoffs it posed.
| makapuf wrote:
| Interesting, do you have a link ?
| timokoesters wrote:
| https://github.com/helix-editor/helix/wiki/FAQ#how-to-
| write-...
| pikelet wrote:
| It's just date based versioning, so 22.08 is August, 2022.
| willeum wrote:
| Tried it a few months ago
|
| Felt more responsive than neovim/neovide, and out-of-box was
| great.
|
| However, while the selection > verb scheme conceptually made
| sense, I noticed it took longer to do many basic text editing
| functions than it would with vim bindings. Perhaps others had a
| different experience?
| Casperin wrote:
| I've used Helix since February, and vim for 20 years prior.
|
| For basic edits it's roughly on par now for me (maybe a bit
| slower?); but then Helix has really neat tree-sitter
| integration, so as I'm getting more and more used to that, I
| find myself jumping around code faster and with more precision.
|
| I also never have these moments of fat-fingering a key and then
| have vim go nuts on me. Like I suddenly deleted half the
| function and ended up in some mode I've never heard of while
| doing a recursive recording. ... just mentioning that because I
| believe (but not sure) that it's because of this selection >
| verb scheme that I don't ever see that happening in Helix :)
| jalino23 wrote:
| just started using this today and fell in love and hoping to
| replace my current main editor which is vscode with vim bindings.
|
| I don't wanna spend hours on configs so I really like its
| opinionated defaults
| Casperin wrote:
| I did this in February after 20 years in Vim. Haven't opened
| vim since. Happy coding my friend :)
| ziml77 wrote:
| I went into this expecting it to be another toy editor that
| someone was showing off. But no, this thing is legitimately
| impressive!
|
| I had just been messing around with my neovim config because of
| that Leap plugin that was posted here. I decided to also install
| and configure the Lua language server because I wanted to try
| switching away from Vimscript for my init file.
|
| Since that file was still fresh in my mind, it was the first
| thing I opened after installing Helix, and to my surprise it
| immediately showed me warning markers in the gutter and moving
| the cursor over the underlined symbol showed the langue server's
| complaints. I love that it just worked from having the language
| server installed!
|
| Also while messing with neovim yesterday I was thinking about
| seeing if there was a plugin to show possible operations after
| pressing the leader key, like what you get with Spacemacs. I
| decided to try hitting the spacebar in Helix to see what happened
| and was impressed to see that it popped up with a menu showing
| how I could continue my input.
|
| I'm sure I'll run into annoyances after using it for a while, but
| damn does this project leave an excellent first impression.
| asicsp wrote:
| Previous discussion: "Helix: a post-modern modal text editor"
|
| https://news.ycombinator.com/item?id=27358479 _(657 points | 1
| year ago | 365 comments)_
| sylware wrote:
| does it compile with the rust-written rust compiler?
|
| Do we have elf64 static binaries of this compiler? (with minimal
| usage of syscalls).
| _joel wrote:
| Looks great, I've aliased vim to hx as muscle memory. Will give
| it a test, I'm guilty of having lots of stuff installed on vim I
| don't really know how to use (or even vim's full power)
| buf wrote:
| Does it work with tmux?
|
| I need to run my code in one pane and send commands to a console
| in another pane. I use this feature at least 100 times a day.
|
| edit: it does work with tmux
___________________________________________________________________
(page generated 2022-10-10 23:02 UTC)