Re: Alternative to process-lines for tramp

["Basil L. Contovounesios" <contovob@tcd.ie>]

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