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 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 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:
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.
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.
35 comments
[ 3.0 ms ] story [ 84.6 ms ] threadAnyway I hope this will be soon included in release! (Even if current <space>+f is also pretty good.)
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.
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.
Except for programs embedded in applications that can already read mail (notably web apps)
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!
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!
It uses a buffer/pop to navigate and edit files like you're inside a buffer
Instead we have something like 3 closed PRs for this.
Happy to try a file explorer once again, it’ll be interesting to see how I feel a year later.
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"
"Assume good faith", "Converse curiously" and "Eschew flamebait" are part of the guidelines for commenting, for good reasons.
On Hacker News, banned accounts can still comment, but those comments are immediately dead until vouched.
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 also ditched tabs and rely on fzf on the buffers.
It’s a really powerful setup and cleans up the UI significantly