[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Alternative to process-lines for tramp
From: |
Basil L. Contovounesios |
Subject: |
Re: Alternative to process-lines for tramp |
Date: |
Thu, 04 Apr 2019 03:54:47 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Ergus <address@hidden> 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