Alternative to process-lines for tramp

Alternative to process-lines for tramp

[Ergus]

Hi all

I was checking the counsel-gtags package because it was not working in
Tramp and the issue was basically that the code uses the function
'process-lines' but this function internally uses call-process (instead
of what the name suggests) I was looking for an alternative (like
call-process => process-file) but I couldn't find any.

So the question is if there is a reason for not providing such function;
else if you think that the existing one should be modified or a new one
included just to change the process-file instead of call-process part?

Finally I want to ask about a package adoption process in melpa, because
the original counsel-gtags is abandon (since 2017 and the author doesn't
reply to questions, pull request or issues) and there is a fork from
FelipeLema that wants to substitute it (adopt) but there is not any
answer from Melpa for his pull request since some weeks. So maybe there
is something wrong in the adoption.

Thanks in advance
Ergus

Re: Alternative to process-lines for tramp

[Basil L. Contovounesios]

Ergus <spacibba@aol.com> writes:

> I was checking the counsel-gtags package because it was not working in
> Tramp and the issue was basically that the code uses the function
> 'process-lines' but this function internally uses call-process (instead
> of what the name suggests)

What does the name process-lines suggest?

> I was looking for an alternative (like call-process => process-file)
> but I couldn't find any.

Indeed, I'm not aware of any functions similar to process-lines that
respect file handlers.

> So the question is if there is a reason for not providing such function;
> else if you think that the existing one should be modified or a new one
> included just to change the process-file instead of call-process part?

I don't know whether there's a particular reason for the lack of such a
function; I assume it's just that no-one has worked on it yet.
process-lines is quite restricted in what it can do well, which makes it
an unpopular choice for any sufficiently complex or
performance-sensitive program.  See, for example, bug#1321[1].

I would, nevertheless, welcome a more flexible process-lines, whether
via keyword arguments, a separate function, or otherwise.

> Finally I want to ask about a package adoption process in melpa, because
> the original counsel-gtags is abandon (since 2017 and the author doesn't
> reply to questions, pull request or issues) and there is a fork from
> FelipeLema that wants to substitute it (adopt) but there is not any
> answer from Melpa for his pull request since some weeks. So maybe there
> is something wrong in the adoption.

I'm not an expert on MELPA, but AFAIK it all works by submitting Issues
and Pull Requests via its GitHub site[2].  I see the particular PR
you're referring to[3] was only submitted 8 days ago.  I'd say give
Donald, Steve, and Jonas a little longer to respond, especially since
this involves a change in project ownership, and one of a prominent
Emacs package author at that.  Note also that MELPA isn't an official
ELPA repository, so it doesn't necessarily fall under the jurisdiction
of core Emacs developers.

[1]: https://debbugs.gnu.org/1321
[2]: https://github.com/melpa/melpa/
[3]: https://github.com/melpa/melpa/pull/6093

-- 
Basil

Re: Alternative to process-lines for tramp

[Basil L. Contovounesios]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> I would, nevertheless, welcome a more flexible process-lines, whether
> via keyword arguments, a separate function, or otherwise.

Given that process-lines boils down to a call-process followed by
(split-string (buffer-string) "\n"), one "otherwise" solution would be
to provide a convenience function which does the buffer-splitting (but
in a more efficient way than split-string).

One could then mix and match call-process, process-file, et al. with
this new convenience function.  YMMV.

-- 
Basil