From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id 4Dg9O30yvmLt5AAAbAwnHQ (envelope-from ) for ; Fri, 01 Jul 2022 01:32:14 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id qLM3On0yvmJqTgEAG6o9tA (envelope-from ) for ; Fri, 01 Jul 2022 01:32:13 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 640FD3D4C1 for ; Fri, 1 Jul 2022 01:32:13 +0200 (CEST) Received: from localhost ([::1]:55736 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o73dr-0004b2-Og for larch@yhetil.org; Thu, 30 Jun 2022 19:32:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52866) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o73c7-0004ZS-OO for emacs-orgmode@gnu.org; Thu, 30 Jun 2022 19:30:23 -0400 Received: from mail-oln040092070068.outbound.protection.outlook.com ([40.92.70.68]:7811 helo=EUR03-AM5-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 1o73c5-00057c-8p for emacs-orgmode@gnu.org; Thu, 30 Jun 2022 19:30:23 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KCTfeqWXq0w1rbwTFrxjRq4vFnJy/YIwJe/08nz2yUge2fd29wOt1LbLpWhD+bwqU5sq1LBodNf0oWH32xto+53B9L489XWMZ3L11ulNvDyZBCI1gddndfKEtqmXwULZ073z3L5qdXE4laoGenhpKcSclkcbrFt1y9PUQ7OYDLmuwTCiVNbkmQ/5EK350cIYQ7rup7Ec1NCQfCahl5LtJz9Wr1gxz9jfgyM0j3m7NS4QZrVim98m1i3iIIrJAn5w8vQyYo2a64y/zNdbHjKly4eSpVNoj7aM1+0rRRWtd6ul5zqwn41Srk3Q404vxWu3NgPBta0NZZVDp7N0TtAQAA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=I9pJRTG5tZ2YvahFTC6LJ3oEFgAx+tmkOn4GjiCMVEM=; b=m4BkE51k5c//dE1Gsvf7eGa9Eem2I6nChbZbKAKIq6FDjoQOAwcQmv6HxgYSrj5VNYTICDxTkVujlkQ/F+1KjL8wc2e2ZPibev3cGarwvX4zazwNbH4s3z2uFc9T8VDAGhG3s3darBnly84UV/bA572kQOcEgFGr8lLKPL/n86irFsf4eJgOgHtysIXPga2fLXccmEQK7km3B9BZS0/8b4YEbC86apgdk42S8HGT1iMgkLe6zH9+LsgJtDyw4gA9zUzCLvZKxEx1TYM+JviuFuTLAM4pbh5DXUx9W9es78VRLq7XyHdxUKcDvajdRv/t+Iebh9e7nK0mIcvEtYvLUQ== 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=I9pJRTG5tZ2YvahFTC6LJ3oEFgAx+tmkOn4GjiCMVEM=; b=CDDA7yVYjvL2i3zr4Fx9edT4WM0T/JAko5CejnFj4Nf6C4jiCN3PO+NuO+q0RA9dUpxD3v1xQyi/qWDsGz+PGFN8TukzQPTpB6wlUfFPGdDQ86QyyUPFLmy3c6iTsbG8oSN3U2IIwNJl1j40KQTMBBmYIgSHJOKklT67yXVmT47E+19uK1LgU+f5xtOyr/4YetqGhA+QeJBQPqwbQPEaR+AaiHWawR4LOfcW70sFXBJuJWKUpbAcPX7XCZ9LPK0DLmUiKX/bI6QYdyXFfzvIpJvByHaKhjfCrK1MyzqBPbQuMaSNeHvyhU0/zzEp1D9MKrAoddqd0sbhwI7j9RkRFw== Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) by VI1PR09MB3885.eurprd09.prod.outlook.com (2603:10a6:800:125::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5395.15; Thu, 30 Jun 2022 23:30:18 +0000 Received: from AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::1995:84ad:afa1:1f39]) by AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::1995:84ad:afa1:1f39%9]) with mapi id 15.20.5395.014; Thu, 30 Jun 2022 23:30:18 +0000 From: Arthur Miller To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: Proposal: 'executable' org-capture-templaes References: <87a6ay1enh.fsf@localhost> <87edzvdb44.fsf@localhost> <878rpu5qf4.fsf@localhost> <87zgi7357y.fsf@localhost> <875ykuslpx.fsf@localhost> Date: Fri, 01 Jul 2022 01:30:16 +0200 In-Reply-To: (Max Nikulin's message of "Thu, 30 Jun 2022 00:02:11 +0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Content-Type: text/plain X-TMN: [QUFIGP0CYGGqLT/HArcMwTYWrwamejpi] X-ClientProxiedBy: BE1P281CA0050.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10:23::16) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <87ilohzq47.fsf@live.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9f97d229-44f4-48df-1366-08da5af07dec X-MS-TrafficTypeDiagnostic: VI1PR09MB3885:EE_ X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: DiEy+7hx38PbMca++HDt5h0BQrRugbKZxUY499FKCOeO+sksnVseqYK7FJZc9f2Q176zAfNqNj4WsLYoZU4a8Kc3YxgK9oQTyOsQwmrdqK8e6G99UhSm4IpoTGpfWWuG68jFfYFDq5F4eKzyAENoLOuY4V3TwCKEN7uKE9Pk6CrjimfNrnlJoIK5Di0t9QC9l8/iuuvOSWXVUy5lorghpHyBpLUptvM0wLUAmS7v0eoQ52N5h0uogkk8jvPGc62KaCV/tSSOd7SZZe+0gRwqlGHB5ZyewLhnRkFDRapfaJwXkh4xQrVx+5gHhmhJ4ebooRM+2am0JcE9+xZUm+4S7TPgMKNqukHTtnRc5ile8iKVQsh7ZEJ2qjZpGghrKdkYublw5eZ80Z+ir28K9TQoq4atCFpwV2QpWs+sHdT/tvsfplspeaDGllCWQl+ZcD+Ik5SU/TXjOrZMudipv3XuEl1CQ+5gaftt2V0/Z1/DyLHRSJJ3G4RhgwnUcgExTdW0PuUrbkbjmDajyBPiV0NdvOS9yg9u5KZRGE42DGmLOhc9AqnugebJRlujVpBKDArhPdtPMtORFT3FR5Odsfjw+2qx2hOW64RWrNp+2WaBWVuUQ+/6uEXEa8nkHA9siKOxath95ILoIcdL+MCXttIHbPq87Q4c6HVCoUGlDB5NOhBxl/a7yKADZe680qsklPwi/brsYG92cqDHiVeGC639kg== X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?jGxbveRlpCUJsEqbJQcOh9ljX1lGSqZUxtIlKuvVU1+S67/B6j0XSiMXIWab?= =?us-ascii?Q?15RHzJeG+lvs+BQ5P6A47X4yl5ANPuLaGLRSFL9mN3sOS0qRTHlZ9VZDvQNX?= =?us-ascii?Q?Drux+412t314G5H0X9Ws3joqGHalYlMvhtUfVmquBQ/uaqXfGQlaY0FtydrT?= =?us-ascii?Q?C1ob1iH3kFxshDKie8ZmtJW8j21ivm66Rrxgti3dAK2z2rhYdO8Dj3fqMg1C?= =?us-ascii?Q?yAZhZibwaI385vkz8LFZ2JYhEINnBSciqjLf5mmqBwMyRfvDoshlP2t02VTo?= =?us-ascii?Q?Oh6zP72wsw74JsLk4QD3JePIq/sQx92KuEv2JDs+MljkIvQGFYcPFwIw/ksi?= =?us-ascii?Q?4F52As2An+m9o6m4Yk6a9nk6ukNUT/wsBlA34F+EemLWSeNsFypHEMeWwcvm?= =?us-ascii?Q?ekmEZDfP/AMAqenngGTDAKgFkOdxjqfOeNNnXfVevxoO7va5htybptrhh3Rr?= =?us-ascii?Q?qL2J6+cQ4pe0cpCbv59IithaCMFxCD+E0CfTmwnpccqxuF76bSOpaP//ibmf?= =?us-ascii?Q?00Y9q50+VtmSmNhtaeEVELmNb2xlTg8nFGM+jhMyKXolyIuIw5udCeodGM6P?= =?us-ascii?Q?sUOiZOFurVrz06kfaxkN6GI3Ugm2krtsdCvgp2ZgyQCx1x0JWUSbOPJVNPMD?= =?us-ascii?Q?/fTnoqIELTTzaNODH11rdYesKIFLGo6AacJ5Ti4bJprYs21DIKpz7NGthDyK?= =?us-ascii?Q?9AoQ8KGjF5tysD8OeWrFJPKYmnOPDg/z/PCjIG7jpgTk5yk8EhSPWSWedKsk?= =?us-ascii?Q?/nlDOazbUA+RodPm98O9Kja/yIy8CIrws91ZYWnbBmmZ82n+l/vCKxDPEkZO?= =?us-ascii?Q?+WkldZKLSqCrRqtWqDLOlUo9YKNkqgDFfCm2ABktmjDt19pyI9UDZJN0FLy0?= =?us-ascii?Q?pKmYf3S60RtkDge1L14Ut6TiEBRUiiGxXFmcLvu5k96KuQd4ghjABIJ2mlg7?= =?us-ascii?Q?5TAALNnDCK40a8h6F0T1gOnJoYBrdkaD2izUCxRm9fm+qWyVtc42V+wOS+Hn?= =?us-ascii?Q?MvNaW8yCSk/S7lmk6cyH05c4sXJz/NV3jmyeTSE4Xwi4nCmlaY396eV5CGj7?= =?us-ascii?Q?qQoe0GHOK8OdBvZWhwW1B4cXmOcc5MvfS8qRN4qY/nyl3Ou6XkR8c4jSeZno?= =?us-ascii?Q?QMHkSLT9PPAerCaiuF+A4ZOuIGOC1HubF4RgPNYqM26RGH42IKji/jBexUKr?= =?us-ascii?Q?9eU4byV9Z4KgWhcjNg101+734zGopu9tG/E+nj9tP2pnzznPLle1hNU/JL3E?= =?us-ascii?Q?ADEQRZsx3rmzweZl5xAPMf9RPAkedzKt3bBzEZWTng=3D=3D?= X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-64da6.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 9f97d229-44f4-48df-1366-08da5af07dec X-MS-Exchange-CrossTenant-AuthSource: AM9PR09MB4977.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jun 2022 23:30:18.3570 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR09MB3885 Received-SPF: pass client-ip=40.92.70.68; envelope-from=arthur.miller@live.com; helo=EUR03-AM5-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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1656631933; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=I9pJRTG5tZ2YvahFTC6LJ3oEFgAx+tmkOn4GjiCMVEM=; b=V2x4IZ/CjbZ2G8ZBqSu3PGRNdyQREil3+buLl8rlhdlg9Cx9FzK5mHfpo98unqJZEs/M7K UsYzzVI7nD2uc4pBnnzY/a5AnuqyJdIlojSy3X0A04xMoLNd958kCeqCNt0wOz2CS8P9Hn rL8wNA9s65LJCYEZkBeyjVhXKpZWZUgAM3f37XE8GqoVIOosPxSnIp5D5+pnK3/g2hU6XR 6S2d2+m5ZVa13+io6t+/5pnFpDDdZzml2OfTrI1GJcOELpy2xtRT/V/dgxPYFhvB94rP+j VsMiAxezBYK//UF2uckO8bU4/n2HCE0C3k147ctZ3Ou8Q4R1R7av/Z6TaJH3sQ== ARC-Seal: i=2; s=key1; d=yhetil.org; t=1656631933; a=rsa-sha256; cv=pass; b=QwWSwpmY68YVWFmL0s7atbhuuy3a9Fz5VVmuzRCeSFMRfyffmhXtUEDc+NNICTP4Z397Gk iDcwUixpdg/Hd5THX7TRJ7RCduAA07A7IGk3AW55ZuY43IGYwsa2jBAgK9kqAIOLU++KOF aGLw0pHBHsAv25KwOePY8zZrTe6l0+sSuL7RoVUUt+n7UcgV33nu5oJgadoPSMKQQ+FSwe rk850AnDAmzKQDKmhdKVS2X5r1ZY6g0rmcg9wV6Ay5dmQPEjj7spscljTuhrBwtqDb0HJL PSXgX+vV/+DtOouxBZpPR3JvymlVGJCYv+vrkxKRSkB5+m/odw0B9tzmc5UXog== ARC-Authentication-Results: i=2; aspmx1.migadu.com; dkim=pass header.d=live.com header.s=selector1 header.b=CDDA7yVY; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=live.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -10.45 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=live.com header.s=selector1 header.b=CDDA7yVY; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=live.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 640FD3D4C1 X-Spam-Score: -10.45 X-Migadu-Scanner: scn0.migadu.com X-TUID: FFqB+sUfjfKP Max Nikulin writes: > On 26/06/2022 11:50, Arthur Miller wrote: >> Max Nikulin writes: >>> >>> By state I mean some structure opaque to menu package. It just receives it from >>> caller as an optional argument and (when given) later passes it to >>> handler. Maybe it is alien approach in LISP, but in C (where closures are >>> impossible) it is a widely used technique. Functions having callback argument >>> usually have another void* one that is later passed as an argument of the >>> callback function in addition to other data. >> I understand, I have done my share of C, and know what you mean. Say >> posix thread will take a void* to user data, and pass it on. This is >> exactly what this is about. It is just that we don't need an extra >> structure to pass around. We have a menu entry, which *is* the user >> data. > > You a right, it is not strictly necessary that menu should be aware of state. I > expect some helper though, e.g. > > ;;; -*- lexical-binding: t; -*- > (defun org-menu-multiinstance-stateful (menus &rest args) > (let* ((buffer-name (or (plist-get args :buffer-name) > "*Select menu*")) > (state (plist-get args :state)) > (handler (plist-get args :handler)) > (handler-closure > (and handler > state > (lambda (entry &rest _) > (funcall handler entry state))))) > (when state (org-plist-delete args :state)) > (when handler (org-plist-delete args :handler)) > (plist-put args > :buffer-name > (generate-new-buffer-name buffer-name)) > (apply #'org-select > (if handler-closure > (mapcar > (lambda (menu) > (append menu (list :org-select-handler > handler-closure))) > menus) > menus) > args))) > (provide 'org-multimenu) > > To be able to call menu as > > (load (expand-file-name "org-multimenu")) > (org-menu-multiinstance-stateful > `((("1" "one" 1) > ("2" "two" 2))) > :state (format-time-string "%T") > :text "Some heading" > :buffer-name "*Test menu*" > :handler (lambda (entry state) > (org-select-quit) ; it does not kill the buffer > (message "handler %S %S" entry state))) I might be missunderstanding you now, but from this example it seems to me that you see menu entries as something that aims for the menu itself, while state is some user data? The "menu data" here is just: "1" and "one" in the first entry, and simillary "2" and "two" in the second entry. After those, client code can put whatever it desires: ("1" "one" ..... lots of client state .....). So for example client could have something like ("1" "one" 1 (format-time-string "%T")). However that might be tedious to type for each entry, so maybe we could pass an optional "menu-global" state (or entry) that is passed to the user. So it would be: (lambda (entry &optional state) (org-select-quit) ; it does not kill the buffer (message "handler %S %S" entry state))) Reason for optional: I prefer simplicity. I think the idea to lump together menu selection with user state as it is done in org-capture-templates is really good. Kudos to whomever came up with that one! I like it because it puts everything into one place, we don't need to update display and logic separately but everything is in an entry. I think it is good, and I would like to keep that simplicity. I wouldnt like to suddenly separate user state and menu state, because it would negate that fundamental idea. > I do not like how to closures are represented in elisp stack traces > (e.g. JavaScript engines in browsers tries hard to give some debug names for > anonymous functions). It should not be a problem when passed handler is a named > function (not a lambda) despite closure in the adjacent frame. > > However I would expect that menu handler is not aware if menu is implemented > using buffers. From my point of view handler should not have buffer argument. I understand, and I agree it is not very beautiful design :). The problem is when client code provides its own handler. In the beginning I used a flag, org-select-transient, to signal the menu should go away, but that wasn't very clean either. The solution is maybe to never give total control to user handler, but to always wrap/call user handler and finnish in menu's own handler. That way we can use a flag to signal some state. I don't know, just thinking loud at the moment; will have to test. > What I missed in your current implementation is ability to change text of menu > entries in response to action. E.g. "C-c C-e" ox dispatcher has some options and > user should see current values. The buffer text is just dead text; menu entries are a graphical display for the user, not really interactive in the sense that it will update itself upon some user action, unless user picks submenu or returns from one. > E.g. "C-c C-e" ox dispatcher has some options and > user should see current values. Can that be implemented as a submenu (group node as in org-capture-templates)? > P.S. I am sorry for long delay. Don't worry. It was midsummer celebration here and lots of sun so I was out on the beach with the family, not much behind the computer last weekend and entire week. We are expecting rain next week, so I will probably work on it more over the weekend and early next week. I have rebuild it for now, I have removed tripple nesting and incorporated some (most) of Ihors remarks, and removed some ugly iteration for recursion but I am not completely done with everything I wish to do yet. best regards /a