Re: Automatic (e)tags generation and incremental updates

[Tom Tromey <tom@tromey.com>]

Dmitry> - Do we want to store the generated files openly in the root
Dmitry>   directories of each project?

Yeah.  Either way is fine by me, since the projects I work on already
have TAGS in their .gitignore.

Dmitry> Storing them with "garbled" names somewhere in /tmp of XDG cache
Dmitry> risks having to fully renenerate the indexes at least every time
Dmitry> the machine reboots.

Does anyone really configure their system this way?  XDG warns about
relying on the cache, but in practice I think that is a warning for
developers -- the model being that the user should be able to delete the
cache at any time.  At least on the systems I've used, the cache is
persistent in practice.

Dmitry> Is eliminating the delay worth the
Dmitry> code complexity and increased memory usage?

It should certainly be an option.  Memory is just no barrier on typical
machines these days.

Dmitry> If general, doing updates when Emacs is idle and/or asynchronously are
Dmitry> quality-of-life changes that can come later after we improve
Dmitry> correctness (i.e. make sure the index is up to date even after
Dmitry> external changes).

Please try it on a non-trivial project before committing to something.
IME a lot of these things work fine for simple projects, but when I want
to use them on gdb or gcc, they are unusably slow.

Anyway, thanks for working on this.  Lack of incremental update is why I
stopped using etags, in favor of ggtags.  I hope someday to switch back,
since etags has some features that GNU Global lacks.

Tom