all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Arthur Miller <arthur.miller@live.com>
To: Michael Heerdegen <michael_heerdegen@web.de>
Cc: help-gnu-emacs@gnu.org
Subject: Re: Eval keymapp in a macros
Date: Thu, 05 Aug 2021 08:03:42 +0200	[thread overview]
Message-ID: <AM9PR09MB49770320C31CA38C4D95B5EE96F29@AM9PR09MB4977.eurprd09.prod.outlook.com> (raw)
In-Reply-To: <871r78ydbb.fsf@web.de> (Michael Heerdegen's message of "Thu, 05 Aug 2021 01:56:08 +0200")

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> > Your `keymapp' fix is an emergency solution but it's not perfect:
>> > that test happens at compile time.  If the keymap is not defined at
>> > compile time your compiled code will be inappropriate.
>
> I see now that I was wrong here - the test is performed at run-time.

I discovered that yesterday too. I tried the new macro on my init file,
and it found several left-over bindings after some packages I don't
use any more.

>> I agree, but do I wish to pass name of undefined keymap to define-key?
>
> Not at run-time: when the `define-key' call is evaluated, the symbol
> must be bound, else you would get an error.

Of course, every symbold has to bound when evaled. This is a bit special
use case. I am always ensuring it is evaled in context where everythign
is defined.The use case for my init file is that I pass those stuff
always in 'with-eval-after-load' for some package. So it is always
symbols should be always defined otherwise I have bigger problem then
misspelled syntax. I also expand this myself so I just just write
define-key calls to my init file. However I also have this macro defined
for interpretter, so I can test and eval stuff while I hack my init file.

> But some way or the other something has to decide how to interpret a
> symbol.  If you want to use the same notation for the cases, you need to
> use some kind of heuristic: in theory a symbol might name a function and
> might be bound to a keymap at the same time.

Yes, it's 'lisp-2' ... I like that feature. I know a lot of people
prefer scheme version, but I think it is handy and also more efficient
with 2 namespaces.

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

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.

>                    You could also check whether the `symbol-name' ends
> with "...-map".

I could, there is not guarantee, since it is just a convention, but yes
I agree, I could have done that.

Anyway, thanks  you for the help and feedback. I do have some better
understanding after this.



  reply	other threads:[~2021-08-05  6:03 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-02 12:16 Eval keymapp in a macros Arthur Miller
2021-08-02 20:33 ` Michael Heerdegen
2021-08-02 20:53   ` [External] : " Drew Adams
2021-08-03 21:20   ` Arthur Miller
2021-08-04  0:18     ` Michael Heerdegen
2021-08-04 10:52       ` Arthur Miller
2021-08-04 23:56         ` Michael Heerdegen
2021-08-05  6:03           ` Arthur Miller [this message]
2021-08-06  3:54             ` Michael Heerdegen
2021-08-12 20:28               ` Arthur Miller
2021-08-04  4:54     ` Yuri Khan
2021-08-04  9:38       ` Arthur Miller
2021-08-04 15:37         ` Stefan Monnier via Users list for the GNU Emacs text editor
2021-08-05  6:12           ` Arthur Miller
2021-08-05 13:53             ` Stefan Monnier
2021-08-05 16:04               ` Arthur Miller
2021-08-05 16:34                 ` Stefan Monnier
2021-08-06  4:17                   ` Michael Heerdegen
2021-08-12 20:21                     ` Arthur Miller
2021-08-05  0:03         ` Michael Heerdegen
2021-08-05  6:15           ` Arthur Miller
2021-08-06  3:18             ` Michael Heerdegen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AM9PR09MB49770320C31CA38C4D95B5EE96F29@AM9PR09MB4977.eurprd09.prod.outlook.com \
    --to=arthur.miller@live.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=michael_heerdegen@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.