joshuto

joshuto copied to clipboard

I'm coming here from lf which I like a lot (because it's ultra fast to start and walk through dirs /even network ones/ and supports easy extensibility with shell scripting).

Though there are some long-standing (multiple years) issues with lf I'd like to have fixed because they're pretty much show stoppers for much of the work I do with file managers. Coincidentally they seem to apply to joshuto as well - and if joshuto fixes them, then you have one more user (and occasional contributor especially of configuration/extension scripts :wink:).

1. https://github.com/gokcehan/lf/issues/267
2. https://github.com/gokcehan/lf/issues/47
3. https://github.com/gokcehan/lf/issues/46
4. https://github.com/gokcehan/lf/issues/80
5. https://github.com/gokcehan/lf/issues/109

Other things which joshuto does differently and I'd like it to be configurable/different:

1. https://github.com/gokcehan/lf/issues/50
2. https://github.com/gokcehan/lf/issues/51
3. https://github.com/gokcehan/lf/issues/61
4. https://github.com/gokcehan/lf/issues/69

Hey @dumblob , thanks for the issue. A lot of the features you're requesting seems quite complex in nature so it may take a while to get to all of them (if at all).

For now, I would just like to address a few.

• https://github.com/gokcehan/lf/issues/109: I believe this is already the current nature of Joshuto. Where on reload, if the index is greater than the length of the new list of items, it will revert to the last element. If its less than, it will try to find that item. If it doesn't find it, it will set itself as the previous index. Unfortunately, as its currently implemented, it would be inefficient to try and search for its (possibly non-existent) neighbors. https://github.com/kamiyaa/joshuto/blob/a98af4f70d1b58ae7b2ece410c22d247240a2b1e/src/fs/dirlist.rs#L67-L84

• https://github.com/gokcehan/lf/issues/50: There is a command in Joshuto that lets you copy the full name of the current file. It is possible to also add a command to copy the entire path into clipboard. As for the path compression, I will need to do more research on that to figure out how to support it. https://github.com/kamiyaa/joshuto/blob/a98af4f70d1b58ae7b2ece410c22d247240a2b1e/src/commands/file_ops.rs#L50 https://github.com/kamiyaa/joshuto/blob/a98af4f70d1b58ae7b2ece410c22d247240a2b1e/src/commands/key_command.rs#L83

• https://github.com/gokcehan/lf/issues/61: In older versions of joshuto, I made used of https://github.com/webdesus/fs_extra to provide progress bars. However, this was really slow (for move and copy) because it basically had to read the data into joshuto and write it to the destination. But filesystems like btrfs implements things like copy-on-write, which this doesn't work well with. The workaround is to use move/copy from rust std. This however does not provide a progress bar. The best progression you can get is X/Y files have been successfully moved/copied. The UI for this is currently not very nice (I will polish it more as I have more time), but you can see a progress view by pressing 'w'.

• https://github.com/gokcehan/lf/issues/69: It's currently case insensitive. However, I can add wildcard support and the option to toggle case sensitive search.

• Marking files is something I have partially implemented in joshuto. Will need to do a lot of plumbing to get it working. Some other things I had in mind was also adding support for wildcards when doing select.

Thanks @kamiyaa for looking at the referenced issues.

• https://github.com/gokcehan/lf/issues/109 : does your code account also for the situation when there is only 2 or 1 item in the list and this item gets deleted? Will it jump to index -1 then?
• https://github.com/gokcehan/lf/issues/50 : with that I meant show the file (or dir) being currently selected with its full path in the UI (i.e. not just dirname but really full path, possibly shortened by compression if it won't fit)
• gokcehan/lf#61 : progress bars or alike (e.g. an autoupdated percent number) are really necessary even for one file (it's actually a common case for me to copy things among machines and it takes tenths of seconds or minutes) - without that user doesn't know that something happens which is very frustrating
• gokcehan/lf#69 : maybe an "ultra smart seach" could work too (i.e. when there is at least one unescaped wildcard character in the search string, consider it a wildcard search, but if it yields too few results - configurable number try to fill results up to - or if there is no wildcard character then search as if it was an exact case-sensitive substring search and if even than there is too few results - still smaller than the configurable number - then try to search with fuzzy search which will consider all characters separately as they all must appear somewhere in the record and in the order given in the search string

