bug#71727: Deleting TAGS buffer will cause `etags-regen--update-file` doesn't work

[Siyuan Chen <chansey97@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]

 > 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.
>

[-- Attachment #2: Type: text/html, Size: 3885 bytes --]