GNU bug report logs - #76103
[PATCH] New function 'process-output'

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alvaro Ramirez <alvaro <at> xenodium.com>
Cc: acorallo <at> gnu.org, 76103 <at> debbugs.gnu.org, stefankangas <at> gmail.com, juri <at> linkov.net
Subject: bug#76103: [PATCH] New function 'process-output'
Date: Fri, 07 Feb 2025 13:42:55 +0200

> From: Alvaro Ramirez <alvaro <at> xenodium.com>
> Cc: Stefan Kangas <stefankangas <at> gmail.com>,  Andrea Corallo
>  <acorallo <at> gnu.org>,  76103 <at> debbugs.gnu.org, juri <at> linkov.net
> Date: Fri, 07 Feb 2025 09:17:34 +0000
> 
> Hi Eli,
> 
> Thanks for the questions and feedback.

Thanks for answering them.

> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Álvaro Ramírez <alvaro <at> xenodium.com>
> >> 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?

I'm not sure a 2.5 boost in performance (on which platform, btw?)
justifies yet another API.  We need to think about the downsides of
enlarging Emacs: the need to document each new API, the need to
maintain it, the need to somehow explain which one of the alternatives
to use in each case, etc.

But let's see what other maintainers think.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.