GNU bug report logs -
#67687
Feature request: automatic tags management
Previous Next
Reported by: Jon Eskin <eskinjp <at> gmail.com>
Date: Thu, 7 Dec 2023 11:45:02 UTC
Severity: wishlist
Done: Dmitry Gutov <dmitry <at> gutov.dev>
Bug is archived. No further changes may be made.
Full log
Message #23 received at 67687 <at> debbugs.gnu.org (full text, mbox):
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?
This bug report was last modified 1 year and 142 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.