GNU bug report logs - #67687
Feature request: automatic tags management

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 67687 <at> debbugs.gnu.org, eskinjp <at> gmail.com, michael.albinus <at> gmx.de, stefankangas <at> gmail.com
Subject: bug#67687: Feature request: automatic tags management
Date: Mon, 1 Jan 2024 19:23:28 +0200

On 01/01/2024 18:50, Eli Zaretskii wrote:
>> Date: Mon, 1 Jan 2024 17:47:09 +0200
>> Cc: stefankangas <at> gmail.com, eskinjp <at> gmail.com, 67687 <at> debbugs.gnu.org,
>>   michael.albinus <at> gmx.de
>> From: Dmitry Gutov <dmitry <at> gutov.dev>
>>
>>> I guess for now it will be enough to document that invoking
>>> visit-tags-table disables the mode for that project.  AFAICT this is
>>> not currently documented anywhere in the patch.
>>
>> OK, added a paragraph to the mode's docstring.
>> [...]
>> +
>> +The exception is made when the user has already selected a tags
>> +table manually (for example, using \\[visit-tags-table]).  Then
>> +this mode doesn't do anything.  Reset the visited tags tables
>> +using \\[tags-reset-tags-tables]."
> 
> The above is only true for the project whose TAGS was manually
> visited, right?  IOW, it's not that once the use invokes
> visit-tags-table once, this mode will be effectively disabled for the
> entire session, right?

No, it's the latter. It's off for the whole session, just like a visited 
TAGS file is active for the whole session (not limited to any specific 
project).

The current choice is optimized for making it possible to flip 
etags-regen-mode on globally while not interrupting the workflows of 
most (hopefully all) people who currently use etags.

> If so, I suggest to make it clear:
> 
>    If you select a tags table manually (for example, using
>    \\[visit-tags-table]), then this mode will be effectively disabled
>    for the project or the directory tree from which the tags table was
>    visited (the mode will still auto-regenerate tags tables for other
>    projects and directory trees).  Use \\[tags-reset-tags-tables] to
>    countermand the effect of a previous \\[visit-tags-table].
> 
> Otherwise, this LGTM, thanks.

We could do something like this too, but a tags file, in general, can't 
always be attributed to a specific project. At least we won't always be 
able to do that correctly for custom-made tag files. For example, the 
user could have that file include another tags file from a different 
directory on the same level, just like we here do with directories 'src' 
and 'lisp'. If 'src' and 'lisp' were configured to be separate projects, 
a visited src/TAGS would be attributed to the 'src' project only, while 
in fact it covers both. So the simplest solution is not to try.

Previous Next

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