[Feature request] Plugin system (custom_commands) and custom search command

[Dzordzu]

Hi it would be nice to be able to execute custom search command. For example currently it's not possible to have rg + fzf search. Ideally it may look like

keymap.toml

[default_view]

keymap = [
  { keys = ["x"], command = "custom_serach_interactive rg -n -H --color=never '%text' %s|  fzf --ansi --preview 'bat -n $(echo {} | cut -d \":\"-f1)' | cut -d ':' -f1" },
  { keys = ["X"], command = "custom_search rg -l %text | tail -n 1  },
]

First one should allow to open interactive window (in this example fzf) the second just go to the output file

[Dzordzu]

Started working on implementation on this. Well it's a little more complicated. We may want to specify a new config handling user defined commands. I suggest creating new key in the joshuto.toml named custom_commands. It may look like this

joshuto.toml

custom_commands = [
   { name = "rgfzf", command = "rg -n -H --color=never '%text' %s|  fzf --ansi --preview 'bat -n $(echo {} | cut -d \":\"-f1)' | cut -d ':' -f1" }
]

keymap.toml

[default_view]

keymap = [
  { keys = ["X"], command = ":custom_search rgfzf "  },
]

As one can see that method is basically drastically simple plugin system using shell commands

[superiums]

i thinks this may be restructed more flexable:

custom actions is not the point, the point was communication between commands and joshuto.

1. there are 3 ways of shell command:

   • background shell command, which NOT live joshuto, display at the bottom.. (like :shell tar -xzf aaa.tgz does)
   • inline shell command, which do NOT live joshotu, display at the bottom and pie result back to joshotu. (like / search cmd does)
   • interactive shell command, which live joshotu and pipe result back to joshotu. (like search_fzf does.)

2. we analyze these needs, the custom search command was the 3rd kind. so we could make:

   • two types of UI, inline and interactive one.
   • two types of result pipe: pipe back and not.

in this way, not only custom search could be done well, but also other custom actions should be work very well.

by the way, we may consider another powerful thing:

• pipe out : pipe out the selection or current dir/file to the command. (seems this has been done by %s, but maybe more)

sth more:

• cusor position in shell: just like ! and @ do in ranger.
• result wait: just like shell -w do in ranger.

[Dzordzu]

I like the idea. Maybe I'll be able to prepare a simple diagram with this concept. Unfortunately, current design of the joshuto (AFAIK) is not as flexible. Most joshuto commands are mostly hardcoded, without generalization to the interactive and non-interactive commands. It would require some major changes in the codebase

[superiums]

I like the idea. Maybe I'll be able to prepare a simple diagram with this concept. Unfortunately, current design of the joshuto (AFAIK) is not as flexible. Most joshuto commands are mostly hardcoded, without generalization to the interactive and non-interactive commands. It would require some major changes in the codebase

good ! good structure makes good software.

[DLFW]

Most joshuto commands are mostly hardcoded, without generalization to the interactive and non-interactive commands. It would require some major changes in the codebase

True. BTW: The lack of a common, abstract interface of commands is also a blocker for a good auto-completion. You can never know what switches and arguments a command expects/accepts. I would appreciate some refactoring here. :wink: .

[superiums]

Most joshuto commands are mostly hardcoded, without generalization to the interactive and non-interactive commands. It would require some major changes in the codebase

True. BTW: The lack of a common, abstract interface of commands is also a blocker for a good auto-completion. You can never know what switches and arguments a command expects/accepts. I would appreciate some refactoring here. 😉 .

this interface mainly for user shell commands, not internal one. all shell commands such as fzf , z, zi, rg, tar goes after :shell. so there's no infuent to auto-completion.

where dose it go? just 4 ways:

1. no result need to handle. such as : fast_cp, this should go throgh :shell
2. result need to wait user have a glance, just like :shell -w do in ranger.
3. result need to pipe back to joshuto , a path / file need to be cd to , or select. or muti files/folders need to be show. this should go through :shell -p
4. no result need to be deel with, but only reload the current dir. like :shell -r tar ......

[Dzordzu]

@superiums I don't want to be unkind, but this is not a place for this discussion. The number of notifications and messages to process begins to be overwhelming. Note that I'm an author of the single PR and this issue.

In case of ideas such these, please either open a new issue with your feature request, or start a discussion. You can always reference this issue and/or any PR from there. I generally like the concept, but please take a note that everything takes time. Some of these ideas would need vast amount of work - both conceptual and with physical implementation. My PR is meant to be a quick patch with acceptable code quality without tremendous amount of effort.

[Dzordzu]

@kamiyaa merged PR with custom_commands. Further discussion should be continued in the separate issue