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

Progress/status indicator #16

Closed
walseb opened this issue May 4, 2023 · 3 comments
Closed

Progress/status indicator #16

walseb opened this issue May 4, 2023 · 3 comments

Comments

@walseb
Copy link

walseb commented May 4, 2023

When the API returns long replies, there can be long periods of waiting where I don't know whether its taking so long because my internet went down, or because the reply is really long.

It would be useful if there were some progress or status indicator to each job displayed in the mode line.

@tyler-dodge
Copy link
Owner

The latest version has org-assistant-mode which is a minor mode that changes the mode line to including a queue that shows the individual requests.
It shows the first four letters of the UUID of each request in the [].

Below is the part of the mode-line-format I mentioned:

    (:eval (concat "[" (s-join "," (--map (substring it 0 4) org-assistant--inflight-request)) "]") )

Closing since I think this is already complete

@walseb
Copy link
Author

walseb commented May 5, 2023

Yes although the mode line only displays what jobs are currently running. It would be more useful to know exactly what stage they are in. E.g. connecting to API, waiting for reply, etc.

I'd imagine the mode line would then say something like [foo123(C)] for connecting, for instance.

It's less of an issue once the streaming branch is merged, but it could still be useful in case you have a slow internet connection/DNS issues.

But I'm quite unfamiliar with the interface for making web requests, do you have access to any of that information when making a request?

@tyler-dodge
Copy link
Owner

Yeah, it'd be possible now with the streaming API / it does give some feedback that correlates with the states of the request like once the src block shows up, the server is necessarily connected

More work could be done via adding verbose flags to curl, and parsing the output. For the moment, I only intend to do the streaming implementation, since I think that gives it significantly more feedback than it had before.

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

No branches or pull requests

2 participants