unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#71727: Deleting TAGS buffer will cause `etags-regen--update-file` doesn't work
@ 2024-06-22 23:55 Siyuan Chen
  2024-06-27  8:49 ` Eli Zaretskii
  2024-06-28  1:23 ` Dmitry Gutov
  0 siblings, 2 replies; 6+ messages in thread
From: Siyuan Chen @ 2024-06-22 23:55 UTC (permalink / raw)
  To: 71727

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

Reproduce steps:

1. init.el
```
(setq etags-regen-program "C:/green/emacs/emacs-29.3/bin/etags.exe")
(require 'etags-regen)
```

2. Open test.c with the following code
```
#define APPLICATION_WINDOW_WIDTH 320
```

3. M-x etags-regen-mode

4. Move the cursor to APPLICATION_WINDOW_WIDTH and M-x
xref-find-definitions. Then the TAGS file is created and the
APPLICATION_WINDOW_WIDTH line is highlighted (good).

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.

The expected behavior: The TAGS file is updated and the
APPLICATION_WINDOW_HEIGHT line is highlighted.

The actual behavior: The echo area reports: "No definition found for:
APPLICATION_WINDOW_HEIGHT"

Note that if I don't do step-5 then everything is OK.

Emacs 29.3 has no this feature, I make it available via copy & paste
etags-regen.el to load-path. I think this issue has nothing to do with the
Emacs version though.

Thanks.

Best regards,
Siyuan Chen

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#71727: Deleting TAGS buffer will cause `etags-regen--update-file` doesn't work
  2024-06-22 23:55 bug#71727: Deleting TAGS buffer will cause `etags-regen--update-file` doesn't work Siyuan Chen
@ 2024-06-27  8:49 ` Eli Zaretskii
  2024-06-28  1:23 ` Dmitry Gutov
  1 sibling, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2024-06-27  8:49 UTC (permalink / raw)
  To: Siyuan Chen, Dmitry Gutov; +Cc: 71727

> From: Siyuan Chen <chansey97@gmail.com>
> Date: Sun, 23 Jun 2024 07:55:49 +0800
> 
> Reproduce steps:
> 
> 1. init.el
> ```
> (setq etags-regen-program "C:/green/emacs/emacs-29.3/bin/etags.exe")
> (require 'etags-regen)
> ```
> 
> 2. Open test.c with the following code
> ```
> #define APPLICATION_WINDOW_WIDTH 320
> ```
> 
> 3. M-x etags-regen-mode
> 
> 4. Move the cursor to APPLICATION_WINDOW_WIDTH and M-x xref-find-definitions. Then the TAGS file is
> created and the APPLICATION_WINDOW_WIDTH line is highlighted (good).
> 
> 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.
> 
> The expected behavior: The TAGS file is updated and the APPLICATION_WINDOW_HEIGHT line is
> highlighted.
> 
> The actual behavior: The echo area reports: "No definition found for: APPLICATION_WINDOW_HEIGHT"
> 
> Note that if I don't do step-5 then everything is OK.
> 
> Emacs 29.3 has no this feature, I make it available via copy & paste etags-regen.el to load-path. I think this
> issue has nothing to do with the Emacs version though. 

Thanks.

Dmitry, could you please look into this?





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#71727: Deleting TAGS buffer will cause `etags-regen--update-file` doesn't work
  2024-06-22 23:55 bug#71727: Deleting TAGS buffer will cause `etags-regen--update-file` doesn't work Siyuan Chen
  2024-06-27  8:49 ` Eli Zaretskii
@ 2024-06-28  1:23 ` Dmitry Gutov
  2024-06-29 11:49   ` Siyuan Chen
  1 sibling, 1 reply; 6+ messages in thread
From: Dmitry Gutov @ 2024-06-28  1:23 UTC (permalink / raw)
  To: Siyuan Chen, 71727

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.





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#71727: Deleting TAGS buffer will cause `etags-regen--update-file` doesn't work
  2024-06-28  1:23 ` Dmitry Gutov
@ 2024-06-29 11:49   ` Siyuan Chen
  2024-07-09  2:50     ` Dmitry Gutov
  0 siblings, 1 reply; 6+ messages in thread
From: Siyuan Chen @ 2024-06-29 11:49 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: 71727

