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 CBA0DkdDr2JvxwAAbAwnHQ (envelope-from ) for ; Sun, 19 Jun 2022 17:39:51 +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 IH08DUdDr2LB6AAAG6o9tA (envelope-from ) for ; Sun, 19 Jun 2022 17:39:51 +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 8D4DE3BA30 for ; Sun, 19 Jun 2022 17:39:50 +0200 (CEST) Received: from localhost ([::1]:58994 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o2x1h-0001uo-AY for larch@yhetil.org; Sun, 19 Jun 2022 11:39:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48376) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2x1E-0001uT-Kh for emacs-orgmode@gnu.org; Sun, 19 Jun 2022 11:39:20 -0400 Received: from mail-he1eur04olkn0830.outbound.protection.outlook.com ([2a01:111:f400:fe0d::830]:44454 helo=EUR04-HE1-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 1o2x16-0004Wd-EU for emacs-orgmode@gnu.org; Sun, 19 Jun 2022 11:39:20 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=noBbpQSEsA3t5tQgmSZR7TMmqEFvQrNlj6/7Vg6AwI94JgFbtJZbKK6QQZE9eDT53p9X9OCKzIZkyaP6fJMmvM1jfsqcaVQDkT3JahmSCk+U40Lv0JYKN36Tn79drF4Pj5rlr3wAd9LKCdg5MTqWRn5W0L3+3di0mt8QNacpVgfD5rW/pr8SCRvlAsUdz3qKlDILZ4oiUdhtyXU2ZHJfxJW8ZeIgs79x2ii3KF0cOq115N1XAyczP27KRYpCLcYC6h2SF01JD+oxnY9/va96PPNDTPUvQ+QYDQKaOLFIu1Yviks0GOdvjdbbMZpaiTQodv3stPs9LIEpgZgCCb47kw== 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=7M771UF83r1UuNNmmjx9Lk+2+wqSf5dfzpyTfPY/Nl4=; b=cSY8zPzE4Y5mB0i05WlMy4mJDfyvLMzxQKBeCa20YKu9Oq9vFxhHCx/8a6vBIo52sFHCpQRB9fdsz/sAr8cdhsG9QC3yNj683P7MrvhrvJnfvxiTKvPbyKCgF2ntn8VwrmgMgFr3yI62eowsR4vaM9WFmNBdM3XSrSoySuAzdAqG5ugXfyDx80LgUz6ib/NIQoTJ3mZTeKtQon6o3h0rO/pRqBhunlwbzX+xKckqZgr/CJl7G9tOG03Q8+cj0EBAtrIIe2LBH0Bodj+yD7C/H72BOsHvXXtLtzptqHnjmDOaacfxO4GqkVa+AVzkB/4PpLcu4SUMXInRXLRqlN1PBQ== 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=7M771UF83r1UuNNmmjx9Lk+2+wqSf5dfzpyTfPY/Nl4=; b=XPYsMK9KzRoDS9mGsYq8FkeuiNVMy8fViTKw1f+D4Tv/M0nw1p9ssyfE55zwMwnrSh3j8Rbjxva0c71aKxY+aPzdNmkT2xrmJI3Mc8TTYBoK5Qemk6PNkHcJ7j3pFgvAdcRnNEKa3q0h08DkQq72eXj1D8C5rPlOnXJ66K5G8dwtMHrIgUUuokD4bao81SCCqFL/1GuFMs3urdVpVEFHG1leHKS66RY/bt9CKZj0dQuLXGrbKTM8azBHFQdh8eTJdep4+bBKPM8QXp+pYuLQUTgG3Qd1jTUM0UciEyD76+NmlUcRdzvULntpNcG4bEj9lAUrcyVU1U3ENvM6FnOAwA== Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) by PR2PR09MB3049.eurprd09.prod.outlook.com (2603:10a6:101:23::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.14; Sun, 19 Jun 2022 15:34:07 +0000 Received: from AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::48c7:3657:142f:a842]) by AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::48c7:3657:142f:a842%4]) with mapi id 15.20.5353.021; Sun, 19 Jun 2022 15:34:07 +0000 From: Arthur Miller To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: Proposal: 'executable' org-capture-templaes References: <87mtf3tui1.fsf@localhost> <87pmjyco0x.fsf@localhost> <87fskrobiw.fsf@localhost> <87a6ay1enh.fsf@localhost> <87edzvdb44.fsf@localhost> Date: Sun, 19 Jun 2022 17:34:06 +0200 In-Reply-To: (Max Nikulin's message of "Sun, 19 Jun 2022 17:53:40 +0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Content-Type: text/plain X-TMN: [gUhLKYAkN5lwxs86oz7Tt3ma3Tfs+yVU] X-ClientProxiedBy: PAZP264CA0107.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:1fb::17) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <87k09cmzv5.fsf@live.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5e7a7bc3-9c34-4011-492e-08da520925e8 X-MS-TrafficTypeDiagnostic: PR2PR09MB3049:EE_ X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: dqJMq/hGxZbVwjAWNwuvylyin+u/9oa7nC6NJO1BIotxnarqDOv927+Jv0Pnj3jIzhduqPYy0nWJvdfFxVGrTA66AKrUSFd86fMOPvlK2dnKbYVYc3C48bYBpgCEhXRfQa4ekdvUbjJTG3Bja9tFXCaBHZmre2hZBT5FgcCVN17LfvFHv/g8+72fjvLPvOzVRO7qlAivEIZztZmuOyj58CAOjbbUGgSHpfXTX24UoDp22qBX5GopAT6988Ky4lk8zpDeDpSYMfxL+PAoPPzZrsgjhoTRppWR4UB63gS8JyLF/WJgOhfC+ACFytxxnFz760mKVvFc5OrBt6v/C9bxFhO64lK314udK0Z5warvZEhCVFDF69FdhRbW1IkQ3bVL9ROLxBD48/LYOIVdHqhvuEXcjKcIgRUkVPQzdrG0PKybO2FQP/upQNUM9YGeI3HX/fMPLR3MYQKH+3M5tyWQIkwY3mk+2B7lc7m7JY36Mdw2EYS5srZvnfQBjqcU3PeYlmpjMa0/C43zYUIoLk6pvkzQYvNNPB6UoWqstGzSQbZ1+0yEyy/7IEhUxBPIJxGBaEJmx2frbVNJf3KozcZ6cP/8VWtRNmeKkBMizGBkG+10SghqlD/AMMbzTe6lhSue X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?SKz+58JgLpgeuwBhAPvf3pYU4pAJp0iQPSqCqC42XpNL/5A9nP6iGRSbpPSL?= =?us-ascii?Q?7mkHYTytl21IcZ+XGzVx3b4dYJfmmw3+I2mcmFO6UmjCrWo/Af9qXQtbHrlB?= =?us-ascii?Q?UIPZIJSLvR2ALadXK3gZmNTH5VjY7hiXcjT4mRhWfZy9VJNNRTwSnm97JKch?= =?us-ascii?Q?kUHy06eZtNt6x5lLAcNtSyZfQKr8iBpnh0pAoxH7evkkxsakaxZZ1JDVVde5?= =?us-ascii?Q?YXt35qWRgVh6QRQwzkoAMN/Jt2NGsq+xA4Sk3v1uKJa2hdCkABOiPMy5qYx8?= =?us-ascii?Q?DFuO8qKYhrKvKcfnQ6IebLCUCOtBS3x4mzFFLL8G6UImrtlMW7DzNxIdJd1C?= =?us-ascii?Q?Pclf5s5ZPgLzefNYYHqcXUWo6Srk1rE0TSIHRU37qG7HduVBjs6k4WQvJElh?= =?us-ascii?Q?0lwiTx4AUFovsuMJ691H/SKODUBboitYjAxefYnIMBwO2sfPiWawLLEBBjMv?= =?us-ascii?Q?dOHogSzmPQv84xsJKx66TtsaLuOYLmpIxNAGP5wqzyaodxUurD++Iuqdq8K4?= =?us-ascii?Q?76mnyN8nn6fyZ9l597kHpOjngIAyK5iPVyJaAo9LythhBiDmdl4UarYBu44l?= =?us-ascii?Q?QJvsPGrfJNy6XSUCPdYdJDrcaGEtQffCh6uOzYVP7AcRTaDpmbCU4hdTu/EV?= =?us-ascii?Q?864V/dYG0MZbqIZbSb5PonxMN+zUgDxSjpw41KvbosvgQuMFDZw3vcF3TAuX?= =?us-ascii?Q?yDaF5U8P37eUETRwCMChbTPY3A/nKyEpcjbHc7n6BqiB1DFUdPWtFndb8CdI?= =?us-ascii?Q?Z+geadFX9H9+C3suAbO8Sy1ClqO2y2Cut4vqZiHR/zZbeNiREiifLfexzmPn?= =?us-ascii?Q?CnO8rLnmZqPva8vxCkD/BrG3KFX1Abrmn+AGFYAl90TelZMhvN6wN791HWzw?= =?us-ascii?Q?kCIcL0QKBsfRCwHNuKCHUs2iiPt7VfQ8s+TaJCLjWj6HnrqiyVXAlKbbJpIb?= =?us-ascii?Q?0VgTqL5l6fetTCF1uwMq+J2kBzVTnGXUoFEzt3rq5QzfFgAurfQUq6C5GS5H?= =?us-ascii?Q?xkbLLVrPec2NH8WaEUXhGyHu1S1GS61e/0o6pFu5AimydaNOKfHHYtnGCjDu?= =?us-ascii?Q?dSWqV3rSa6yJjNLSSpmKsz0sYSVGLqNoKLid6whBuaw400s1wIjbErCrBK/V?= =?us-ascii?Q?eXyU6tftRmT2Y7TXi/urAjEGLcZB9jWml8t8LhjwnMPaiTlcl3fql2pQRxSu?= =?us-ascii?Q?3+ADXkskie3oXQU/WdPBoppJX9TLeHEAM7QduPekBceAWZSBwgv+foSV+uhD?= =?us-ascii?Q?IKk6dItnO2bSA8nJqH4Kjzuh5DDm/cxxwZ7esc3TtvOFhRnFybql9e8pusk1?= =?us-ascii?Q?KxH5Y6WH7vEqdFk371YGMQvpKXEBYYLf/OVRCTxettDR71YDKI2EDdG7rtp4?= =?us-ascii?Q?urkxomZJ5HbroDvUnLwku5lqGTMGxXWd5D7jE/EuxA/NXwl9jsNiS2OPT8Pm?= =?us-ascii?Q?eOwWwm1+ZFI=3D?= X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-64da6.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 5e7a7bc3-9c34-4011-492e-08da520925e8 X-MS-Exchange-CrossTenant-AuthSource: AM9PR09MB4977.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jun 2022 15:34:07.4258 (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: PR2PR09MB3049 Received-SPF: pass client-ip=2a01:111:f400:fe0d::830; envelope-from=arthur.miller@live.com; helo=EUR04-HE1-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, 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=1655653190; 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=7M771UF83r1UuNNmmjx9Lk+2+wqSf5dfzpyTfPY/Nl4=; b=kJB6gLn91k5YMsq8vDCuU5C98qdW5gw7Ueza0AYs97Yg3ZO+wlpG+AYcqDVVmPBph+aMuj BJ5ya78apiiLJyggZbhIf0Lcg6wKXe1K6/lNcHmjSh+QEqc4Ghs128FY8eaXhEJ/mZ9iwS tM/al+5pYEXT/bNIYje8ATPKil8uV3Wh+aOf4j5iwCW9WosLht8H+kazL734UqJrhaL8sj phsHxwlWUOdK+RF47O2DWdSxOIN6ToRunCWnoWSf+H7LxdzAdWF5UTbm453zwGPdSZh8Cb FTrFRXA0cTEY+mZ5g3V6rzhX/cSLVMJo5g7xUlftycyOXjMz9BLqh0Xdx/rTLg== ARC-Seal: i=2; s=key1; d=yhetil.org; t=1655653190; a=rsa-sha256; cv=pass; b=db/zVtNJRQtVEAZSSIIeJr5dY0QHyw4iuTzSWw+euH1clwTBBSyRdxXU5NQIvNdVPmaa5f /J40WotToC4CquqLdvV14iQQA18KtZWDfN9O7nWukr7LHEaoC7XoXSLkQVPoACZyWysTC0 fXenFLVUg6/tqHhvsWHvTFs8ernhExbkCiubu6Ial4/Mqg/YlTXBOEPuGcqIVCw1oqSSls yjIyT01qOsy15g8QMM98MGu3OSQId1rO6h8kB4P7uvigagWfTD4J1ZANL4FwwHXwzo9L0R PVvVrrey31hr1c1JSk0XjQNYfeDSq5Z8bfR6GhiKzAkJ6ZosYgSxR4zcmnuLbQ== ARC-Authentication-Results: i=2; aspmx1.migadu.com; dkim=pass header.d=live.com header.s=selector1 header.b=XPYsMK9K; 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: -5.78 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=live.com header.s=selector1 header.b=XPYsMK9K; 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: 8D4DE3BA30 X-Spam-Score: -5.78 X-Migadu-Scanner: scn0.migadu.com X-TUID: xNae00ZXhYwp Max Nikulin writes: > On 18/06/2022 22:05, Arthur Miller wrote: >> Max Nikulin writes: >>> On 11/06/2022 12:26, Ihor Radchenko wrote: >>>> Max Nikulin writes: >>>> >>>>> Imagine what would happen if Emacs decided to show several capture menus >>>>> with keymap non-blocking interface in different virtual desktops. >> Different Emacs processes, or just different Emacs frames? > > I mean single Emacs process perhaps with multiple frames spread over monitors > and virtual desktops. I am unsure if Emacs can create windows for different X11 > displays, but let's leave it aside and inter-process file locks as well. Allright then; in that case what Ihor suggests, a variable somewhere, should do. I suggest that variable be the capture buffer itself. I'll try to implement this in a day or two; just need some time from other things in life. >> In case of different Emacs processes, there is no way to guarantee consistence >> unless one locks file in the file system. Windows can do it, I am not sure what >> is Linux API to do this, don't know if Emacs exposes this functionality, have >> never tried. >> Otherewise, if it is only different Emacs frames/clients, the capture should >> always find the capture buffer and return that one instead of creating new >> ones. That way there is only one capture buffer, so multiple captures should not >> be possible, i.el, it creates same effect as locking the input to minibuffer. I >> am not sure how org-capture does, I haven't studied the code in-depth yet, but >> what I see currently a user cancels it with C-c C-k. org-capture buffer could >> setup hooks to clean everything, even if user kills buffer by other means, c-x >> k, or whatever. It maybe already does, as said I haven't looked at those >> details. > > Arthur, be reasonably skeptical concerning my ideas or suggestions, it seems I > have not managed to convince e.g. Ihor. :-). I think this would be quite a big and radical change in some important parts of Org, so I really want to make sure that a fundamental error does not happen. It would be a horrible thing if someones file with maybe lots of data from the past gets messed up. That must not happen, so I really value the input and would like to make sure use cases we have to take care of. > I believe, multiple capture menus should be possible in parallel even within > single frame since it may contain several windows and user experience should be > better than now. Keymap-based selection opens a road in this direction since > menu may be non-modal, but it requires a bit different design. That sounds like a new feature. You are correct, keymaps do open in that direction. That would be possible to tuck on the routine that saves the temporary buffer (whatever is called with C-c C-c). When user press C-c C-c in a capture buffer, that is the only time when interaction with real a file on the disk happends, right? Everythign else is done in a temporary buffer in ram. User can physically press it only in one capture buffer, so it least in theory, multiple capture shouldn't be impossible or too hard to implement. But, lets do it after the rework of the menu thing? > Waiting for return value to get capture template is not possible any more. A > kind of continuations should be passed to the function creating menu buffer > instead. E.g. it can be some state object that stores snapshot of data necessary > to fill capture template, export options, etc. and functions in menu entries > that accept this state object as argument or obtain it from a dynamic > variable. The state object likely should be a buffer-local variable. For > non-blocking menu, entries should contain callbacks or menu may have single > callback that is able to process static data from menu entries. I happened to send the code yesterday by misstake only to one participant, unfortunately, it wasn't ment; I seem to have pressed S w instead of S W and wasn't looking at the address on top, so unfortunately you probably haven't seen the code. However I have to rework it again because I did a bit bad design in handling of one feature; I'll try to do it tomorrow. However the idea is that the selection menu framework have no idea who is calling it and why. It can not possibly know that either. It is entirely up to the caller, so for that reason a caller can setup a handler that gets entire template passed back and can do what it wants with it. Current org-mks & Co don't really know who is calling than and why, but locking happens automatically due to nature how the input is read (via minibuffer). In case of new menu handling, the client has to do locking on its own, so it is a bit more extra, but client can just buffer-get-create to get an existing buffer before calling org-select, so it shouldn't be too much of the work. I think. I'll test tomorrow or so. > As a result, capture can not be processed till filling of a template (and so > till adding it to the target buffer) within a single function. Instead first > function prepares set of callbacks and renders a buffer with menu. When user > activates a menu entry, a callback either just modifies the state object to > change some option or starts some action (fills capture template and inserts > result to the target document) and notifies caller that the menu should be > destroyed. E.g. if some special symbol is returned from the menu entry callback > than it means change of some option, so menu should be retained, otherwise it is > action and the menu buffer is not necessary any more. I have used a property 'transient' to flag that menu should be destroyed, and I have done that before a handler is called, in osl--do-entry. But I it is a bad thing. I came up with a different plan yesterday, and I will rework the meaning of "transient" property there (btw if you have better word to skip confusion with transient.el please suggest). The idea is to have something like this: (defun org-capture--handler (entry &optional menu-buffer) When a menu buffer is marked as "transient", it means that a client will take ownership of the menu buffer and will can do whichever it prefer: keep it alive or destroy it; in most cases destry it by reusing it, as in example of org-capture where current code seems to recreate capture buffer in same buffer. > So despite I earlier opposed to executable menu entries, they are quite natural > way to implement non-blocking menu. State object specific to menu instance > should be added in some way convenient for developers. Current proposition is meant to be backwards compatible with org-capture, so it has to work with org-capture-templates modell of state. Means a list of form (key label ....) Sometimes it is not even a proper plist, but anyway, it is a list, i.e. a state carrier. So IMO menu "framework" itself is just a presentation of choices to a user. Hanlder is the logic, so I don't think menu framwork should do too much here; just present choices to a user, and pass the choice to the handler. There is default handler (defun osl--default-handler-fn (entry) "Try to execute form found in ENTRY if any." (let* ((form (nth 2 entry)) (message (cond ((commandp form) (call-interactively form)) ((functionp form) (apply form (cddr entry))) (t (eval form))))) (if (stringp message) message))) (I have to rework, that is the one from yesterday ) That can cover lots of simple cases, so most use-cases don't need to write handler in one-shot actions, (even org-agenda seems to work with this scenario), but more advanced uses should give a handler and deal with the state in hanlder. > More work may be necessary however to make org-capture really convenient and > reliable. Capture menu should display some summary of captured data otherwise it > is impossible to decide which template should be chosen in the case of several > simultaneous capture buffers. It is better to save capture data somewhere on > disk while while menu is displayed to recover it after a crash. See the comment about new feature above; I think that covers same issue. Sure temporary file might be something, but that would be more work. Lets leave it out for the particular moment, and come to it later. >> I agree with you that completing read is a good alternative, but it is a >> bit like discussion about GUI vs. terminal. I am personally heavy user >> of Helm, but not everyone is I believe. > > I mentioned completing-read because I consider it as a test of API quality. It > should be possible to plug alternative menu implementation and completing read > may be a simple enough variant. It is blocking, but in the case of capture "push > to capture queue" could be used to postpone the action. I don't think it matters there that completing read is blocking. Users do completing read just to pick one action to get executed. I don't think I understand how qeue of captures to do would work, to be honest. > P.S. Notice text properties for entries in the following modal menu: > Timothy to emacs-orgmode. [PATCH] New remote resource download policy. Sun, 12 > Jun 2022 22:43:07 +0800. https://list.orgmode.org/87mteiq6ou.fsf@gmail.com I am not sure what do you bring that cod up? I looked at the link, but I just see text styling with faces. Do you mean to use text properties to communicate the state? Sure text properties can be used for different things, but already have "template" (a list) we are passing around. Isn't it sufficient as a state carrier. You can push/pop things off of it to communicate whatever. Forgive me if I don't understand what you meant there. best regards /a