GNU bug report logs -
#79442
RFE: process-lines equivalent for NUL-separated output
Previous Next
Full log
Message #26 received at 79442 <at> debbugs.gnu.org (full text, mbox):
> From: Tim Landscheidt <tim <at> tim-landscheidt.de>
> Cc: 79442 <at> debbugs.gnu.org
> Date: Sun, 14 Sep 2025 11:11:02 +0000
>
> Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> >> > That's not the important part of my question. I'm asking why is there
> >> > a need for a new function whose only job is to call split-string.
>
> >> > process-lines exists because several places in Emacs call it. By
> >> > contrast, there was no reason until now to have a function that deals
> >> > with lines of output separated by nulls. So adding such a function
> >> > would mean we have a function that no one calls, and why would we do
> >> > that, when the way to handle such output in a Lisp program is as
> >> > simple as a single call of an existing function?
>
> >> Well, there are four calls in:
>
> >> | (split-string
> >> | (shell-command-to-string
> >> | (concat "foo "
> >> | (shell-quote-argument "bar baz")))
> >> | "\0"
> >> | t)
>
> >> I want to reduce this to one.
>
> > You could start by writing your own function for that if you use this
> > frequently, no?
>
> Yes.
>
> >> I don't know about the needs of Emacs core, but I use this
> >> pattern regularly to process the output of external programs
> >> where data may include newlines. As Emacs does not provide
> >> a single function for that purpose yet, any user who wants
> >> to process data that may include newlines must use this
> >> pattern as well (or a similar one). Providing a function
> >> that makes it easy to pass data properly encapsulated to an
> >> external program and retrieve its separated output would
> >> make it harder for users to write insecure code.
>
> > I see your point, but I'm not convinced we should add something like
> > that. I welcome other opinions, with rationale.
>
> Then it would be prudent to add the criteria that this
> rationale has to meet to (emacs) Bugs.
If someone can come up with such criteria up front, I'm all ears.
Usually, it's a judgment call of the Emacs maintainers, to be made on
a per-case basis.
> Usually, the first or second adjective in any (self-)description of
> Emacs is "extensible".
Emacs is extensible, but not every possible extension must be in Emacs
OOTB. Many people have quite a lot of local code in their init files
and local packages, without ever submitting that for inclusion in
Emacs, and that is how it should be, IMO. Each one of us has his/her
local needs and requirements which are not necessarily shared by or
important to others. Emacs being extensible by users is important
precisely for this reason.
> If feature requests are ineligible if users can implement them on
> their own, then documenting this could save some time for all
> parties involved.
It goes without saying that not every extension should be part of
Emacs, I'm surprised that this is not self-evident.
This bug report was last modified 4 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.