knorrfg/dotree

A small, interactive command runner

dotree's Issues

[Feature request] Default values for vars

It would be nice to have default values that can be overriden if needed.

Here are some syntax/usage suggestions

menu http {
    test: {
        vars route="index", port=8080
        "make a test request" - "curl http://127.0.0.1:$port/$route"
    }
}

And the ui could look something like

value for route ("index"): 
value for port (8080):

Question: Best way to share code between aliases?

Hi,

I think this project idea is brillant, I have many aliases with short names and I sometimes have to look at the shell code to remember the exact letters.

However I have a question, I usually organize aliases/functions with same target domain in dedicated files, and that allows sharing code. For example I have many aliases calling yt-dlp, to download video, stream audio, stream video, search and choose with a fzf menu which video to play, etc. Currently these aliases call private subfunctions, or use variables declared in the same file. This does not seem to be possible with dotree, unless I source a common shell file first for each command declaration, which is not ideal because it duplicates code between 2 different places.

Is there a better way to share code between aliases ?

Thanks

How to have arbitrary number of arguments to a command?

Stupid example to illustrate:

menu root {
    w: cmd {
        vars urls
        "Download URLs" - "wget ${urls}"
    }
}

Now I can download a single URL with dotree w FIRST_URL, more than one by quoting as a single argument dotree w 'FIRST_URL SECOND_URL', but that does not work with the interactive prompt.

Suggestion: file inclusion

I was thinking, as my configuration file is growing, and syntax support for this kind of file isn't great in my editor, that it would be nice to have file inclusion on the menu level. That way, I could develop new submenus independenly, and when finished, include them in the main configuration. Files would remain more managable as well. Lazy evaluation, as only evaluating the included file when it is effectively needed, could also be a consideration.

Just a suggestion, it's already great as it is.

Feature Request/Discussion: More verbose output option(s)

Currently the output from a successful dt invocation is nothing besides whatever is being called. However, I've been finding that I'll run a command with some side effects and then looking back on my shell history/ouput I can't see what's been run already. Re-running a command (non-consecutively) is also not really possible.

A workaround is to run e.g. dt xyz some_arg at the cost of needing to provide everything up front (non-interactive).

At the simplest, I think it would be nice to be able to echo the final invocation after an interactive session:

$ dt
dt xyz some_arg

output of doing z ...

That should usually provide enough context and could also be copy-pasted. Additionally, a quiet/verbosity flag might also be useful in case people are piping output, for instance.

Getting fancier:

• the echo could be previewed as one traverses the tree while typing
• printing the final "name" - "bash command" leaf that's run
• a full-blown @ show/hide token in the config à la just; and maybe toggling that interactively too?
• modifying shell history so re-running is more seamless than copy-pasting from scrollback

I don't mean to introduce bloat (I'd likely turn to an emacs hydra if I needed all that), but I thought I'd include it since it's related and I had some fun brainstorming. The simplest solution alone would make a world of difference!

I haven't touched rust in years, but maybe I'll make an excuse to pick it up again and toy around with some of this. Just wanted to put this all out there for discussion!

Configuration Syntax

First of all, thank you for this great tool!

This is more of a discussion, which, depending on its outcome, may lead to a specific suggestion.

Is the configuration syntax based on some agreed upon standard or is it just hand-crafted for this product?

When I saw it the first time, it reminded me of a JSON extension, like Jsonnet, for example.

Is there a specific reason to use this syntax, besides "simplicity"?

If both questions are answered with "no", I would suggest using something like Jsonnet for the following reasons.

• An uncommon extension of JSON is still a million times more common/accessible/usable, than a unique syntax specifically designed for a single product, which you never see anywhere else.
• There are plenty of Jsonnet language helpers with syntax highlighting etc. for editors like e.g. Visual Studio Code or VSCodium.
• You can leverage all tools Jsonnet already offers by default, like variables, etc., snippet & configuration generation, like e.g. ini files. That means, you wouldn't need to build this from scratch. It's just there.
• Yes, there are maintained Rust libraries already available. This is the recommended one.

From my point of view, switching to Jsonnet would be only an improvement, without worsening the current experience. I guess, the only "increase in complexity" I see, is the addition of a comma after each menu & wrapping all menus inside two absolute braces. Otherwise, everything stays exactly the same, complexity-wise. It would change, but it would not increase complexity.

Config in `$XDG_CONFIG_HOME` not found.

I have a working config $XDG_CONFIG_HOME/dotree.dt, but dt seems to be looking elsewhere.

❯ ls $XDG_CONFIG_HOME/dotree.dt && dt
/Users/cnmne/.config/dotree.dt
Expected config file at /Users/cnmne/Library/Application Support/dotree.dt, but couldn't find it. Please create one.

I also tried using ~/.config/dotree/dotree.dt instead (which I know is not per the docs, but maybe more common elsewhere).

Of course I can successfully use dt --conf-file ~/.config/dotree.dt as a workaround, which I'll be aliasing in the meantime. Alternatively I could make a link to Application Support.

Also thanks for making this tool-- been looking for a just alternative; and a bonus: very hydraesque!

Also... first! 🥇 second? 🥈