[-- 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 --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#71727: Deleting TAGS buffer will cause `etags-regen--update-file` doesn't work
  2024-06-29 11:49   ` Siyuan Chen
@ 2024-07-09  2:50     ` Dmitry Gutov
  2024-07-11  0:50       ` Dmitry Gutov
  0 siblings, 1 reply; 6+ messages in thread
From: Dmitry Gutov @ 2024-07-09  2:50 UTC (permalink / raw)
  To: Siyuan Chen; +Cc: 71727

Hi again!

On 29/06/2024 14:49, Siyuan Chen wrote:
>  > 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.

Thanks for the clarification.

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

I think actually a simpler approach can suffice: using kill-buffer-hook 
in the TAGS buffer. Like this:

diff --git a/lisp/progmodes/etags-regen.el b/lisp/progmodes/etags-regen.el
index dc778b14061..21ea9bfb8b3 100644
--- a/lisp/progmodes/etags-regen.el
+++ b/lisp/progmodes/etags-regen.el
@@ -294,7 +294,9 @@ etags-regen--visit-table
    (add-hook 'before-save-hook #'etags-regen--mark-as-new)
    (setq etags-regen--tags-file tags-file
          etags-regen--tags-root root)
-  (visit-tags-table etags-regen--tags-file))
+  (visit-tags-table etags-regen--tags-file)
+  (with-current-buffer (get-file-buffer tags-file)
+    (add-hook 'kill-buffer-hook #'etags-regen--tags-cleanup nil t)))

  (defun etags-regen--ctags-p ()
    (string-search "Ctags"
@@ -390,7 +392,8 @@ etags-regen--mark-as-new

  (defun etags-regen--tags-cleanup ()
    (when etags-regen--tags-file
-    (let ((buffer (get-file-buffer etags-regen--tags-file)))
+    (let ((buffer (get-file-buffer etags-regen--tags-file))
+          kill-buffer-hook)
        (and buffer
             (kill-buffer buffer)))
      (tags-reset-tags-tables)






^ permalink raw reply related	[flat|nested] 6+ messages in thread

* bug#71727: Deleting TAGS buffer will cause `etags-regen--update-file` doesn't work
  2024-07-09  2:50     ` Dmitry Gutov
@ 2024-07-11  0:50       ` Dmitry Gutov
  0 siblings, 0 replies; 6+ messages in thread
From: Dmitry Gutov @ 2024-07-11  0:50 UTC (permalink / raw)
  To: Siyuan Chen; +Cc: 71727-done

Now pushed to emacs-30, please report any further problems.

On 09/07/2024 05:50, Dmitry Gutov wrote:
> On 29/06/2024 14:49, Siyuan Chen wrote:
>>  > 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.
> 
> Thanks for the clarification.
> 
>> 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.
> 
> I think actually a simpler approach can suffice: using kill-buffer-hook 
> in the TAGS buffer. Like this:
> 
> diff --git a/lisp/progmodes/etags-regen.el b/lisp/progmodes/etags-regen.el
> index dc778b14061..21ea9bfb8b3 100644
> --- a/lisp/progmodes/etags-regen.el
> +++ b/lisp/progmodes/etags-regen.el
> @@ -294,7 +294,9 @@ etags-regen--visit-table
>     (add-hook 'before-save-hook #'etags-regen--mark-as-new)
>     (setq etags-regen--tags-file tags-file
>           etags-regen--tags-root root)
> -  (visit-tags-table etags-regen--tags-file))
> +  (visit-tags-table etags-regen--tags-file)
> +  (with-current-buffer (get-file-buffer tags-file)
> +    (add-hook 'kill-buffer-hook #'etags-regen--tags-cleanup nil t)))
> 
>   (defun etags-regen--ctags-p ()
>     (string-search "Ctags"
> @@ -390,7 +392,8 @@ etags-regen--mark-as-new
> 
>   (defun etags-regen--tags-cleanup ()
>     (when etags-regen--tags-file
> -    (let ((buffer (get-file-buffer etags-regen--tags-file)))
> +    (let ((buffer (get-file-buffer etags-regen--tags-file))
> +          kill-buffer-hook)
>         (and buffer
>              (kill-buffer buffer)))
>       (tags-reset-tags-tables)






^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2024-07-11  0:50 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-06-22 23:55 bug#71727: Deleting TAGS buffer will cause `etags-regen--update-file` doesn't work Siyuan Chen
2024-06-27  8:49 ` Eli Zaretskii
2024-06-28  1:23 ` Dmitry Gutov
2024-06-29 11:49   ` Siyuan Chen
2024-07-09  2:50     ` Dmitry Gutov
2024-07-11  0:50       ` Dmitry Gutov

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).