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

Previous Next

To reply to this bug, email your comments to 79358 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Liu Hui <liuhui1610 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: etags-regen-mode doesn't work for remote projects
Date: Mon, 1 Sep 2025 18:19:52 +0800

Hi,

The recipe is as follows:

1. create a test project on remote server, and install universal-ctags

2. emacs -Q /ssh:remote:~/test_project

3. (setq etags-regen-program "ctags -e"), then M-x etags-regen-mode

4. open a project file, press M-.

Then emacs displays the buffer *etags-regen-tags-errors*

   ctags: cannot open tag file : No such file or directory

and a message:

   File /ssh:remote:~/test_project/TAGS does not exist

Message #8 received at 79358 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Liu Hui <liuhui1610 <at> gmail.com>
Cc: 79358 <at> debbugs.gnu.org
Subject: Re: bug#79358: etags-regen-mode doesn't work for remote projects
Date: Mon, 01 Sep 2025 12:46:27 +0200

Liu Hui <liuhui1610 <at> gmail.com> writes:

> Hi,

Hi,

> The recipe is as follows:
>
> 1. create a test project on remote server, and install universal-ctags
>
> 2. emacs -Q /ssh:remote:~/test_project
>
> 3. (setq etags-regen-program "ctags -e"), then M-x etags-regen-mode
>
> 4. open a project file, press M-.
>
> Then emacs displays the buffer *etags-regen-tags-errors*
>
>    ctags: cannot open tag file : No such file or directory
>
> and a message:
>
>    File /ssh:remote:~/test_project/TAGS does not exist

I don't use etags, but my bet is that you need to change
etags-regen--choose-tags-file:

--8<---------------cut here---------------start------------->8---
...
(file-local-name (expand-file-name etags-regen-tags-file (project-root proj)))))
--8<---------------cut here---------------end--------------->8---

Best regards, Michael.

Message #11 received at 79358 <at> debbugs.gnu.org (full text, mbox):

From: Liu Hui <liuhui1610 <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 79358 <at> debbugs.gnu.org
Subject: Re: bug#79358: etags-regen-mode doesn't work for remote projects
Date: Tue, 2 Sep 2025 12:57:06 +0800

On Mon, Sep 1, 2025 at 6:46 PM Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Liu Hui <liuhui1610 <at> gmail.com> writes:
>
> > Hi,
>
> Hi,
>
> > The recipe is as follows:
> >
> > 1. create a test project on remote server, and install universal-ctags
> >
> > 2. emacs -Q /ssh:remote:~/test_project
> >
> > 3. (setq etags-regen-program "ctags -e"), then M-x etags-regen-mode
> >
> > 4. open a project file, press M-.
> >
> > Then emacs displays the buffer *etags-regen-tags-errors*
> >
> >    ctags: cannot open tag file : No such file or directory
> >
> > and a message:
> >
> >    File /ssh:remote:~/test_project/TAGS does not exist
>
> I don't use etags, but my bet is that you need to change
> etags-regen--choose-tags-file:
>
> --8<---------------cut here---------------start------------->8---
> ...
> (file-local-name (expand-file-name etags-regen-tags-file (project-root proj)))))
> --8<---------------cut here---------------end--------------->8---

Thanks. The error is same if file-local-name is used.

I find etags-regen--tags-generate uses shell-command-on-region to run
the ctags command, but it seems shell-command-on-region doesn't call
the remote command correctly.

Message #14 received at 79358 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Liu Hui <liuhui1610 <at> gmail.com>
Cc: 79358 <at> debbugs.gnu.org
Subject: Re: bug#79358: etags-regen-mode doesn't work for remote projects
Date: Tue, 02 Sep 2025 09:10:20 +0200

Liu Hui <liuhui1610 <at> gmail.com> writes:

Hi,

> I find etags-regen--tags-generate uses shell-command-on-region to run
> the ctags command, but it seems shell-command-on-region doesn't call
> the remote command correctly.

You are right. shell-command-on-region uses call-process-region, which
isn't aware of remote locations.

I don't know whether we could change this simply. Other uses of
shell-command-on-region, which trust that the command runs locally,
could be broken.

Best regards, Michael.

Message #17 received at 79358 <at> debbugs.gnu.org (full text, mbox):

From: Liu Hui <liuhui1610 <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 79358 <at> debbugs.gnu.org
Subject: Re: bug#79358: etags-regen-mode doesn't work for remote projects
Date: Wed, 3 Sep 2025 18:10:00 +0800

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

On Tue, Sep 2, 2025 at 3:10 PM Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Liu Hui <liuhui1610 <at> gmail.com> writes:
>
> Hi,
>
> > I find etags-regen--tags-generate uses shell-command-on-region to run
> > the ctags command, but it seems shell-command-on-region doesn't call
> > the remote command correctly.
>
> You are right. shell-command-on-region uses call-process-region, which
> isn't aware of remote locations.
>
> I don't know whether we could change this simply. Other uses of
> shell-command-on-region, which trust that the command runs locally,
> could be broken.

Indeed. Maybe the docstring should be updated to clarify that
shell-command-on-region only runs local commands at the moment.

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.

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

Message #20 received at 79358 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Liu Hui <liuhui1610 <at> gmail.com>, Michael Albinus <michael.albinus <at> gmx.de>
Cc: 79358 <at> debbugs.gnu.org
Subject: Re: bug#79358: etags-regen-mode doesn't work for remote projects
Date: Wed, 3 Sep 2025 15:58:51 +0300

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.

Message #23 received at 79358 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Liu Hui <liuhui1610 <at> gmail.com>
Cc: 79358 <at> debbugs.gnu.org
Subject: Re: bug#79358: etags-regen-mode doesn't work for remote projects
Date: Wed, 03 Sep 2025 15:59:40 +0200

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.

> +         (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.

Best regards, Michael.

Message #26 received at 79358 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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)]

Message #29 received at 79358 <at> debbugs.gnu.org (full text, mbox):

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

Liu Hui <liuhui1610 <at> gmail.com> writes:

Hi,

>> 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.

No. make-temp-file generates by default a file relative to
temporary-file-directory. default-directory doesn't matter.

What you want is to use make-nearby-temp-file. process-file understands
remote infile and errfile.

Best regards, Michael.

Previous Next

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