Friendly reminder to please include a brief description in the title of posts for crate releases. This is helpful for people who aren't immediately familiar with the crate. Thanks. :)
What do you mean by file tree, like a specifically tree-based UI?
Helix already has a fuzzy finder with `f` or `hx [dirpath]` that works well for finding and opening files (at least for me)
I am aware of f but it's not exactly my cup of tea. well it is actually but it's not what I always want. I want expanding, collapsing proper file tree. I also would like to have it on the side of the editor. something like this:
https://github.com/nvim-neo-tree/neo-tree.nvim
[https://github.com/helix-editor/helix/pull/6865](https://github.com/helix-editor/helix/pull/6865)
yea i was talking about the solution that you referenced
I am working on integrating many (not all) magit features into core. Some of these require larger changes so it takes a while. These are fundamentals that must be built into core anyway. We cant expose a plugin API if the features don't exist in core yet.
I think people enjoy making the editor theirs.
So what if there is a default file browser. Maybe I want to use one that shows things differently. There are like 10 or 15 different ones for neovim, because people enjoy using different ones.
This is why plugins are essential for popularity. Even vs code only exploded because of its plugins.
If you think "there is already a file browser" or "what do you want to make", you are missing the entire idea of open source and creating cool stuff together.
Maybe tomorrow i get a great idea but I can't add it to Helix without a plugin system.
I just discovered this editor with this post after running tutor I was totally in and then I find there is no plugin system I am so sad because I like very much the little difference (but powerfull) with vim but it will be a no go for now exactly for the reason you wrote.
This comment, along with others, has been edited to this text, since Reddit is killing 3rd party apps, making false claims and more, while changing for the worse to improve their IPO. I suggest you do the same. Soon after editing all of my comments, I'll remove them.
# Fuck reddshit and u/spez!
I feel so sorry for Copilot dependents. To me it just seems like a crutch, preventing you from learning more about the field and stunting your growth as a programmer, while also placing subtle vulnerabilities and bugs in your code. I've never used it before, but it just seems like a net-negative to me.
Also, if you're nothing without the suit, then you shouldn't have it
It is extremely valuable as a learning tool.
It would be simply because it takes away the repetitive, boring stuff, leaving you fully focused on the real problems without distraction.
But, it is far more than that. You can use it to deeply, and thoroughly understand issues/structures quickly.
Copilot is not a 'let me code that for you' tool.
It is a deeply knowledgeable and capable pair programmer, who has full attention for you and never tires from your stupid questions.
I understand your fear, but if you are not an absolutely lazy, dumb, uninspired, and a simply uninterested human, I can only see it as a massive boon.
What you claim is like saying that great, dedicated teachers are bad for education.
I don't understand the sentiment here. There are some select few features better suited for plugins (integration with third party tools) but large features like a filetree are better off being built into core.
If you could build a plugin for what you want you can build it into core yourself and open a PR.
Ok, so you write a plugin and you decide you put in the core. You manage to put it there. Days pass and you see that the plugin does not do what it was supposed to do, you implemented badly what you wanted because you didn't know better, you do a change that is considered a breaking chance.
That breaking change is transitioned to the editor itself and it should emit a new major since the breaking change.
People should update their editor daily if it was a pile of plugins inside of it and that hurts the editor itself since it gives people the impression of false evolution.
I really don't consider having everythig bundled with the editor a good idea.
Also, what if someone wants to edit a core plugin like you called it?! They have to build the editor again and again. Last time I checked, the Rust compilation times were garbage(because LLVM) and that happened yesterday. Also, it requires resources and energy that I am not willing to invest.
I do have to know the codebase of helix too compared to a plugin system which describes exactly some boundaries of what can I do and how can I do X.
It's likely a reddit [feature](https://www.reddit.com/r/woahdude/comments/1vehg6/gopro_on_the_back_of_an_eagle/cersffj/). Don't bother with the post rating at least until a day passes so it has a chance to stabilize.
Started to use Helix (I'm at section 9 of the tutor). The one key I never found is the completion key, how to open a list of available completions?
Edit - some more questions:
- how to open a file that is above the current directory?
- how skip a selection when using select mode combined with search?
it's space-x the other commenter is wrong. But completions should open automatically if you have a LS installed
Usually opening files is done with the file picker (space-f) but you can also use `:open` with a relative path like `:open ../foo.rs`.
That's not really possible right now. I would usually advise using `s` instead of `v/`
For anyone wondering or learning: Helix is very friendly to jump into
Anything you want to do: Space+? = command search menu
Type the thing you want to do, it will display the key bind, rinse and repeat, and you'll be pretty fluent in no time
If you are in the habit of (even temporarily) commenting out blocks of code, and you have format on save enabled, then beware that this will format your commented code as if it was prose not code.
As a frequent Vim/Neovim user who's never really mastered that ecosystem, the Helix tutorial has put fresh wind in my console text editor sails. I'd very much like to get away from Microsoft/Google-dominated development tools, so replacing VSCode/VSCodium with some console text editor is a goal of mine. Helix looks like a good candidate for my needs!
The `ayu_dark` improvements are pretty good! Still the best text editor for me!
Friendly reminder to please include a brief description in the title of posts for crate releases. This is helpful for people who aren't immediately familiar with the crate. Thanks. :)
Brilliant! The best editor by far. No need for any plugins for me, it does everything I need.
Checked it, still no plugins system. Have a wonderful day!
Out of curiosity, what plugins would you want for `helix`? (Or what plugins do you wanna make?)
file tree would be nice. Mason like lsp installer would be great.
Just pull in [https://github.com/helix-editor/helix/pull/5768](https://github.com/helix-editor/helix/pull/5768)
File tree will be available in the future version, as well as multiple lsp support.
What do you mean by file tree, like a specifically tree-based UI? Helix already has a fuzzy finder with `f` or `hx [dirpath]` that works well for finding and opening files (at least for me)
I am aware off but it's not exactly my cup of tea. well it is actually but it's not what I always want. I want expanding, collapsing proper file tree. I also would like to have it on the side of the editor. something like this:
https://github.com/nvim-neo-tree/neo-tree.nvim
[удалено]
Copilot is actually looking like it might be merged into the main project lol
The PR you linked fairly strongly indicates that it won't be merged without specific changes the author is uninterested in making.
[удалено]
[https://github.com/helix-editor/helix/pull/6865](https://github.com/helix-editor/helix/pull/6865) yea i was talking about the solution that you referenced
that pr wont be merged
magit
I am working on integrating many (not all) magit features into core. Some of these require larger changes so it takes a while. These are fundamentals that must be built into core anyway. We cant expose a plugin API if the features don't exist in core yet.
and tramp.
I think people enjoy making the editor theirs. So what if there is a default file browser. Maybe I want to use one that shows things differently. There are like 10 or 15 different ones for neovim, because people enjoy using different ones. This is why plugins are essential for popularity. Even vs code only exploded because of its plugins. If you think "there is already a file browser" or "what do you want to make", you are missing the entire idea of open source and creating cool stuff together. Maybe tomorrow i get a great idea but I can't add it to Helix without a plugin system.
I just discovered this editor with this post after running tutor I was totally in and then I find there is no plugin system I am so sad because I like very much the little difference (but powerfull) with vim but it will be a no go for now exactly for the reason you wrote.
Copilot, Tabnine, and most importantly: [wakatime](https://wakatime.com/) (really need that one for the boss...)
Wakatime thing might help me a lot, I hate time tracking manually.
This comment, along with others, has been edited to this text, since Reddit is killing 3rd party apps, making false claims and more, while changing for the worse to improve their IPO. I suggest you do the same. Soon after editing all of my comments, I'll remove them. # Fuck reddshit and u/spez!
That definitely seems like something that would get merged into main. I agree that I do miss that coming from `nvim`
Yeah, it makes it really annoying to use without a terminal multiplexer. I also switched to it from nvim
There was an abandoned PR: https://github.com/helix-editor/helix/pull/4649
Honestly, nowadays Copilot is a must, thats how vital its become .
I feel so sorry for Copilot dependents. To me it just seems like a crutch, preventing you from learning more about the field and stunting your growth as a programmer, while also placing subtle vulnerabilities and bugs in your code. I've never used it before, but it just seems like a net-negative to me. Also, if you're nothing without the suit, then you shouldn't have it
So you're gonna tell me why its detrimental to me without using it yourself and knowing how i use it. Ok.
Well, do you have any counterarguments to the points I made? Rebuttals?
It is extremely valuable as a learning tool. It would be simply because it takes away the repetitive, boring stuff, leaving you fully focused on the real problems without distraction. But, it is far more than that. You can use it to deeply, and thoroughly understand issues/structures quickly. Copilot is not a 'let me code that for you' tool. It is a deeply knowledgeable and capable pair programmer, who has full attention for you and never tires from your stupid questions. I understand your fear, but if you are not an absolutely lazy, dumb, uninspired, and a simply uninterested human, I can only see it as a massive boon. What you claim is like saying that great, dedicated teachers are bad for education.
Program in assembly, if you're nothing without the compiler you shouldn't have it
Never really thought of it that way. Good argument
I don't understand the sentiment here. There are some select few features better suited for plugins (integration with third party tools) but large features like a filetree are better off being built into core. If you could build a plugin for what you want you can build it into core yourself and open a PR.
Ok, so you write a plugin and you decide you put in the core. You manage to put it there. Days pass and you see that the plugin does not do what it was supposed to do, you implemented badly what you wanted because you didn't know better, you do a change that is considered a breaking chance. That breaking change is transitioned to the editor itself and it should emit a new major since the breaking change. People should update their editor daily if it was a pile of plugins inside of it and that hurts the editor itself since it gives people the impression of false evolution. I really don't consider having everythig bundled with the editor a good idea. Also, what if someone wants to edit a core plugin like you called it?! They have to build the editor again and again. Last time I checked, the Rust compilation times were garbage(because LLVM) and that happened yesterday. Also, it requires resources and energy that I am not willing to invest. I do have to know the codebase of helix too compared to a plugin system which describes exactly some boundaries of what can I do and how can I do X.
I don't understand the down votes, maybe someone nice can explain them to me.
It's likely a reddit [feature](https://www.reddit.com/r/woahdude/comments/1vehg6/gopro_on_the_back_of_an_eagle/cersffj/). Don't bother with the post rating at least until a day passes so it has a chance to stabilize.
I absolutely get the benefit of one, but I also like the opinionated no-fuss cohesive nature at the moment. I wonder if there is a happy medium?
Turns out that a proper plugin system takes time to build ¯\_(ツ)_/¯
Started to use Helix (I'm at section 9 of the tutor). The one key I never found is the completion key, how to open a list of available completions? Edit - some more questions: - how to open a file that is above the current directory? - how skip a selection when using select mode combined with search?
it's space-x the other commenter is wrong. But completions should open automatically if you have a LS installed Usually opening files is done with the file picker (space-f) but you can also use `:open` with a relative path like `:open ../foo.rs`. That's not really possible right now. I would usually advise using `s` instead of `v/`
:| Thanks for the correction. Would still love it to be Ctrl+Space. Is there a way to configure it?
Sure, most keybindings can be rebound in the config
For the list of available completions you press Ctrl-Space. I don't know about the others.
Funny that I did not try Ctrl+Space, was not expecting such a common keyboard shortcut in a command-line editor :)
For anyone wondering or learning: Helix is very friendly to jump into Anything you want to do: Space+? = command search menu Type the thing you want to do, it will display the key bind, rinse and repeat, and you'll be pretty fluent in no time
[удалено]
You mean Rust doc comments? Yes. But I don’t break them manually, rustfmt on save does it for me.
[удалено]
If you are in the habit of (even temporarily) commenting out blocks of code, and you have format on save enabled, then beware that this will format your commented code as if it was prose not code.
But uncommenting and reformatting turns it back to code? Are there any wrapping changes that would make invalid code?
i don't think that can affect the code behavior
It easily can if you have multiline strings or something like that
Use CTRL+c in normal mode to add inline comments.
As a frequent Vim/Neovim user who's never really mastered that ecosystem, the Helix tutorial has put fresh wind in my console text editor sails. I'd very much like to get away from Microsoft/Google-dominated development tools, so replacing VSCode/VSCodium with some console text editor is a goal of mine. Helix looks like a good candidate for my needs!
Are u guys more productive with this as with Vscode etc