Call to `curl --version` on every shell-maker-submit call can adversely impact user experience

[carlosdagos]

G'day :)

I noticed that shell-maker-submit uses shell-maker--clear-input-for-execution which then calls shell-maker--curl-version-supported, which runs curl --version.

For some reason my (homebrew installed) curl takes a loooong time to execute.

Check out this disaster

NOTE: Intentional omissions with [...]. The first call is homebrew `curl` and the second is macOS-default `curl`.

$ time curl --version
curl 8.19.0 (aarch64-apple-darwin25.3.0) [...]
________________________________________________________
Executed in    5.06 secs      fish           external
   usr time   31.36 millis    0.70 millis   30.66 millis
   sys time   23.92 millis    2.88 millis   21.04 millis

$ time /usr/bin/curl --version
curl 8.7.1 (x86_64-apple-darwin25.0) [...]

________________________________________________________
Executed in   35.60 millis    fish           external
   usr time    8.04 millis    0.58 millis    7.46 millis
   sys time   11.87 millis    2.63 millis    9.25 millis

While issues with my installation of curl are not necessarily a concern for shell-maker, the matter of fact is that we're doing IO with every shell-maker-submit and if this IO takes slightly longer than expected ¹ then the user experience is degraded because doing a sync call like that on every submit blocks emacs entirely for the amount of time the IO takes.

I'm wondering if there's something we can do about this. Perhaps we can cache the result of curl --version on shell-maker startup? Or on the first shell-maker-submit for a specific buffer?

Happy to hear your thoughts :)

Thank you so much!

Footnotes

1. This can happen for a number of reasons, like different types of antivirus solutions installed in target machines. ↩

[xenodium]

Ah interesting. I'm also using homebrew but it doesn't look like I've installed curl from there. I'm using the system's 8.7.1.

the matter of fact is that we're doing IO with every shell-maker-submit

Hear ya, though realistically this delay is typically negligible and in return I'm able to simplify checking logic.

I'm wondering if there's something we can do about this. Perhaps we can cache the result of curl --version on shell-maker startup? Or on the first shell-maker-submit for a specific buffer?

If possible, I'd prefer we don't add caching for this sort of thing as it's going to get more complex and yield another set of bugs raised by users. Let's see if we can either resolve or mitigate the issue for you...

$ time curl --version

Did you run this from inside Emacs itself (eshell?) or a terminal? Trying to establish how PATH is resolved.

What's in your Emacs's exec-path variable? I wonder if searching through PATH to find is what's taking long in your system?

Try (setq shell-maker-curl-executable "/absolute/path/to/homebrew/curl")).

Also worth trying (setq shell-maker-curl-executable "/usr/bin/curl"))

[carlosdagos]

Thanks @xenodium. I should've noted that I had already done what you suggested and set shell-maker-curl-executable to /usr/bin/curl and that fixed my immediate issue.

This issue was to ask about your appetite to make changes to the current logic. I can see tradeoffs in adding changes. For what it's worth I did try adding a lil caching layer using a buffer-local variable and the changes aren't huge but I also couldn't up front tell you if that will yield more issues from users or not.

I could open a PR and give you a chance to think about that one if you'd like :)

Thank you again for your response!

[xenodium]

Gut feeling is that we'd be applying a fix to mitigate an issue that should be fixed elsewhere but sure, happy to look at the PR if it doesn't give you much work.

[sabahmax-inc]

Hi! Thanks for the report. I’ve opened PR #45 to address this by caching the curl --version check instead of running it on every shell-maker-submit call, so Emacs won’t block on that IO each time.