Subject: Re: bug#76103: [PATCH] New function 'process-output'

From: Alvaro Ramirez <[email-masked]>
Date: Fri, 07 Feb 2025 09:17:34 +0000

Hi Eli,

Thanks for the questions and feedback.

Eli Zaretskii <[email-masked]> writes:

>> From: Álvaro Ramírez <[email-masked]>
>> Date: Thu, 06 Feb 2025 19:06:25 +0000
>>
>> I find process-lines super convenient for glueing command line
>> utilities.
>>
>> Often wished I had a similar function that neither split into
>> lines (process-lines) nor relied on shell
>> (shell-command-to-string).
>>
>> Proposing process-output as a close cousin to process-lines.
>
> Thanks, but can you explain why shell-command-to-string is not 
> what
> you want?

1. Performance: Shell overhead isn't needed to get a process 
output.

(benchmark-run 1000
    (process-output "seq" "200")) => (1.239617 0 0.0)

(benchmark-run 1000
    (shell-command-to-string "seq 200")) => (4.049149999999999 0 
    0.0)

2. Convenience API: The existing process-lines API is simple and 
easy to reach out to when glueing command line utilities.

Would be handy to have the same convenience available via 
process-output.

  - Predictably and concisely named: easy to find, starts with 
  "process-".
  - Structure + versatility: IMO while list of args is partially 
  structured, it remains fairly versatile (benefits from other 
  list-operating functions) vs unstructured string.
  - Avoids all issues with unescaped params (compared to 
  shell-command-to-string).

> And in any case, given that the implementation is basically 4 
> lines of

Users would need to either re-implement this for each package they 
build or duplicate the 4 lines every time they want a short-lived 
process output.

> Lisp, why do we need this in Emacs,

Seems like a good core basic function to offer (same reasons as 
above) which package authors can rely on without duplicating 
across every packages.

>  and in subr.el on top of that

subr.el was chosen since that's where the existing process-lines 
lives. Happy to move to a more appropriate location. Suggestions?

> (which means it will be preloaded)?  Sounds like not justified 
> for
> such a simple function.  If some package needs it, and cannot 
> use
> shell-command-to-string (for reasons I still don't understand),
> it can easily implement it as a utility function, no?

I hope the above rationale helps. While in its entirety, it could 
be open to opinion, perhaps we can justify purely on performance 
alone?

> Stefan and Andrea, WDYT?