I used to believe that a File explorer is crucial in my text editor; after using Helix for more than a year, I’ve discovered that is not required at all; space+f much faster use flow. I work with split terminal windows, where I have supporting windows to navigate the file system.
Happy to try a file explorer once again, it’ll be interesting to see how I feel a year later.
> I’ve discovered that is not required at all; space+f much faster use flow.
Some use "fuzzy find" on the filename, which is ultra fast too.
I use something even faster IMO: typically I know at least some of the text of the source / test code file I want to go to. So I either use a function of the editor that can "find usage" or... I simply use ripgrep, integrated in my editor, and start typing text I know is in the file I want to visit.
I still use, sometimes, a "file explorer" to find the file to open but it's not the most common.
In a way using a file explorer is "sort": things are arranged in folders/directories. Fuzzy search or finding usages or ripgrep is "search". So, basically:
A file explore is great only for browsing (to get a sense of the project) and managing files (moving renaming, especially in batch). Actually opening file is better with a finder (either filename or content) and a fuzzy filter. I use emacs and consult is a great package for that (the native features mostly present a buffer with the result). A step up from VSC is acting over a result buffer and have the changes reflected back to the normal buffer. Like renaming functions when LSP can’t help you.
Lots of completely harmless comments are dead, the few that are not were vouched for by someone (like myself if we're talking about this thread specifically). I don't really care either way, but the guy should be aware that he's writing into /dev/null
For me, space+f is a "fuzzy search", a filter to find by filename. You can omit some characters, e.g. `pack/back/conf` would show `packages/backend/config.z`.
I have muscle memory now, so I'd have to open the editor to confirm it. There is also another mode, that works a bit like grep I think? I haven't used it but seems that you can look for matches in file content.
I like the idea of doing browsing in folders containing files as navigating between edit buffers.
I've been editing like that since the 1990s because that's how Emacs and XEmacs do it (M-x dired command). The ease and speed of just pressing RETURN on the .. menu to go up or on the folder name to open and look inside is unrivalled and much faster than using my mouse (and better for health - avoids RSI).
Would be cool for Helix to get Emacs-like directories-as-edit-buffers functionality!
It is the best explorer for me too. It blends into the rest of the vim so much so that you don't feel the difference between manipulating text and files.
I've been using vim/neovim for decades, and "so that you don't feel the difference between manipulating text and files" made no sense.
Then I watched a video from the README (https://github.com/stevearc/oil.nvim) and yup, that looks amazing and makes so much sense. Thanks GP for mentioning it!
What I really want to see merged is the tokens in shell commands. dotnet is my day job, and the boilerplate (its luckily just namespace nowadays) gets repetitive and typo-prone. If I could just (approximately) `dotnet new class -o $cwd`...
Instead we have something like 3 closed PRs for this.
I get that Helix is really fast (I also use it sometimes) but some of those screen-grabs could be made bit slower so one could see what is actually happening.
Anyway I hope this will be soon included in release! (Even if current <space>+f is also pretty good.)
I agree. Capturing the interaction as a movie (like .mov file) makes it really difficult to understand what the user is doing. e.g. What keystrokes did the user press to finish this interaction. I wish folks would post screen grabs with tools like https://asciinema.org/ - this is what the helix-editor homepage uses to show the features. This is ideal for terminal apps.
That said, I wish asciinema can also show the key strokes a an annotation with the ability for the viewer to pause on each keyboard interaction.
I used to believe that a File explorer is crucial in my text editor; after using Helix for more than a year, I’ve discovered that is not required at all; space+f much faster use flow. I work with split terminal windows, where I have supporting windows to navigate the file system.
Happy to try a file explorer once again, it’ll be interesting to see how I feel a year later.
I ditched file explorer in neovim and just use fzf.
I also ditched tabs and rely on fzf on the buffers.
It’s a really powerful setup and cleans up the UI significantly
> I’ve discovered that is not required at all; space+f much faster use flow.
Some use "fuzzy find" on the filename, which is ultra fast too.
I use something even faster IMO: typically I know at least some of the text of the source / test code file I want to go to. So I either use a function of the editor that can "find usage" or... I simply use ripgrep, integrated in my editor, and start typing text I know is in the file I want to visit.
I still use, sometimes, a "file explorer" to find the file to open but it's not the most common.
In a way using a file explorer is "sort": things are arranged in folders/directories. Fuzzy search or finding usages or ripgrep is "search". So, basically:
"search, don't sort"
A file explore is great only for browsing (to get a sense of the project) and managing files (moving renaming, especially in batch). Actually opening file is better with a finder (either filename or content) and a fuzzy filter. I use emacs and consult is a great package for that (the native features mostly present a buffer with the result). A step up from VSC is acting over a result buffer and have the changes reflected back to the normal buffer. Like renaming functions when LSP can’t help you.
You're shadowbanned, mate, almost all your comments from at least the last couple of weeks are dead.
Probably not the best venue, but if you read through the comments, kind of makes sense.
"Assume good faith", "Converse curiously" and "Eschew flamebait" are part of the guidelines for commenting, for good reasons.
I don't think they're shadowbanned, just a lot of the comments have been banned the old-fashioned way.
I’m not seeing it? They don’t appear to be shadowbanned from my account.
Lots of completely harmless comments are dead, the few that are not were vouched for by someone (like myself if we're talking about this thread specifically). I don't really care either way, but the guy should be aware that he's writing into /dev/null
dang seems to have outright banned him just over a fortnight ago. https://news.ycombinator.com/item?id=42653007
On Hacker News, banned accounts can still comment, but those comments are immediately dead until vouched.
Isn't space+f fuzzy find?
For me, space+f is a "fuzzy search", a filter to find by filename. You can omit some characters, e.g. `pack/back/conf` would show `packages/backend/config.z`.
I have muscle memory now, so I'd have to open the editor to confirm it. There is also another mode, that works a bit like grep I think? I haven't used it but seems that you can look for matches in file content.
I like the idea of doing browsing in folders containing files as navigating between edit buffers.
I've been editing like that since the 1990s because that's how Emacs and XEmacs do it (M-x dired command). The ease and speed of just pressing RETURN on the .. menu to go up or on the folder name to open and look inside is unrivalled and much faster than using my mouse (and better for health - avoids RSI).
Would be cool for Helix to get Emacs-like directories-as-edit-buffers functionality!
Oil for nvim is THE best explorer i have used. Highly recommend
For people to understand your enthusiasm I feel like you should try to explain why :
It uses a buffer/pop to navigate and edit files like you're inside a buffer
It is the best explorer for me too. It blends into the rest of the vim so much so that you don't feel the difference between manipulating text and files.
I've been using vim/neovim for decades, and "so that you don't feel the difference between manipulating text and files" made no sense.
Then I watched a video from the README (https://github.com/stevearc/oil.nvim) and yup, that looks amazing and makes so much sense. Thanks GP for mentioning it!
yazi for me!
I recently tried yazi after trying a few other cli file explorers and after I settle my current dot file redo I’m gonna dig into it some more
I was waiting for this to try switching… and now I’ve discovered oil.nvim and can never go back.
What I really want to see merged is the tokens in shell commands. dotnet is my day job, and the boilerplate (its luckily just namespace nowadays) gets repetitive and typo-prone. If I could just (approximately) `dotnet new class -o $cwd`...
Instead we have something like 3 closed PRs for this.
https://github.com/helix-editor/helix/pull/12527
Can't you just:
PWD is does hot refer to the directory that file I am working on is in.
One of the long-awaited features was recently merged!
I get that Helix is really fast (I also use it sometimes) but some of those screen-grabs could be made bit slower so one could see what is actually happening.
Anyway I hope this will be soon included in release! (Even if current <space>+f is also pretty good.)
I agree. Capturing the interaction as a movie (like .mov file) makes it really difficult to understand what the user is doing. e.g. What keystrokes did the user press to finish this interaction. I wish folks would post screen grabs with tools like https://asciinema.org/ - this is what the helix-editor homepage uses to show the features. This is ideal for terminal apps.
That said, I wish asciinema can also show the key strokes a an annotation with the ability for the viewer to pause on each keyboard interaction.
These are HTML <video> controls. You can right-click and set a speed.
... but can it read emails?
Jamie Zawinski's Law: Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
They’re working on a scheme-based plugin system, so… almost!
And a corollary to this law:
Except for programs embedded in applications that can already read mail (notably web apps)
Great news! When I'm familiar with the project space+F works great, but isn't great for discovery.
Yay!!! Been waiting!!!
Nvm this has been around for a while. Still a simple file explorer would be nice for when you want to browse the structure.