GNU bug report logs - #79358
etags-regen-mode doesn't work for remote projects

Previous Next

Full log

View this message in rfc822 format

From: Liu Hui <liuhui1610 <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Michael Albinus <michael.albinus <at> gmx.de>, 79358 <at> debbugs.gnu.org
Subject: bug#79358: etags-regen-mode doesn't work for remote projects
Date: Fri, 5 Sep 2025 22:07:48 +0800

[Message part 1 (text/plain, inline)]

On Wed, Sep 3, 2025 at 8:58 PM Dmitry Gutov <dmitry <at> gutov.dev> wrote:
>
> Hi!
>
> On 03/09/2025 13:10, Liu Hui wrote:
> > So I changed shell-command-on-region/shell-command to
> > process-file-shell-command in the attached patch, which should make
> > etags-regen-mode work for both local and remote projects.
>
> Thanks for the patch, it's a good improvement.
>
> Specifically for call-process-region, could you try branching like the
> workaround helper xref--process-file-region? Maybe it could be copied
> verbatim even.
>
> Perhaps you could also try the puzzle described in the comment there? IF
> that observation still applies.

OK. I have added etags-regen--process-file-region in the patch. I
don't find there is a significant speed difference. Perhaps most time
is spent generating TAGS.

I changed the absolute file name to relative file name when generating
TAGS file if possible, because etags.el can handle relative file name
in both local and remote cases. etags.el uses expand-file-name for the
file name in TAGS file, and expand-file-name doesn't add remote part
for absolute file names.

Therefore, if the etags-regen-mode creates TAGS file outside of the
remote project root, etags.el cannot find remote files. Since the
problem lies in etags.el, it can be fixed separately.


Michael Albinus <michael.albinus <at> gmx.de> writes:

> Liu Hui <liuhui1610 <at> gmail.com> writes:
>
> Hi,
>
> As said I don't use etags.el (and I haven't installed a tags program),
> but comment from cursory reading:
>
>> -                          (shell-quote-argument tags-file))))
>> +                          (shell-quote-argument (if remote
>> +                                                    (file-local-name tags-file)
>> +                                                  tags-file))))
>
> file-local-name returns always a proper result, for both remote and
> local files. So don't check with file-remote-p.

Done, thanks for pointing it out.

>> +         (tempfile (make-temp-file "etags-regen"))
>> +         (error-file (make-temp-file "etags-regen-err")))
>>      (with-temp-buffer
>>        (mapc (lambda (f)
>> -              (insert f "\n"))
>> +              (insert (if remote (file-local-name f) f) "\n"))
>>              files)
>> -      (shell-command-on-region (point-min) (point-max) command
>> -                               nil nil etags-regen--errors-buffer-name t))
>> +      (write-region nil nil tempfile))
>> +    (process-file-shell-command command tempfile (list nil error-file))
>
> tmpfile and error-file are local files, because created with
> make-temp-file. Why do you call process-file-shell-command then?
> call-process-shell-command would do the job.

When default-directory is remote, tmpfile contains file names on the
remote host, and process-file-shell-command can run etags remotely
with tmpfile as the input.

[0001-Fix-etags-regen-mode-for-remote-projects-bug-79358.patch (text/x-patch, attachment)]

Previous Next

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