Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add capture and stdout commands #495

Merged
merged 1 commit into from
Mar 10, 2024
Merged

Add capture and stdout commands #495

merged 1 commit into from
Mar 10, 2024

Conversation

DLFW
Copy link
Contributor

@DLFW DLFW commented Feb 15, 2024

This adds two new commands as a base to enable users to use the output of scripts to do certain actions in Joshuto.

The first command this adds is a third command to start a sub-process beside shell and spawn, called capture. Like shell, capture is running blocking but unlike shell, it does not release the terminal but captures the stdout of the sub-process and stores it in an AppContext attribute.

The second command added by this commit is stdout. This command takes the output from the last capture run, stored in the AppContext attribute, and uses it for some action. The action has to be specified as a sub-command. As of now, only stdout cd is implemented. This checks that the last output of capture is a single line of an existing file or directory and then changes the working directory to that.

To get significant value from these new commands, capture needs to be equipped with more variables to feed more information about Joshuto's state into external scripts, and stdout needs to get some more sub-commands.

@DLFW
Copy link
Contributor Author

DLFW commented Feb 15, 2024

This is a first step for #456. Reasons why have chosen this solution are outlines in my comment there.

As mentioned in the commit message, this is currently not sufficient to solve the original requirement, but I thought this is a good first commit, also to have some agreement that this concept is a feasible way to go. I will provide ~two follow-up commits to get some of the other missing pieces and I will also provide some documentation then.

To test the single working “stdout-command”, one can add something like

  { keys = ["e", "t"], commands = ["capture joshtest.sh", "stdout cd"] },

into keymap.toml, a script joshtest.sh like

#!/usr/bin/env bash
echo $(cat /home/dude/test-bookmarks | dmenu)

somewhere in the path, and a list of directories in /home/dude/test-bookmarks like

/home/dude/Downloads
~/music
~/sandbox/joshuto

Then, e-t will open a dmenu where one can choose a directory from the list, and Joshuto will jump to there.

It's just a first, simple example for these two new commands.

@DLFW DLFW force-pushed the shell-result branch 2 times, most recently from a30dcde to 51dbc23 Compare February 20, 2024 22:45
@DLFW
Copy link
Contributor Author

DLFW commented Feb 20, 2024

Just did a rebase and fmt

@kamiyaa
Copy link
Owner

kamiyaa commented Feb 21, 2024

Thanks! Might take a while for me go through the PR

This adds two new commands as a base to enable users to use the output
of scripts to do certain actions in Joshuto.

The first command this adds is a third command to start a sub-process
beside `shell` and `spawn`, called `capture`. Like `shell`, `capture` is
running blocking but unlike `shell`, it does not release the terminal
but captures the `stdout` of the sub-process and stores it in an
`AppContext` attribute.

The second command added by this commit is `stdout`. This command takes
the output from the last `capture` run, stored in the `AppContext`
attribute, and uses it for some action. The action has to be specified
as a sub-command. As of now, only `stdout cd` is implemented. This
checks that the last output of `capture` is a single line of an existing
file or directory and then changes the working directory to that.

To get significant value from these new commands, `capture` needs to be
equipped with more variables to feed more information about Joshuto's
state into external scripts, and `stdout` needs to get some more
sub-commands.
@DLFW
Copy link
Contributor Author

DLFW commented Mar 2, 2024

Just rebased and resolved conflicts

@kamiyaa
Copy link
Owner

kamiyaa commented Mar 10, 2024

Interesting design.
It seems a little messy to have these commands do all this, but I can't think of a better solution at the moment and I'm curious to see where this goes.

@kamiyaa kamiyaa merged commit 2de86e3 into kamiyaa:main Mar 10, 2024
4 checks passed
@DLFW
Copy link
Contributor Author

DLFW commented Mar 10, 2024

Interesting design. It seems a little messy to have these commands do all this, but I can't think of a better solution at the moment and I'm curious to see where this goes.

“A little messy” is a good description. 😇 In the end, I saw only two alternatives: Complete refactoring of the “command processing” in Joshuto and introducing something like clap to have a real command/option/argument parser (which would have enabled me to implement my initial idea), or introducing something like a socket from where Joshuto can read commands (in parallel to stdout) to allow “remote controlling” of Joshuto. That could have also been used by shell-commands to issue certain reaction. Both these alternatives were too much effort/risky for me right now.

Thanks for merging!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants