Hey! That's a clever idea - and it would probably be very easy to implement, too. I'll put it in TODO, but if you wish, you can always add the feature and merge it yourself - the (Python) codebase shouldn't be very difficult to get acquainted with, and I try to be open to others' changes.
I highly recommend z for switching between frequently used folders. Sure you could set up aliases, but then you need to keep them up to date when your work patterns change.
I don't really understand this. Why use grep? You can just use `find ~/Documents -name somefileiwant -ls`. You can use -regex or -path if you need to use regular expressions to describe a filename or path, respectively.
Alternatively, if you really wanted to use find and grep together, there is no need for any file I/O. You can just use `find ~/Documents -exec ls -l {} + | grep somefileiwant`.
I use grep so I can just come back later and do more grep'ing if needed or even do more complicated grips. ;) Just have to remember to update the filelist.txt file every week or so .. anyway its ghetto and I like it.
Lightning was built because I was tired of both the "cd x; ls; cd x; ls; cd x" and "cd x<tab>x<tab>/xx<tab>x<tab>" patterns and wanted something faster where all I had to do was hit the right keys and I would automagically get to my destination. It's less about finding files than it is about getting to them; in fact, I can imagine myself opening files found with the above method much faster with Lightning than I would using standard shell tools. But that might just be me.
I haven't even seen Helm mode before. I am a hybrid Vim/Emacs user, though, so I am definitely going to try this out and perhaps "borrow" a feature or two.
I don't understand how this helps. From what I've seen, it shows a list of files and directories and you "build" a path by selecting/opening them, navigating using some keys to go up/down in the list.
How is that more efficient than "tabtabbing" (hitting tab two times) to see possible completions? To me it seems less efficient to use up/down than hitting the few necessary keys to get the autocomplete you need.
Well, the idea is that you're supposed to stay in search mode as long as possible, thereby avoiding the need to go into normal mode and select files mc-style. If you do that, then Lightning should be more efficient than tabtabbing because (1) you don't have to press tab to filter files and (2) after you have enough characters to uniquely identify your file/directory, instead of having to press <tab><enter>, you're actually already there.
That said, this is not for everyone; I anticipate it being useful for about 20% of *nix programmers in 90% of their file-opening cases. I just submitted it because (1) I thought that the style of the tool might be interesting to some and (2) that 20% might really enjoy and benefit from having this.
I don't like the selecting up and down, it's much faster to just type a few characters. I wonder if it can use peco to select a directory by fuzzy search.
"Search mode" is the default because, 80% of the time, you're right, it is faster to just type a few characters. However, in about another 10% of cases (in my experience, and up until this point I've been the sole user of this thing), there are filenames that differ by a few characters at the end (lightning-cd.lisp vs lightning-cd.py is a good example), and it would take much longer to type out the entire unique portion of the filename than it would to hit two characters, switch modes, and then select downward once or twice.
I am considering adding in a fuzzy searching engine. However, because Lightning's primary mode (search mode) works by selecting on uniquely identifying substrings of filenames (the ones at the beginning in particular), a fuzzy search might make it more difficult to get a particular file because the algorithm would grab other filenames that you didn't want. I'll give it a try and see how it works.
I think I'd much rather use something like Midnight Commander. You can move using arrow keys (right arrow to cd to a dir, left to cd back, up and down to select file/dir), as well as use the traditional 'cd' command, as well as move through history using M-y and M-u, as well as incremental search, as well as using bookmarks/directory hotlist.
Plus, you don't have to clutter your bash history with loads of 'i' commands (I know about HISTCONTROL=ignorespace and HISTIGNORE, but still).
28 comments
[ 3.1 ms ] story [ 70.4 ms ] threadDoes Midnight Commander? It's one of the features I have been missing on Linux.
https://github.com/rupa/z
Alternatively, if you really wanted to use find and grep together, there is no need for any file I/O. You can just use `find ~/Documents -exec ls -l {} + | grep somefileiwant`.
Lightning was built because I was tired of both the "cd x; ls; cd x; ls; cd x" and "cd x<tab>x<tab>/xx<tab>x<tab>" patterns and wanted something faster where all I had to do was hit the right keys and I would automagically get to my destination. It's less about finding files than it is about getting to them; in fact, I can imagine myself opening files found with the above method much faster with Lightning than I would using standard shell tools. But that might just be me.
How is that more efficient than "tabtabbing" (hitting tab two times) to see possible completions? To me it seems less efficient to use up/down than hitting the few necessary keys to get the autocomplete you need.
That said, this is not for everyone; I anticipate it being useful for about 20% of *nix programmers in 90% of their file-opening cases. I just submitted it because (1) I thought that the style of the tool might be interesting to some and (2) that 20% might really enjoy and benefit from having this.
I am considering adding in a fuzzy searching engine. However, because Lightning's primary mode (search mode) works by selecting on uniquely identifying substrings of filenames (the ones at the beginning in particular), a fuzzy search might make it more difficult to get a particular file because the algorithm would grab other filenames that you didn't want. I'll give it a try and see how it works.
The good thing about fuzzy search is that "ligy" would match "lightning-cd.py", and "ligs" would match "lightning-cd.lisp".
Plus, you don't have to clutter your bash history with loads of 'i' commands (I know about HISTCONTROL=ignorespace and HISTIGNORE, but still).