GNU bug report logs -
#75946
[PATCH] Avoid infinite questions if TAGS file was removed
Previous Next
To reply to this bug, email your comments to 75946 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#75946
; Package
emacs
.
(Thu, 30 Jan 2025 14:17:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 30 Jan 2025 14:17:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
[1.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#75946
; Package
emacs
.
(Thu, 30 Jan 2025 15:38:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 75946 <at> debbugs.gnu.org (full text, mbox):
> From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#75946
; Package
emacs
.
(Thu, 30 Jan 2025 15:45:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 75946 <at> debbugs.gnu.org (full text, mbox):
On Thu, 2025-01-30 at 17:37 +0200, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> > 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.
In autocompletion context it results in complete inability type text, because the
user gets spammed by the prompt on every letter.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#75946
; Package
emacs
.
(Sat, 01 Feb 2025 10:04:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 75946 <at> debbugs.gnu.org (full text, mbox):
> From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> Cc: 75946 <at> debbugs.gnu.org
> Date: Thu, 30 Jan 2025 18:44:31 +0300
>
> On Thu, 2025-01-30 at 17:37 +0200, Eli Zaretskii wrote:
> > > From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> > > 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.
> 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?
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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#75946
; Package
emacs
.
(Sat, 01 Feb 2025 10:17:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 75946 <at> debbugs.gnu.org (full text, mbox):
On Sat, 2025-02-01 at 12:03 +0200, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> > Cc: 75946 <at> debbugs.gnu.org
> > Date: Thu, 30 Jan 2025 18:44:31 +0300
> >
> > On Thu, 2025-01-30 at 17:37 +0200, Eli Zaretskii wrote:
> > > > From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> > > > 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 😊
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Sat, 01 Feb 2025 13:47:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
:
bug acknowledged by developer.
(Sat, 01 Feb 2025 13:47:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 75946-done <at> debbugs.gnu.org (full text, mbox):
> From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> Cc: 75946 <at> debbugs.gnu.org
> Date: Sat, 01 Feb 2025 13:16:15 +0300
>
> On Sat, 2025-02-01 at 12:03 +0200, Eli Zaretskii wrote:
> > > From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> > > Cc: 75946 <at> debbugs.gnu.org
> > > Date: Thu, 30 Jan 2025 18:44:31 +0300
> > >
> > > On Thu, 2025-01-30 at 17:37 +0200, Eli Zaretskii wrote:
> > > > > From: Konstantin Kharlamov <Hi-Angel <at> yandex.ru>
> > > > > 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.
This bug report was last modified 7 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.