From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Siyuan Chen Newsgroups: gmane.emacs.bugs Subject: bug#71727: Deleting TAGS buffer will cause `etags-regen--update-file` doesn't work Date: Sat, 29 Jun 2024 19:49:50 +0800 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000005b4b21061c05f523" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9301"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71727@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 29 13:51:27 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sNWc3-0002Ch-64 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Jun 2024 13:51:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sNWbg-0004mg-NY; Sat, 29 Jun 2024 07:51:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sNWbf-0004lg-1y for bug-gnu-emacs@gnu.org; Sat, 29 Jun 2024 07:51:03 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sNWbe-00037I-QK for bug-gnu-emacs@gnu.org; Sat, 29 Jun 2024 07:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sNWbe-0005UH-EH for bug-gnu-emacs@gnu.org; Sat, 29 Jun 2024 07:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Siyuan Chen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Jun 2024 11:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71727 X-GNU-PR-Package: emacs Original-Received: via spool by 71727-submit@debbugs.gnu.org id=B71727.171966184521067 (code B ref 71727); Sat, 29 Jun 2024 11:51:02 +0000 Original-Received: (at 71727) by debbugs.gnu.org; 29 Jun 2024 11:50:45 +0000 Original-Received: from localhost ([127.0.0.1]:37225 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sNWbM-0005Ti-Nd for submit@debbugs.gnu.org; Sat, 29 Jun 2024 07:50:45 -0400 Original-Received: from mail-yw1-f178.google.com ([209.85.128.178]:55702) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sNWbK-0005TV-FJ for 71727@debbugs.gnu.org; Sat, 29 Jun 2024 07:50:44 -0400 Original-Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-643f1ee4b3cso13954317b3.3 for <71727@debbugs.gnu.org>; Sat, 29 Jun 2024 04:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719661777; x=1720266577; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CorB/+5fzJkV7w7w7Cv73sa5dCr3YZA+cghyvGiz8tY=; b=ikNIP9inkpsRPsiTpaC/Xxilag1pYZGyy24xVtwX6fclrOW2OnJgc+CHc7ZMy8Stl7 v6JxzfzqsJvFyUCTYz6dDF3eJVU0N10283birrg+EaKJFzi//F2EfN2NcALItLeFcCAm qQ50Si84pPSwAQGvy7vy+ZoYMtHL7Xk45Uli0gX6+F0656QwFUhjeH1+McewxAnH80BQ MzkA3wrm7stkCt+Hq8gBjjASFMY29XwRi9Le2SngrsbLMOLXFpcOv8f1B63L6JByJ/Zt CeYb8VKww5VmD/hmABPylyfQKczHK/Oc8OCTzrmSBigprG/iuI5Nlk8rIYVJb/2EA0gt lxAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719661777; x=1720266577; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CorB/+5fzJkV7w7w7Cv73sa5dCr3YZA+cghyvGiz8tY=; b=lrva5syhb/LvYxjYtr2v0Ck7rKWGjkJZLWrpvd9XoiX5LJ89xWCEjEExpPBBZ1R2vm JhsNyuu9dG3pRTy1Y/Fk0skX2vcJuJJW4CzPD+6rhVb/R5J8ne3K1jsZtgLM6g1Soy1n BhBH5T3Fl8QLzn3CXE3hG5dvEUWy+sh7bbAaoUWe6MOEar6ojHotOXicyTh+4TX0TMpX LzVsNRNug6OAzkvoVijRHMHjBW5GK77+NaQi8trsVP5TiHTHKXvAM0EiKBbRCDChdmFE 7XgfliNvwTQbmd8hlvcVc6ZHnBTeFPCXV9tegNeTQeFTt+L4FICT2pEL0LiazqAQutpp mM8g== X-Gm-Message-State: AOJu0YwBmQVGxFC1Q+JfylvO/H77DCrEVCj/cXCcmBoxtWRKa9XngPwH 36fUaY0ywGwPHhIfJMFpeFjwMz0qEW2FzAhEVUM0Q7CwjDCyKnzMVt1AZsC3ks0jalNtQ8gRQU3 xrw8cmdgiLfW+zvSYoEfb9GOn+WI= X-Google-Smtp-Source: AGHT+IFWujFa9sbuDjn9K7I8xFZv1nArAimAmpuxRajo96uZbqvxg0kExUdge5tsmvc2EKO930IaO/AoRXw3afV5QeI= X-Received: by 2002:a05:690c:a8b:b0:64a:79f6:2f2d with SMTP id 00721157ae682-64c71fc2387mr8376527b3.31.1719661777076; Sat, 29 Jun 2024 04:49:37 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:288107 Archived-At: --0000000000005b4b21061c05f523 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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=E2=80=AFAM Dmitry Gutov wro= te: > 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. > --0000000000005b4b21061c05f523 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Is there are particular reason you killed the TAGS buffer?=20

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

Another option is to temporarily add documentation advising=20 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=E2=80=AFAM 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

=C2=A0 =C2=A0(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 <= br> 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.
--0000000000005b4b21061c05f523--