Replies: 2 comments 15 replies
-
|
https://github.com/helix-editor/helix/blob/master/docs/vision.md Generally, commonly used features are intended to be in core. The features you mentioned also have rationale for not being externalized as a plugin:
Helix isn't trying to replace Kakoune, and follows a different philosophy. I personally feel that Helix is quite maintainable, and a large part of it thanks to using Rust which encourages stricter quality control and adds guardrails against common issues. There's also been a lot of effort in maintaining a good contributor experience to get more eyes on the code. |
Beta Was this translation helpful? Give feedback.
-
Yeah. Instead of baking in certain functionality helix could also document how these usecases could be solved with external tools, and allow for that kind of integration. But I suppose that that too is a bit of a philosophical debate. Do you want to pay the maintenance cost of integrating all these things, or do you want to outsource some of that work to your users, asking that they do a little bit more reading and setup work upfront (which gives them more responsibility, but also more freedom)? Personally I think that for an open source project run by unpaid volunteers it's important to not take on too much. In the beginning there's a lot of velocity, but once that tapers off it can be hard to maintain a project that has taken on a lot of functionality. And yeah, I also feel that for an application that runs in a terminal to integrate a terminal the costs start to outweigh the benefits quite rapidly. Plus, it's a bit of a vicious cycle. Once your project integrates the functionality that say, vscode integrates, you'll probably attract a lot of users that are used to vscode, who will expect things to work like they did in vscode. The suckless philosophy comes to mind: https://suckless.org/philosophy/. I don't completely agree with this, and it's a little cynical, but the point is not without merit. But then again, it's a matter of perspective. I don't think the New Jersey vs. MIT style debate will ever be conclusively solved. The difficult thing is to know where to draw the line. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I agree that it is a matter of perspective. The benefits of a batteries-included approach include: simplified configuration and a consistent workflow across systems (especially on Windows). There are quite a few issues already for the external programs due to user error, such as missing syntax highlighting and clipboard support. On the other hand, the greater surface area may require contributors to make more extensive changes when submitting a PR. Rust can't protect against logic bugs. Ultimately, the line is usually drawn by @archseer. |
Beta Was this translation helpful? Give feedback.
-
|
I think the idea that Helix should integrate something out of the box can be answered with: if we integrate it will it be substantially better than just using an alternative. I agree that treesitter and LSP support are about as mandatory as it comes, no one is going to be better off without that, but an entire terminal emulator inside Helix which is already running in a terminal seems a bit absurd to me. The terminal alternatives are SO much better than having an integrated terminal, use Wezterm or Alacritty or one of the many other good terminal emulators. In wezterm I literally just keep two tabs open and tab back and forth, ctrl-tab and I'm in my actual terminal. And that is the dumb and lazy way to do it, there are much better methods others have mentioned. To me at least, integrating a terminal will always be worse than just using the actual terminal. It's 1 keyboard shortcut away no matter how you shake it, so why bother with the substantial effort of including it in the built-in feature set? To me this is very clearly in plugin territory. |
Beta Was this translation helpful? Give feedback.
-
|
As much of a proponent as I am of integrated, seamless experiences, I have to agree with the above regarding an integrated terminal. Helix is a terminal app. A terminal inside a terminal app doesn’t make sense to me. It’s akin to including an operating system inside of an app. The app runs in the operating system. If you want to use features of the operating system, you use the operating system. |
Beta Was this translation helpful? Give feedback.
-
|
Please channel these thoughts into #1976 where we've already stated most of this. |
Beta Was this translation helpful? Give feedback.
-
|
My 2c as a relative outsider to helix:
Does helix want to be akin to vim/kakoune or VSCode/JetBrains/Emacs? EDIT - submitted too quickly(!) My ideal editor:
I'm genuinely not sure whether my Vim + a few plugins is still the way to go, or maybe kakoune + LSP plugins... (I'm not arguing technology, I'm only arguing "feelings" and perception. I qualified the worth of this as 2cents so .... ;-)) |
Beta Was this translation helpful? Give feedback.
-
|
thanks @zetashift - I agree with everything you say, and I think LSPs being a persistent server that editors connect to (rather than being a process managed and scoped by) would go a long way to resolving this. |
Beta Was this translation helpful? Give feedback.
-
|
@yatesco Another option would be if helix could have a daemon mode: #312. That way if the 'server' instance of helix holds onto the connection with |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure why LSP servers are designed to be persistent. |
Beta Was this translation helpful? Give feedback.
-
|
I only just started trying out Helix, but I do think #312 is important an important thing to do even if one is happy with a single terminal window. |
Beta Was this translation helpful? Give feedback.
-
|
Reviving an old discussion just to add my 2 cent...
But that's exactly how I fell. I loved Helix from the start mainly because of its very good default set of features and the simple config. Neovim with Lazy seemed much too bloated with its multiple Lua config files sourced by its main Now having a deeper look at the upcoming I know a plugin system is wanted by many users and I understand the maintainers can't take every individual concern (like this one) into account; they're already doing a great job. But I hope Helix wont loose its focus on simplicity (very subjective, but let's say in comparison to nvim or Emacs config/package system). As one of those "bash script" guys, I appreciate very much the possibility to have a ready to go in-terminal editor which I can enhance with some scripting stuff, but without running into the rabbit hole of a blown up config file containing thousands of lines and the need to install multiple plugins/packages (whatever you call it, its the same to me) just to set up the editor for some coding/writing... But I guess you maintaing guys have that in mind. Keep up the great work! |
Beta Was this translation helpful? Give feedback.
-
I've been using kakoune for a while, and am considering moving to helix. There are a couple of design decisions that the helix devs have made that make it quite compelling. Overall it feels a bit like helix is to kakoune what neovim is to vim.
I've been following the progress on helix for over a year, and there's one thing that I feel a little apprehensive about when it comes to helix. It seems that the helix team is less worried about adding certain features to the helix core. I think that this is great when it comes to LSP and treesitter support. But there are several features that helix bundles, or that are being considered, that I'm rather skeptical about, specifically: integrated window management, an integrated file tree (file pickers even) and an integrated terminal.
Integrated Terminal#1976I can imagine that people want these features, and if you don't like them you don't have to use them of course. But I do think that for the long term health of the project it's important to consider the added complexity and long term maintenance costs for features like these. One thing that kakoune does very well is bundle only what's necessary and make integration of external tools easy. Comparing the two projects it seems like helix is at least on par in terms of LOC, and actually already larger, when compared to kakoune:
With kakoune adding a fuzzy file picker and file browser has been trivial. Combined with a kitty overlay window it integrates seamlessly. I don't need an integrated terminal because I have my terminal for that. I don't need window management because I have my window manager for that (or could even use kitty splits if I wanted to).
I'm not trying to bash helix. The opposite, I think it's a great project. But I know that it's difficult to draw a line for what features to reject and which to include. I'm a little worried that helix will end up trying to do too much, and that the maintainers will end up spending a lot of effort maintaining features that would be better off being outsourced to external tools, or plugins.
I can imagine that for devs that are coming from neovim, or vscode, that having everything integrated in your editor feels right. And that those things should be added to helix if they're missing. I think though that helix would be better off just focusing on what it does well: editing code/text, and remove everything from the core that could be a plugin or an external tool. Thought it would be good to start a discussion on that topic, as I think it will enhance the long term maintainability of the project.
Beta Was this translation helpful? Give feedback.
All reactions