help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Eval keymapp in a macros


From: Arthur Miller
Subject: Re: Eval keymapp in a macros
Date: Thu, 12 Aug 2021 22:28:59 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Michael Heerdegen <michael_heerdegen@web.de> writes:

Sorry for the little bit late answer. I didn't had time to look at this
immidiately, and then it just was left.

> Arthur Miller <arthur.miller@live.com> writes:
>
>> > And instead of `eval' better use `bound-and-true-p' - you know that you
>> > look at a symbol.
>>
>> Thanks. I can remove at least the eval in test with bound-and-true-p,
>> but I don't think I can remove the second eval, since I have to get
>> object the symbol is representing.
>
> And exactly this is what `bound-and-true-p' returns.  But that doesn't
Aha, I did a little bit of a noob thing there, and didn't checked the
docs. Just expected return to be a boolean and forgott that in elisp,
actually lots of stuff return the object itself, which is handy (like
`or', or `and' etc).

> matter if you are actually having a problem like this:
>
>> However I am getting false positives from keymapp, it accepts anything
>> seems like:
>>
>> (defmacro with-key-map (mapname &rest body)
>>   `(dolist (def '(,@body))
>>      (define-key ,mapname
>>        (if (vectorp (car def)) (car def)
>>       (read-kbd-macro (car def)))
>>        (if `(bound-and-true-p ,(cdr def))
>>              (if `(keymapp ,(cdr def))
>>                  (eval (cdr def))
>>                (cdr def))))))
>>
>> Instead I have to use to test for listp and functionp first:
>>
>> (defmacro with-key-map (mapname &rest body)
>>   `(dolist (def '(,@body))
>>      (define-key ,mapname
>>        (if (vectorp (car def)) (car def)
>>       (read-kbd-macro (car def)))
>>        (if `(bound-and-true-p ,(cdr def))
>>            (if (or (listp (cdr def))
>>                    (functionp (cdr def)))
>>                (cdr def)
>>              (if `(keymapp ,(cdr def))
>>                  (eval (cdr def))))))))
>>
>> And I can also remove last if, and just leave eval, keymapp does not
>> seems to cull anything out.
>
> I think you have a problem here with these nested backquotes, not
> everything you think gets evaluated.  Have a look at the expansion
> (`macroexpand').
>
>> Anyway, thanks you for the help and feedback. I do have some better
>> understanding after this.
>
> An honest opinion: Maybe the advice to start with a function is the best
> one so far.  Else you will be wasting time for nothing.  Don't write
> macro code and look what happens when you call it and then try to fix
> what seems to be wrong.  You'll get crazy and not learn very much.  That
> approach doesn't work for most human brains.

Yes, that is a very good advice, if anyone else than me is reading this
in the future.

> One cool trick for learning: make the macro expander a named function.
>
> I'm using your first definition from above - it is equivalent to
>
> #+begin_src emacs-lisp
> (defmacro with-key-map (mapname &rest body)
>   (apply #'my-with-key-map-expander mapname body))
>
> (defun my-with-key-map-expander (mapname &rest body)
>   `(dolist (def '(,@body))
>      (define-key ,mapname
>        (if (vectorp (car def)) (car def)
>        (read-kbd-macro (car def)))
>        (if `(bound-and-true-p ,(cdr def))
>            (if (or (listp (cdr def))
>                    (functionp (cdr def)))
>                (cdr def)
>              (if `(keymapp ,(cdr def))
>                  (eval (cdr def))))))))
> #+end_src
>
> While this is semantically exactly the same and doesn't make much of a
> difference you can now better study what the expander does: how it
> transforms code (or forms) to code (to be evaluated).
>
> E.g. now
>
>   (with-key-map global-map ([f1] . make-frame-command))
>
> will internally use an ordinary function call:
>
>   (my-with-key-map-expander 'global-map '([f1] . emacs-list-mode-map))
>
> to generate the expansion.  You can use the debugger, study the return
> value etc.  Why does the code it returns not work as expected?  Would
> you write the code like that?
>
> To repeat: this is actually working in the wrong direction.  Better
> start from the expected expansion, and then write an expander function
> that generates that expansion.

Indeed, and I agree. That was something like that I meant when I answered
in some earlier mail to Stefan. Anyway It all start with simple 6 lines
of very simple macro which worked out straightforward, so I was all the
time just "hacking" a single case it didn't worked for. But yes, in the
end, it is not very good approach.

Thank you for the help.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]