Marking files is something I have partially implemented in joshuto. Will need to do a lot of plumbing to get it working.

This is absolutely necessary to work with multiple files and across sessions/runs_of_joshuto.

Some other things I had in mind was also adding support for wildcards when doing select.

That's also sometimes useful. But can be often substituted by interactive search (i.e. filtering the result after each pressed character when switched in that inter. search mode).

* [gokcehan/lf#109](https://github.com/gokcehan/lf/issues/109) : does your code account also for the situation when there is only 2 or 1 item in the list and this item gets deleted? Will it jump to index `-1` then?

It will jump to the end or beginning of the list

* [gokcehan/lf#69](https://github.com/gokcehan/lf/issues/69) : maybe an "ultra smart seach" could work too (i.e. when there is at least one unescaped wildcard character in the search string, consider it a wildcard search, but if it yields too few results - configurable number _try to fill results up to_ - or if there is no wildcard character then search as if it was an exact case-**sensitive** substring search and if even than there is too few results - still smaller than the configurable number - then try to search with fuzzy search which will consider all characters separately as they **all** must appear somewhere in the record **and** in the order given in the search string

I've just added wildcard support via search_glob. For future stuff, I'm thinking of adding fzf support either directly or implementing a plugin system (via lua or something)

Marking files is something I have partially implemented in joshuto. Will need to do a lot of plumbing to get it working.

This is absolutely necessary to work with multiple files and across sessions/runs_of_joshuto.

Some other things I had in mind was also adding support for wildcards when doing select.

That's also sometimes useful. But can be often substituted by interactive search (i.e. filtering the result after each pressed character when switched in that inter. search mode).

Well, I added wildcard for now xd

I think I'm misunderstanding something about this. I recall in ranger, you can select files (they turn yellow and bold) and you can mark them (red star beside it). Which one are you referring to?

I saw the mention of FZF and you may want to use skim as an alternative, it's really performant and has about 95% of the same functionality and even the same flags and such.

I've just added wildcard support via search_glob.

Will take a look.

For future stuff, I'm thinking of adding fzf support either directly or implementing a plugin system (via lua or something)

Plugins sound good. I'm though rather a fan of "one config file shall be enough" :wink:. And admittedly "plugins" sound like overengineering (and lots of work for you as a developer and maintainer in the future). Maybe it's enough for now to nicely interface with command line - I find the syntax & semantics lf has quite balanced (lf gives up on providing any computational language like Lua, but provides hell lot of triggers/hooks/... and ways to create your own - all that to call your script which turns out to be fine in practice despite the expected latency of execution). Feel free to take a look at my config: https://pastebin.com/VrvaEGXA (notice the amount of shell code and the prefixes ${{ !{{ &{{ etc. (see https://github.com/gokcehan/lf/blob/202a99873173b1e78351eeee02c1aae7685863c4/lf.1#L907 ).

Well, I added wildcard for now xd

I think I'm misunderstanding something about this. I recall in ranger, you can select files (they turn yellow and bold) and you can mark them (red star beside it). Which one are you referring to?

I dislike any diversification of "marking/selecting/..." - so for me both are the same thing as you can see from the esc key mapping in my config above :wink: (I never really understood why Ranger/lf/... distinguish them).

I was merely referring to select by manually picking files (I do it with the space bar key - analogous to selection by mouse clicking in GUI file managers) versus selection by "list & filter & select_all_results" command (usually "list & filter" is combined to "find" or alike - probably what you refer to as the new wildcards support) which can be either "batch"-wise (e.g. execute :find *abc??* from the built-in command line) or interactive (e.g. switch to interactive select mode by pressing / and then every key stroke will reevaluate "unselect_everything & list & filter & select_all_results" chain and then turn off interactive mode by pressing e.g. esc).

@JacobTravers hm, it seems to me that skim doesn't support "smart search" (i.e. the "chain of fallbacks" as I outlined above) which forces one to learn and remember to always put the right character in front of the string which is tedious. Or maybe I misread the documentation?

So i looked into it more and it turns out skim is not as efficient as i thought, and the maintainer hasn't touched the project in months... it still seems to be a better match for this project since it's directly integrated with the library. However it may also be worth considering having fzf as an optional dependency/replacement for users more focused on performance.