bug#67687: Feature request: automatic tags management

[Dmitry Gutov]

On 20/12/2023 23:11, Jon Eskin wrote:
> > Wow! This is excellent, worked like a charm on my end.
> >
> > I’m going to get this set up on a few different machines and take some 
> > time to build feedback.
> >
> > Thank you!
>
> Just a quick follow up - I’ve been using this every day. I’ve been able 
> to work without thinking about tags at all, and it’s been a huge QOL 
> upgrade for me.

Excellent.

> The only road-bumps I had in the last few weeks were the following:
>
> 1) In some repositories I unknowingly had an existing universal ctags 
> file “tags”. When I did, trying to goto-def would give an error like 
> "user-error: File /Users/jon/development/c/clp/TAGS is not a valid tags 
> table”. This was misleading, because the actual file on my filesystem is 
> "/Users/jon/development/c/clp/tags”. Usually I differentiate ctags 
> format from etags by the capitalization of the filename, and that error 
> message makes it look like it’s an etags file. I’m guessing this has 
> something to do with MacOS file system case insensitivity on the file 
> system.

Hm, the first advice I would give is customize 'etags-regen-tags-file' 
to something else -- e.g. "RETAGS"? Then it won't match existing files.

Later we could also add some file format verification (a regexp search 
or two), but probably not in the first version.

> 2) I had always generated tags with a path argument for some reason, so 
> when I customized “Etags Regen Program” to “ctags -e -R .”, I got an 
> error since it appends an -o option to the end. I just needed to glance 
> at the source and experiment for a minute to realize I just needed to 
> remove the “.”.

And "-R", I hope. Though it probably makes no difference, since none of 
the arguments passed to it are directories.

Yeah, "-R ." is antithetical to how the program is used. We can extend 
the :type argument for this option, adding "ctags -e" at least. Maybe a 
longer docstring as well.

> I don’t mean to suggest those are problems to be fixed, I can’t really 
> think of any addition or change that would make sense to try to address 
> them, but I figured I would report them in case you had any ideas.
>
> Overall this package gets a big thumbs up from me and I think it would 
> be a great inclusion in a future release. Thank you for sharing it!

Thanks for testing!

That is a good sign (with another positive bit of feedback on Reddit 
yesterday), so I think it's time to ask the head maintainers what they 
think about the inclusion of this feature in the core now.

Eli/Stefan?