> Is there are particular reason you killed the TAGS buffer?

No. I found this bug is just because I tried to view the TAGS content while editing a .c file and then closed it (I am using tab-line-mode with tab-line-close-tab-function set to kill-buffer). Since then, I have stopped closing the TAGS buffer.

Another option is to temporarily add documentation advising users not to close the TAGS buffer, because closing it accidentally can result in the odd behavior.

Best regards,

Siyuan Chen

On Fri, Jun 28, 2024 at 9:23 AM Dmitry Gutov <dmitry@gutov.dev> wrote:

Hi!

Thanks for the report.

On 23/06/2024 02:55, Siyuan Chen wrote:
> 5. M-x kill-buffer TAGS
>
> 6. Add `#define APPLICATION_WINDOW_HEIGHT 320` to test.c and M-x save-buffer
>
> 7. Move the cursor to APPLICATION_WINDOW_HEIGHT and M-x
> xref-find-definitions.

What happens here, is etags-regen--update-file (added to
after-save-hook) fails the check

(get-file-buffer etags-regen--tags-file)

and so the buffer and the file are not updated.

Note that if after step 7 you make an edit to the same file and then try
navigating again it will work because at step 7 the tags file is visited
again. So this doesn't seem an urgent problem, but it would be nice to
fix nevertheless.

I think we couldn't re-visit the tags file inside after-save-hook (it
might not be fast enough, for one thing), but the second alternative
mentioned inside the TODO at the top of etags-regen--update-file should
be fix this as well.

Is there are particular reason you killed the TAGS buffer? Perhaps a
quicker fix would be to visit the tags file in a hidden buffer, rather
than use the name that's so easy to find and kill or do something else
by accident.