Subject: Re: bug#75946: [PATCH] Avoid infinite questions if TAGS file was removed

From: Eli Zaretskii <[email-masked]>
Date: Sat, 01 Feb 2025 15:46:11 +0200

> From: Konstantin Kharlamov <[email-masked]>
> Cc: [email-masked]
> Date: Sat, 01 Feb 2025 13:16:15 +0300
> 
> On Sat, 2025-02-01 at 12:03 +0200, Eli Zaretskii wrote:
> > > From: Konstantin Kharlamov <[email-masked]>
> > > Cc: [email-masked]
> > > Date: Thu, 30 Jan 2025 18:44:31 +0300
> > > 
> > > On Thu, 2025-01-30 at 17:37 +0200, Eli Zaretskii wrote:
> > > > > From: Konstantin Kharlamov <[email-masked]>
> > > > > Date: Thu, 30 Jan 2025 17:16:13 +0300
> > > > > 
> > > > > When the visited TAGS file was removed, commands that depend on
> > > > > TAGS
> > > > > such as auto-completion may invoke an interactive question
> > > > > whether
> > > > > a
> > > > > user wants to re-read the file.  From that point on, the
> > > > > question
> > > > > will
> > > > > be asked over and over, because the file no longer exists,
> > > > > which
> > > > > results in mtime mismatch and inability to "fix the mismatch"
> > > > > by
> > > > > reading from the file.  Fix that by simply ignoring the
> > > > > mismatch if
> > > > > the file no longer exists.
> > > > 
> > > > Thanks, but can you please show a recipe, starting from "emacs -
> > > > Q",
> > > > which could be used to reproduce this problem?
> > > 
> > > Sure. Idk of any Emacs tags auto-completion functions, but I don't
> > > it's particularly
> > > important in the context. I use below a `(tags-completion-table)`
> > > instead.
> > > 
> > > 1. Create empty tags `touch /tmp/TAGS`
> > > 2. Launch Emacs with `emacs -Q --eval '(visit-tags-table
> > > "/tmp/TAGS")'`
> > > 3. Remove the tags: `rm /tmp/TAGS`
> > > 4. In Emacs evaluate `(tags-completion-table)`
> > > 
> > > You'll get the question if you want to re-read from TAGS file, and
> > > disregarding
> > > whether you reply "yes" or "no", each time you execute `(tags-
> > > completion-table)`
> > > again you'll get the prompt again and again.
> > 
> > When I repeat these steps, Emacs signals an error:
> > 
> >   (error "File .../TAGS no longer exists!")
> > 
> > This comes from revert-buffer, called by tags-verify-table.  I wonder
> > why you see something different.
> 
> Correct, I see the same thing. The error isn't a problem (a user likely
> knows the file was deleted), the problem is that every time you execute
> the function you'll be getting the question over and over, and you
> can't do anything with that.
> 
> > > In autocompletion context it results in complete inability type
> > > text, because the
> > > user gets spammed by the prompt on every letter.
> > 
> > Maybe the autocompletion runs with ignore-errors or something?
> 
> Sorry, maybe I was unclear. Triggering autocompletion works same way as
> triggering `(tags-completion-table)` in the example above: you get a
> question, you might answer "yes" or "no", but disregarding what you
> answer, the next time it's triggered you'll get the question again. But
> the problem is more prominent with autocompletion compared to manually
> calling the function above, because completion is triggered on every
> key you typing, so you get basically get spammed by these questions. It
> isn't something serious, it's just an annoyance a user have to work
> around somehow, but I figured it is an easy one to fix so decided to
> send the patch 😊
> 
> > As for your patch: verify-visited-file-modtime returns t for files
> > that never existed -- is that case covered by the patch?  Maybe we
> > should text file-exists-p before calling verify-visited-file-modtime?
> 
> I don't have strong preference, but given that order doesn't matter too
> much, I put the `(file-exists-p)` after the `(verify-visited-file-
> modtime)` check because it seems the case where TAGS file is deleted is
> an unlikely one. So basically I micro-optimized the order in preference
> of the more likely case. And the diff is also one line shorter 😊
> 
> But if you prefer, I can swap the order 😊

No need, I've now installed the patch on the master branch, and I'm
therefore closing the bug.

Thanks.