From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.help Subject: Re: Eval keymapp in a macros Date: Wed, 04 Aug 2021 12:52:09 +0200 Message-ID: References: <87bl6fy4cf.fsf@web.de> <87r1faf4fy.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="575"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: help-gnu-emacs@gnu.org To: Michael Heerdegen Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 04 12:52:50 2021 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mBEW1-000ATP-Nu for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 04 Aug 2021 12:52:50 +0200 Original-Received: from localhost ([::1]:41992 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mBEW0-0005Fx-LG for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 04 Aug 2021 06:52:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42532) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mBEVU-0005Fh-QW for help-gnu-emacs@gnu.org; Wed, 04 Aug 2021 06:52:16 -0400 Original-Received: from mail-vi1eur05olkn2022.outbound.protection.outlook.com ([40.92.90.22]:35937 helo=EUR05-VI1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mBEVR-0005A2-No for help-gnu-emacs@gnu.org; Wed, 04 Aug 2021 06:52:16 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FwnqCZPn+YVv54zM6roHC/VzgCLBvfH9YDaQTvq/0dyDMcm0Er+Qekc4F/jALHY4/Y3UjWopC3nDdSdD/PZMXuDfCd+n37jDCXNq/PIS9/6l6Q6u6l3mF39iRScTUDi24LqEtZ9kppzynibAXsypg9cRSodlrHFtdHdTuvjCD5eh0on5440CRm9dIGLVYfihB0esDQ5lqthu0RYfFGAPRf1uapr83uK876sFTCP01bAsrhUR2i4CY6jGrYuUCJv6i7UUyz2Ggge8ukoCsyvwxaw5rY/uZCun0orAGSSiDZOOrYtUoeLvBKWEctQ/+0go9TKGZpv/TX4nyubwXnenPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1t2s5DSy7BlQNgiuV2Z4him7U9fqsbYAolc7SNSSM3E=; b=HSCC1P1IbfFpYLqkKVCk8ibMt6DsoyTfAx0LAUlG4JAqLlDr+KeSK2LH46gTA26tint8+H6ACI/atViBfShcxN9Yml70yqv99GI433Ce3IJYnOYLsJ22OYwZ28UVC8fOM+o5K0WiNAMqF0CBlmlNoUabBAQqIOHZ8xtErjrk5Xz5RUvAm2Zz5aKbagG67j5q4ZLbui8L7WOs290B7dHp0n1VPCCty+OZX8VAeHC4pYYOfn8Fkmk/nr5nqAe2LPdXV/l+0AYLROk4I5W3/4FEe08nVepgFV8LxFMrB8sz5PTJQlUyCxzwLpRyTb+CDiIktENT3htxoJPGwcY4st2eCA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1t2s5DSy7BlQNgiuV2Z4him7U9fqsbYAolc7SNSSM3E=; b=B0+le0nWVUhdzGkuXcdKdwoLhGKgu4Kzbgm4PFhIFoyg0eJIOK+KOU8XP0vUONcfhVLFspXkkDf69YZYH72eF2LxJmUgrarSISsXx8bjGzk5hYhHCLdj7KoiCh7vf7FptOCbIJ/RQfZM9k0qHywkfkVacNKKsS8NRwPVRZshJDl9NkUYMdglF4OzyO+bTCNxEUBhAUMyELLRzibStU+JeA9bUzRkb9ZQL4mobmkIvxZJpzYLXgSAJ5puzdt4cDvCoqqMFMtC5e4CjoQ27ir3bfzzQeV2xd3sfDzFcpOgAn3IFiak5gF7/EZXjsuGagnf65YMiC+hVBnVKNdysMIFHQ== Original-Received: from VI1EUR05FT054.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc12::43) by VI1EUR05HT101.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc12::126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.18; Wed, 4 Aug 2021 10:52:11 +0000 Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2a01:111:e400:fc12::4c) by VI1EUR05FT054.mail.protection.outlook.com (2a01:111:e400:fc12::144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.18 via Frontend Transport; Wed, 4 Aug 2021 10:52:10 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:4DB6C7E4A38747FAD5F5BC7781F20092D943370D9BB039C7C0335A18F989527E; UpperCasedChecksum:5C6E15EBA776FAA4147AD15822E55A2CA6696AA2A9E3A87C433015A5E900F2E9; SizeAsReceived:7532; Count:46 Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::6558:f201:6d1a:3f39]) by AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::6558:f201:6d1a:3f39%2]) with mapi id 15.20.4394.016; Wed, 4 Aug 2021 10:52:10 +0000 In-Reply-To: <87r1faf4fy.fsf@web.de> (Michael Heerdegen's message of "Wed, 04 Aug 2021 02:18:09 +0200") X-TMN: [ICliJou8xgl1hkya58NKzPifqEldFgn5] X-ClientProxiedBy: BEXP281CA0013.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10::23) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <87czqtcwiu.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 Original-Received: from pascal.homepc (81.232.177.30) by BEXP281CA0013.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.12 via Frontend Transport; Wed, 4 Aug 2021 10:52:10 +0000 X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 46 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 502120b1-5a98-49f1-2bd8-08d95735e907 X-MS-TrafficTypeDiagnostic: VI1EUR05HT101: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: re/9NT0Axc92CnGzmatiO2JyPIiiHdIEPOQAcxhKZL6WaJvbJpgs45oK2K6sxpzBVKSKTKuKdRp3Holu1ZNrrCLT3gM92RzDA1bklme1fzIFJ3JLaS4PyfIOhs/RpWx2OE5qu67madEK+F1WdeL9dn9S3i5ZNUSRPSohYTQw7Hjz4BhJTlCqTMDoMM8BF+0UqQNXmyZY05ehBIuoGqixDzko/rn8k/R7iOwKjvsJoy4YQQb+VPKRDbBJPJCC+u4rpEk91ZN3kSbrl1/7U9cC8gTbpqxMnleqK3FpK8kMlkf8XA2f1aRKG+huqYp/pqIfnSFZ+CwmO5Br/2MqZCXk42OEFto0t1PBBMSTlLmaG5H61z2OwmHxt4hdt6QvSjKvidg/sxCBvgMzx0IsJcr+pOCXt2G71SQ0cORkAR6bHC7ATv+pvAREfVMZ7XYBGHsO X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: F7sU/HncPVaV0uf+5PZe+776Es8CRwUdPoHtlkIvr9yK7kGUt2bndWTWSU8BRO+FyxMWKbYJsugvDf0NB7LRPSLFgDg94utM72Ln3GAx1xKyxrxS6g2g7JGITupnG3VpTrMia2MqRfvhIn/XOIFhkw== X-OriginatorOrg: live.com X-MS-Exchange-CrossTenant-Network-Message-Id: 502120b1-5a98-49f1-2bd8-08d95735e907 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Aug 2021 10:52:10.8899 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: VI1EUR05FT054.eop-eur05.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1EUR05HT101 Received-SPF: pass client-ip=40.92.90.22; envelope-from=arthur.miller@live.com; helo=EUR05-VI1-obe.outbound.protection.outlook.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:132360 Archived-At: Michael Heerdegen writes: > Arthur Miller writes: > >> So I ended with the one I posted which works, but I wonder why, and I >> don't really like it. I think you are correct about the reason. That is >> what I think also, so that is why I used eval, because I need the keymap >> object itself to pass to define-key, at least so I think. Maybe I am >> wrong there? > > You are right. What you get in the expansion is similar to what happens > here: > > (let ((entry '([f11] . emacs-lisp-mode-map))) > (define-key global-map (car entry) (cdr entry))) > > which will also not "work". You never evaluate the bindings - else you > would need to quote your command names. > > With other words: you currently specify command names and keymaps in the > same way (as a symbol) - but the expansion needs to treat them > differently Yes, thank you. I think that is the key here. You put a finger on it as they say. The macro itself is a little dsl that has to do stuff with list of symbols. It is a bit similar situation to cl-loop I guess. > 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 agree, but do I wish to pass name of undefined keymap to define-key? We have seen a move from adding functions to hooks by name to adding function objects. Is there a difference here? > I suggested to expand calls of the macro, not its definition ;-) Aha. I missed that one :). > Unless you wanted to search for bugs in the implementation of > `defmacro'... but let's assume for now that your issue is caused by the > implementation of `with-key-map', and not by `defmacro' ;-) > > >> > Note that nothing in BODY is ever evaluated (it's behind a quote). >> >> Stuff in dolist gets evaluated, because dolist itself is a macro. >> The real body of function which is all in do list gets expanded by >> dolist (or the real interested part by 'while' which seems to be a >> special form) and then evaled by dolist. So dolist will actually call >> define-key for me, and that is what seem to happend, because stuff gets >> defined after I call the macro. I hope I understand correctly what is >> going on there. > > Yes, see my example above: the (quoted) list gets evaluated, but not its > members, so you pass a symbol to `define-key' (what works for command > names but not for keymap names). > > >> As a side note, this isn't really a macro that writes a function or >> another macro and returns it. I have it partly to save myself typing, >> and partly to skip overhead of macroexpansion when Emacs start. Byte >> compiler will expand it when init file is byte compiled. Actually I >> wrote a program to write my init file which does expansion when it >> outputs code to init file but it is just another regression. > > Compiling is a good idea. It would warn you if you misspelled a command > name (your version doesn't support that btw). Oh, there is a lost of things that can go wrong there :). I am aware. Eval could get passed entire program to erase the disk for example. That could be easily hacked to pass funtion objects, I just don't want to use function objects here. It is my private use, so I really prefer it this way. I was thinking of it when I originally wrote it. > That concrete idea is cool but not really suitable for daily use, as you > already have found out: macro expansions can take damage after printing > and re-reading. > > Why do you think you need that? Why is normal code + normal compiling > not sufficient? I could have used define-key all the way, but I wanted to reduce the noise and repetion when typing. Syntatic sugar I guess. There is not more power in this, and unlike for example is case of cl-loop, just some, more error prone, convenience so to say :): (defmacro defkey (mapname &rest body) `(let ((defs '(,@body))) (while defs (define-key ,mapname (if (vectorp (car defs)) (car defs) (read-kbd-macro (car defs))) (if (or (listp (cadr defs)) (functionp (cadr defs))) (cadr defs) (if (eval`(keymapp ,(cadr defs))) (eval (cadr defs))))) (setq defs (cddr defs))))) (defkey global-map "C-" term-toggle "" term-toggle-eshell [f9] ispell-word [S-f10] next-buffer [f10] previous-buffer [f12] kill-buffer-but-not-some [M-f12] kill-buffer-other-window [C-M-f12] only-current-buffer) I think, it removes a lot of noise. Unfortuantely macros are only way to do special forms in elisp and work with unavluated arguments. While manual does not state explicitly that it is not possible to write user special forms, unlike for exmaple some other Lisp implementations, I don't see how anything but macros would be possible in elisp. I find it handy to work with unevaluated arguments. If you compare lisp(s) to TCL where the situation with argument passing is inverted, unevaluated arguments are default and evaluation is explictly asked for when arguments are passed to functions, I sometimes think it is better default. I am not sure yet though :). It is an exercise and learning experience, in how much I can automate and let computer do things for me. I am also learning lisp and elisp, and so I tinker a lot with impossible stuff I "shouldn't" do. Of course there are pitfalls and caveats, but that's expected. I use this is in my init file, so I will pass it correct stuff, it is not some kind of general framework, so for me personally, reduced error catching is acceptable in this case. Since this is a learning experience too, I really wish to understand what was going on there, so thank you for the help.