unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Dmitry Gutov <dmitry@gutov.dev>
Cc: 67687@debbugs.gnu.org, eskinjp@gmail.com, michael.albinus@gmx.de,
	stefankangas@gmail.com
Subject: bug#67687: Feature request: automatic tags management
Date: Mon, 01 Jan 2024 14:07:20 +0200	[thread overview]
Message-ID: <83ttnx1clj.fsf@gnu.org> (raw)
In-Reply-To: <801f2f8a-a39b-493f-a24f-0613a3c7ca57@gutov.dev> (message from Dmitry Gutov on Mon, 1 Jan 2024 03:23:36 +0200)

> Date: Mon, 1 Jan 2024 03:23:36 +0200
> Cc: stefankangas@gmail.com, eskinjp@gmail.com, 67687@debbugs.gnu.org,
>  michael.albinus@gmx.de
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >> a) We won't add new files to the index, because we (apparently) can't
> >> simply use the project's list of files -- there is no guarantee that it
> >> matches the fileset that the original author of the TAGS file had in mind.
> > 
> > The user has etags-regen-ignores to control that.
> 
> etags-regen-ignores wouldn't normally include filters that already are 
> in project's ignores. But of course the user might choose to add them.
> 
> >> b) There is no way to pick up the --regex options used for generating
> >> the original TAGS, or any other options we don't know about.
> > 
> > There are defcustoms to control both of those.
> 
> If all of these options are set to the expected values, what's stopping 
> the user from calling 'M-x tags-reset-tags-tables' and having 
> etags-regen-mode create the table on its own? The extra 10 seconds of 
> waiting?
> 
> Also note that if you have an existing TAGS file in the root of the 
> project, with default configuration etags-regen-mode will pick it up to 
> visit and refresh it where necessary (when there are changed or missing 
> files).
> 
> >> Either way, we get a poorly-defined behavior with edge cases that are
> >> likely to surprise the user at different points of time. So we might
> >> indeed grow such a capability, but it'll probably stay off by default.
> > 
> > I agree that sometimes it could be against the user's expectations.
> > But I also think that other times it is according to user's
> > expectations.  Which tells me that this is a separate issue that needs
> > a separate knob; we shouldn't deterministically deduce what users want
> > in this respect from the fact that he/she loaded an existing tags
> > table.  Moreover, it is quite possible that even when the mode is
> > turned on, users might want sometimes to load tags tables manually.
> 
> I don't mind adding additional knobs.

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.





  reply	other threads:[~2024-01-01 12:07 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-07 11:43 bug#67687: Feature request: automatic tags management Jon Eskin
2023-12-07 15:57 ` Dmitry Gutov
2023-12-07 19:57   ` Jon Eskin
2023-12-10  2:41     ` Dmitry Gutov
2023-12-10 11:38       ` Jon Eskin
2023-12-20 21:11         ` Jon Eskin
2023-12-21  0:24           ` Dmitry Gutov
2023-12-21  7:40             ` Eli Zaretskii
2023-12-21 16:46               ` Dmitry Gutov
2023-12-21 23:37                 ` Dmitry Gutov
2023-12-24  1:43                   ` Dmitry Gutov
2023-12-28  9:30                     ` Eli Zaretskii
2023-12-30  3:05                       ` Dmitry Gutov
2023-12-30  7:33                         ` Eli Zaretskii
2023-12-30 23:43                           ` Dmitry Gutov
2023-12-31  1:02                             ` Stefan Kangas
2023-12-31 23:29                               ` Dmitry Gutov
2024-01-02  0:40                                 ` Stefan Kangas
2024-01-02  1:31                                   ` Dmitry Gutov
2023-12-31  7:07                             ` Eli Zaretskii
2023-12-31 15:21                               ` Dmitry Gutov
2023-12-29 22:29                     ` Stefan Kangas
2023-12-30  1:50                       ` Dmitry Gutov
2023-12-30 20:31                         ` Stefan Kangas
2023-12-30 22:50                           ` Dmitry Gutov
2023-12-30 23:25                             ` Stefan Kangas
2023-12-30 23:58                               ` Dmitry Gutov
2023-12-31  7:23                                 ` Eli Zaretskii
2023-12-31 15:31                                   ` Dmitry Gutov
2023-12-29 22:17                 ` Stefan Kangas
2023-12-30  1:31                   ` Dmitry Gutov
2023-12-30 20:56                     ` Stefan Kangas
2023-12-30 23:23                       ` Dmitry Gutov
2023-12-31  0:03                         ` Stefan Kangas
2023-12-31  6:34                       ` Eli Zaretskii
2023-12-31  7:22                         ` Stefan Kangas
2023-12-31 15:22                           ` Dmitry Gutov
2023-12-31 15:25                         ` Dmitry Gutov
2023-12-31 16:42                           ` Eli Zaretskii
2023-12-31 17:53                             ` Dmitry Gutov
2023-12-31 19:27                               ` Eli Zaretskii
2024-01-01  1:23                                 ` Dmitry Gutov
2024-01-01 12:07                                   ` Eli Zaretskii [this message]
2024-01-01 15:47                                     ` Dmitry Gutov
2024-01-01 16:50                                       ` Eli Zaretskii
2024-01-01 17:23                                         ` Dmitry Gutov
2024-01-01 17:39                                           ` Eli Zaretskii
2024-01-01 18:48                                             ` Dmitry Gutov
2024-01-01 19:25                                               ` Eli Zaretskii
2024-01-02  1:40                                                 ` Dmitry Gutov
2024-01-04  1:56                                                   ` Dmitry Gutov
2024-01-02 10:41                               ` Francesco Potortì
2024-01-02 13:09                                 ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83ttnx1clj.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=67687@debbugs.gnu.org \
    --cc=dmitry@gutov.dev \
    --cc=eskinjp@gmail.com \
    --cc=michael.albinus@gmx.de \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).