Hi all,

First, thanks for all the attention this has received. Eli, your comments
are duly noted.

Trying my best to follow this thread, I took the patch submitted by Gerd,
pasted it in my scratch buffer, renamed the macro 'my-cl-flet', but
switched the order of the two '&define' clauses. I evaluated this macro and
started using it on some small test cases, which check out. I believe I may
merely be echoing Gerd's comment about exchanging the two debug specs, but
I wanted to flesh this aspect out a bit more thoroughly in case. Note that
I've used Org source blocks (which I've noticed people have been doing),
since I suspect people are reading this thread in Emacs itself, and can
subsequently avail themselves of this format.

Under 'emacs -Q':

#+begin_src emacs-lisp
(require 'cl-macs)

;; insert 'my-cl-flet' macro definition here

(my-cl-flet ((cool-fn ((min max))
                      (cons min max)))
  (cool-fn '(2 3)))
#+end_src

Edebug here runs as smooth as butter. Nice!

Next, I tried another example mentioned in this thread:

#+begin_src emacs-lisp
(defun make-fun (n)
  (message "the function")
  (lambda () n))

(defvar k 17)

(my-cl-flet ((a (make-fun k))) ;; `make-fun' call not instrumented
  (a))
#+end_src

Again, everything looks good. Finally, a more conventional example:

#+begin_src emacs-lisp
(my-cl-flet ((fn (a b)
                 (cons a b)))
  (fn 1 2))
#+end_src

Works out, as expected. So it looks like we may have a happy ending after
all?

WDYT?

On Tue, Aug 22, 2023 at 4:05 AM Gerd Möllmann <gerd.moellmann@gmail.com>
wrote:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
> > Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> >
> >> I wonder if this isn't a bug in cl-flet itself.  If you change the names
> >> a bit, this is
> >>
> >> (cl-flet ((fn (a b)))
> >>   ...)
> >>
> >> which is a perfectly valid local definition of FN with two parameter A
> >> and B, returning nil in CL.  It signals an error in Emacs which I'd
> >> consider a bug.
> >
> > It's a known limitation, AFAIR.  It's more important to support the
> > (SYMBOL EXPR) than this corner case, and we don't want to guess "what is
> > meant", so a binding of two elements is always interpreted this way in
> > Elisp.  This problem has been discussed a while ago.
>
> That's quite unfortunate :-(.  I wish that whole extension would be at
> least be deprecated.
>
> I'll exchange the two debug specs then.  ATM, I don't see how to test
> that though.  That's also unfortunate.
>
> > Hmm, right...but where did I see it.  Oh, I remember, it was
> > `cl-defmethod' that supports such names.
>
> Looks like it does, indeed, by constructing a symbol.  One couldn't tell
> from the doc string :-).
>