idursun
Run aliases from ui
Seems like it would be nice to be able to run entries from the [aliases] section of the configuration. For example:
[aliases]
bm = ["bookmark", "set", "main", "--revision=@"]
sync = [
"util",
"exec",
"--",
"bash",
"-c",
'jj git fetch && jj rebase -d "trunk()"',
]
These are of course operations that can be done in the ui already, but to be able to run any of the aliases seems like it would be nice.
Perhaps custom commands is what you're looking for?
https://github.com/idursun/jjui/wiki/Custom-Commands
Not quite, though that may be sufficient. However, it requires writing the command again as a specific component of the jjui configuration. What I'm proposing is that a single key opens a menu from which the user can select from already existing aliases in jj configuration.
Ah ok, those details were not in the original post.
Yes, I am averse to having to define things in both jj and jjui config. Your proposal seems reasonable.
You can exec : sync.
If you need a key-binding, you can assign it a leader key if needed:
# jjui config.toml
[leader.S]
send = [":sync", "enter"]
That is helpful @vic, but I still think there is an improvement to be made by allowing the execution of aliases already existing in jj config by way of providing a menu selection. If I find time this weekend, I may try to implement it. But still thank you for the helpful information.
by providing a menu selection you mean something like the UI for custom commands ? perhaps aliases being auto loaded as custom commands ?
I have aliases that expect parameters (like expecting the revision to work on) so I'm not sure I'd like all aliases be automatically callable from jjui becase not all of them are ready for execution. I do use leader keys that leave the exec prompt ready for me to just complete the revision that my alias command needs.
I'm not sure if all aliases can be considered as runnable as they might be expecting more arguments.
That is an interesting point. Nevertheless, yes that is the idea. Some command that pops a menu where the selections are jj's configured aliases. And since we have access to the configuration, I don't see why it couldn't further prompt for those arguments, or at least only load aliases that don't have positional arguments expected.
Yes, we can extract the configutation using jj config list aliases that's why I was thinking of auto-loading aliases as custom-commands (not to add another way to add user defined commands to the UI) , but how would you determine which of these aliases are not expecting additional arguments (they can be anything user defined). it would be simpler to just load them all.
If jjui loaded your aliases as custom-commands at startup, it would be like you had this config:
[custom_commands]
"bm" = { args = ["bm"] }
"sync" = { args = ["sync"] }
for this to be possible you just need the alias names: jj config list aliases -T "name ++ \"\n\""
EDIT: I used the following to add all my aliases as custom commands: (now documented at our wiki)
echo "[custom_commands]" >> $JJUI_CONFIG_DIR/config.toml
jj config list aliases -T '"\"" ++ name ++ "\" = { args = [ \"" ++ name ++ "\" ] }\n"' --no-pager |\
sed -e 's/aliases.//g' |\
tee -a $JJUI_CONFIG_DIR/config.toml
and they are shown on the x custom-commands menu.
Hey, thanks for the suggestion.
I believe the current functionality covers the use of aliases. If you want to assign a key to your alias then it should go into custom commands (it's what it is implemented for).
If you don't need a key for your alias then you can simply do :bm.
Showing aliases in the custom commands, or in its own menu doesn't make invoking them convenient (as it requires opening the menu and then selecting the item), but also creates confusion as now there are three ways to achieve the same thing.
I don't follow. Typically one of the intents of a tui is to make underlying inputs discoverable. Using :bm doesn't accomplish that goal. To that end, this menu does, and without requiring duplication in a new configuration.
I don't follow. Typically, one of the intents of a tui is to make underlying inputs discoverable.
No worries. My previous answer was about using the aliases. If we are trying to tackle the discoverability problem, then I'd argue that it should be done in the same way as revset-aliases is done. Revset editor shows the revset-aliases as completion items when in edit mode.
Using :bm doesn't accomplish that goal. To that end, this menu does, and without requiring duplication in a new configuration.
You're right, a menu solves the discoverability problem. In this specific example, it can be solved in a different way which is also consistent with the rest of the app.
If the user sees revset-aliases loading up in the revset editor, then they can automatically assume the same will happen in the jj exec editor but with the aliases. jj exec doesn't do that at the moment, but mostly because it is a very new feature. I'd welcome a PR that's implementing that.
Just as an example, I implemented rebase operation as annotations around the jj log, because that's where the action is happening. Similarly, one can assume the same thing will happen with jj squash and jj duplicate.
P.S. Even though I mentioned my take on the design guidelines and principles in various places before, I haven't added a CONTRIBUTING file to the project yet. I will work on it to make things a little bit more clear.