Commands that are both groups and have multi-mode cannot be listed #657
Comments
|
I've been thinking about this for a while and I am not so sure there's a non-confusing way of implementing this. Actually, in my mind, the issue comes from the multi-purpose How would I do it?
Now, the problematic
The issue of using For listing all the "base-commands" use Confusing, and still not so happy about the |
|
Your solution addresses indeed the problem of having Maybe to avoid changing "drastically" the syntax we could have:
This has the advantage of remaining "in line" with the existing syntax at the cost of having to do |
|
@caribpa BTW if you want we have a Mattermost server where we discuss this and other stuff. https://rizin.re/community/ There's a special channel for "newshell" development to discuss in real time some random ideas/issues. |
Yeah, I realized later, I thought of two solutions for this:
By the way, I suggested
I agree it is not fun to change the syntax, though Rizin is still not considered "stable" (until 1.0.0 release version), so I think that now is the time to "experiment" with breaking-changes (and revert them if the feedback/usability gets bad). IMO there could be a separate branch for these kind of experiments for the brave 😉 What you propose could also work, by the way, with the exception of the |
Ignore the
I think we don't want to list recursively sub-commands and show long descriptions at the same time. Consider that long descriptions might contain multi-paragraph descriptions, examples, use-cases and what not. It could easily become a mess to read. What we mean by "recursively list sub-commands" is exactly what you get now with |
At this point, I think we don't have that many people testing the |
Well, I use the built-in grep ( |
I use the |
Thanks, I'll pass by later 👍 At the same time, have you considered moving (some of the conversations/ideas/FAQ requests) to the repo's discussions page? I'm suggesting this with the idea of increasing the visibility and possible engagement of the discussions as not everybody has a Mattermost account (and may not be interested in creating one just to check what the conversations there are about) 🙂 |
Awesome! ;)
Honestly, I haven't, but if you want to try using it, I'd be happy to move discussions there when it make sense. |
I realized this is not alright, because
So using One solution could be to just consider sub-modes as some additional detail of a single command, so they would not be listed anymore as special sub-commands, but just as a single command. In particular, the sub-modes of
|
|
So: Right? So it is basically the same it is now but |
|
Why not making |
That's right.
This is a good point... One might say that sometimes you just want to know the arguments you have to pass to a command and you don't want your whole screen to be cleared by a lot of help text... |
|
Well, you could still do: |
|
Honestly, I also get mildly annoyed by the pollution caused by the output of This "smart-pager" gets opened in another buffer, like the HUD input mode ( Example: And I said "smart-pager" because it behaves like in of these two when filtering it:
|
|
Sure thing, this change comes with an |
This could have the disadvantage of not being able to see the command syntax while typing it. Sometimes you do However I do see value in both cases. |
|
What could be done (in a really far future) is to make an interactive help-buffer with a cursor that pastes in the prompt the selected command, and allows traversing in the sub-command/group in tree-like fashion. For example: $ rizin --
> z?
*a help-buffer opens only showing the following*
Usage: z[?] # Zignatures management
> | z[j*qk] # Show zignatures
| z.[*] # Find matching zignatures
| zb[r] # Search for best match
| z- <zigname|*> # Delete zignature
| za[fF] # Add zignature
| zg # Generate zignatures (alias for zaF)
| zo[sz] # Manage zignature files
| zf<ds> # Manage FLIRT signatures
| z/[*f] # Search zignatures
| zc[n] # Compare zignatures in current zignspace with another one
| zs[j*-+r] # Manage zignspaces
| zi[j*qi] # Show zignatures matching information
*Note that the > denotes the cursor position*
Usage: z[?] # Zignatures management
| z[j*qk] # Show zignatures
| z.[*] # Find matching zignatures
| zb[r] # Search for best match
| z- <zigname|*> # Delete zignature
> | za[fF] # Add zignature
| zg # Generate zignatures (alias for zaF)
| zo[sz] # Manage zignature files
| zf<ds> # Manage FLIRT signatures
| z/[*f] # Search zignatures
| zc[n] # Compare zignatures in current zignspace with another one
| zs[j*-+r] # Manage zignspaces
| zi[j*qi] # Show zignatures matching info
*Presses TAB to show the sub-commands*
Usage: z[?] # Zignatures management
| z[j*qk] # Show zignatures
| z.[*] # Find matching zignatures
| zb[r] # Search for best match
| z- <zigname|*> # Delete zignature
> \ za[fF] # Add zignature
| za <zigname> <type> <param0> [<param1> ...] # Add zignature
| zaf [<fcnname> [<zigname>]] # Create zignature for function
- zaF # Generate zignatures for all functions
| zg # Generate zignatures (alias for zaF)
| zo[sz] # Manage zignature files
| zf<ds> # Manage FLIRT signatures
| z/[*f] # Search zignatures
| zc[n] # Compare zignatures in current zignspace with another one
| zs[j*-+r] # Manage zignspaces
| zi[j*qi] # Show zignatures matching info
*Also allowing to move the cursor to the sub-commands*
Usage: z[?] # Zignatures management
| z[j*qk] # Show zignatures
| z.[*] # Find matching zignatures
| zb[r] # Search for best match
| z- <zigname|*> # Delete zignature
\ za[fF] # Add zignature
| za <zigname> <type> <param0> [<param1> ...] # Add zignature
> | zaf [<fcnname> [<zigname>]] # Create zignature for function
- zaF # Generate zignatures for all functions
| zg # Generate zignatures (alias for zaF)
| zo[sz] # Manage zignature files
| zf<ds> # Manage FLIRT signatures
| z/[*f] # Search zignatures
| zc[n] # Compare zignatures in current zignspace with another one
| zs[j*-+r] # Manage zignspaces
| zi[j*qi] # Show zignatures matching info
*Pressing Enter closes the help-buffer and pastes the selected command into the prompt*
$ rizin --
> z?
> zaf |
|
Well, or it could end overriding the current $ rizin --
> zafinstead of: $ rizin --
> z?
> zaf |
|
that feature is cool, but i do not think is needed right now. i think is better to just use |
I'm more than ok with this. makes more sense. |
|
I don't think I will be able to do this for 0.3.0. Going to move it to 0.4.0. |
|
it is fine. so many things to be done and not much time to work on them |
Work environment
rizin -vfull output, not truncated (mandatory)Expected behavior
There should be a way to list the sub-modes of all commands, even the ones that are already the parent of a group, like
z. Initially we were just appending?, but that means that to get the longer help of a command you may have a lot of?(e.g.z?gives the list of sub-commands ofz,z??gives the list of sub-modes of the commandz,z???gives the short description of the commandz with standard output,z????gives the longer description of the commandz with standard output... It seems a bit too confusing).Ideas?
Steps to reproduce the behavior
Additional context
By "sub-command" of
zI mean commands likezi,zc,zg,zb, etc.By "sub-mode" of
zI mean all those things that behave exactly the same aszbut provide an output in a different format, likezj,z*,zq, etc. These things actually are commands to the user, but they are handled by the same command handler and provide the same information just in different formats.The text was updated successfully, but these errors were encountered: