unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* which-func.el unconditionally requiring edebug
@ 2022-11-25 18:44 Juanma Barranquero
  2022-12-07 15:17 ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Juanma Barranquero @ 2022-11-25 18:44 UTC (permalink / raw)
  To: Emacs developers; +Cc: Lars Magne Ingebrigtsen

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

Lars, would it be possible to delay (require 'edebug) until
lisp-current-defun-name is going to be used?

  commit 55cc8b040b0e3c5f97fd1386d1e9c5a120be6340
  Author: Lars Ingebrigtsen <larsi@gnus.org>
  Date:   2022-08-08 14:31:54 +0200

      Make which-func-mode output less junk

      * lisp/emacs-lisp/lisp-mode.el (lisp-current-defun-name): Use
      edebug specs to find the name (if they exist), and default to
      returning the top-level symbol if there isn't a define-like form
      (bug#49592).

I've spent quite a while trying to understand why

(setq edebug-inhibit-emacs-lisp-mode-bindings t)

was not working, turns out that I have

(eval-when-compile (require 'which-fun))

early in my .emacs and I certainly wasn't expecting it to affect edebug.
The change isn't even mentioned in the commit log.

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

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

* Re: which-func.el unconditionally requiring edebug
  2022-11-25 18:44 which-func.el unconditionally requiring edebug Juanma Barranquero
@ 2022-12-07 15:17 ` Eli Zaretskii
  2022-12-07 15:46   ` Juanma Barranquero
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2022-12-07 15:17 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: emacs-devel, larsi

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 25 Nov 2022 19:44:28 +0100
> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>
> 
> Lars, would it be possible to delay (require 'edebug) until lisp-current-defun-name is going to be used?

Since Lars seems to be unavailable, why don't you try what you are
suggesting, and see if it gives good results?



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

* Re: which-func.el unconditionally requiring edebug
  2022-12-07 15:17 ` Eli Zaretskii
@ 2022-12-07 15:46   ` Juanma Barranquero
  2022-12-07 18:09     ` Juanma Barranquero
  0 siblings, 1 reply; 7+ messages in thread
From: Juanma Barranquero @ 2022-12-07 15:46 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel, larsi

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

On Wed, Dec 7, 2022 at 4:17 PM Eli Zaretskii <eliz@gnu.org> wrote:


> Since Lars seems to be unavailable, why don't you try what you are
> suggesting, and see if it gives good results?
>

I'll take a stab at it.

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

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

* Re: which-func.el unconditionally requiring edebug
  2022-12-07 15:46   ` Juanma Barranquero
@ 2022-12-07 18:09     ` Juanma Barranquero
  2022-12-07 18:17       ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Juanma Barranquero @ 2022-12-07 18:09 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel, larsi

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

In fact, I think the (require 'edebug) in which-func.el is leftover code. I
didn't realize that Lars had in fact reverted that patch, sort of.

In 55cc8b040b (2022-08-08), he modified lisp-mode.el (mentioned in the
commit log), and also which-func.el and lisp-mode-tests.el (these are not
mentioned).

And then, in 48b0f2606b (2022-08-23), he removed just the changes to
lisp-mode.el, but he left the new tests and the change in which-func.el.

His reverting lisp-mode.el left behind a few little changes, but he removed
all references to edebug-form-spec, so there's no point now to the one-line
change to which-func.el and it should be reverted too, I think.

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

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

* Re: which-func.el unconditionally requiring edebug
  2022-12-07 18:09     ` Juanma Barranquero
@ 2022-12-07 18:17       ` Eli Zaretskii
  2022-12-07 21:28         ` Juanma Barranquero
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2022-12-07 18:17 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: emacs-devel, larsi

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 7 Dec 2022 19:09:30 +0100
> Cc: emacs-devel@gnu.org, larsi@gnus.org
> 
> In fact, I think the (require 'edebug) in which-func.el is leftover code. I didn't realize that Lars had in fact
> reverted that patch, sort of.
> 
> In 55cc8b040b (2022-08-08), he modified lisp-mode.el (mentioned in the commit log), and also
> which-func.el and lisp-mode-tests.el (these are not mentioned).
> 
> And then, in 48b0f2606b (2022-08-23), he removed just the changes to lisp-mode.el, but he left the new tests
> and the change in which-func.el.
> 
> His reverting lisp-mode.el left behind a few little changes, but he removed all references to
> edebug-form-spec, so there's no point now to the one-line change to which-func.el and it should be reverted
> too, I think.

If that require is not needed, there should be no problem removing it.



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

* Re: which-func.el unconditionally requiring edebug
  2022-12-07 18:17       ` Eli Zaretskii
@ 2022-12-07 21:28         ` Juanma Barranquero
  2022-12-08  6:11           ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Juanma Barranquero @ 2022-12-07 21:28 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel, larsi

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

On Wed, Dec 7, 2022 at 7:17 PM Eli Zaretskii <eliz@gnu.org> wrote:

> If that require is not needed,

It isn't. It was just added to help fix a problem that wasn't fixed.

> there should be no problem removing it.

Release branch, or master?

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

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

* Re: which-func.el unconditionally requiring edebug
  2022-12-07 21:28         ` Juanma Barranquero
@ 2022-12-08  6:11           ` Eli Zaretskii
  0 siblings, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2022-12-08  6:11 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: emacs-devel, larsi

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 7 Dec 2022 22:28:40 +0100
> Cc: emacs-devel@gnu.org, larsi@gnus.org
> 
> > there should be no problem removing it.
> 
> Release branch, or master?

Release branch is fine.



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

end of thread, other threads:[~2022-12-08  6:11 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-25 18:44 which-func.el unconditionally requiring edebug Juanma Barranquero
2022-12-07 15:17 ` Eli Zaretskii
2022-12-07 15:46   ` Juanma Barranquero
2022-12-07 18:09     ` Juanma Barranquero
2022-12-07 18:17       ` Eli Zaretskii
2022-12-07 21:28         ` Juanma Barranquero
2022-12-08  6:11           ` Eli Zaretskii

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