From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id 4LOXM6josWLRdwAAbAwnHQ (envelope-from ) for ; Tue, 21 Jun 2022 17:50:00 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id kH+UM6josWKAKAAA9RJhRA (envelope-from ) for ; Tue, 21 Jun 2022 17:50:00 +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 A2C2913560 for ; Tue, 21 Jun 2022 17:50:00 +0200 (CEST) Received: from localhost ([::1]:45836 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o3g8d-0000ph-Kv for larch@yhetil.org; Tue, 21 Jun 2022 11:49:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37422) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3g7V-0000of-I9 for emacs-orgmode@gnu.org; Tue, 21 Jun 2022 11:48:50 -0400 Received: from ciao.gmane.io ([116.202.254.214]:58554) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3g7U-00023x-1J for emacs-orgmode@gnu.org; Tue, 21 Jun 2022 11:48:49 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1o3g7R-0001G6-0g for emacs-orgmode@gnu.org; Tue, 21 Jun 2022 17:48:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: Proposal: 'executable' org-capture-templaes Date: Tue, 21 Jun 2022 22:48:18 +0700 Message-ID: References: <87mtf3tui1.fsf@localhost> <87pmjyco0x.fsf@localhost> <87fskrobiw.fsf@localhost> <87a6ay1enh.fsf@localhost> <87edzvdb44.fsf@localhost> <878rpu5qf4.fsf@localhost> <87zgi7357y.fsf@localhost> <875ykuslpx.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Content-Language: en-US In-Reply-To: <875ykuslpx.fsf@localhost> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 28 X-Spam_score: 2.8 X-Spam_bar: ++ X-Spam_report: (2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1655826600; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=QcNsr1Q1fQFbvDipu+1dZAQCz4pVbXOiI5d9hffZaig=; b=e1YO/hVDBQIELUnUma3Dhx4J38T7E1qF6+T34g6xJgP8N8YChAP6c7xc/9Nd4PvI4nQznx 287eVQ8/7rLAxiVw1X9G77uD6XA2icxM59Mt44K1XJe2KEvjmgww54f61NqvQee3zljHbs fEOgdWbxCEA9258jfOojm1bZoPOIPgQzC1nusAgpddooQHYPPHbOFr7iJovRuKv5kmlSpy J8sclM/FYrSlSgsOuEpVVpK/Vj9i88/88YJj9Y9rNerVmw8VDS0uDRA3ZKKx9jly9SgK0k eEZ+G8xhSmJcSS8gCpWLAgEqHxDNkjmh5c7i4VZ4od2YAbyEiUYy5UTUwVOv3Q== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1655826600; a=rsa-sha256; cv=none; b=sRXIxJ3bWVUdn0DJgqCfqAaeBywAtTq6y6Mnq6SbCLdSltApTHgsUdSkQBkwMpci+/arX2 CP8VbztTay2Lk1k+OS7lRtOP4RcFOf5Bz8bMd4IF7/uxj9vFucDgp+VX4j5DpNVfjvQvcT 5MLwUC9po0KPjym1QBbb/7ipL2AHzuw/dFbcJJWptw60V3dyfWOZ5OXKyfTtYZ6vbDsxTj XkdnZqHhEI6YX1dpHY1aWqS64MoQEIo2b13DnBb3VmOb5rKuLMjUV3rroyKZe85A2LlWsN Hz9Pm+hqiZeKmQS0kc9q6MEZQge/14kq53gwm5jTYx7lzAOqLWTR60DXJFsCvA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); 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: 3.73 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); 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: A2C2913560 X-Spam-Score: 3.73 X-Migadu-Scanner: scn0.migadu.com X-TUID: nFmfitaPvFHA On 21/06/2022 11:07, Ihor Radchenko wrote: > Max Nikulin writes: > > The other question is altering the org-capture code. > I think that it is too early to discuss org-capture part just yet. > Lets first finalize the generic library itself and discuss the > appropriate adjustments to > org-capture/org-agenda/org-export/org-todo/etc code later. From my point of view changing menu without adjusting calling logic is a kind of trade-off with uncertain net result. New UI may significantly affect different user expectations. It seems this is the point of our disagreement. You tend to consider menu in isolation trying to postpone the question concerning interaction of code running before menu creation and handlers of menu items (they are not belong to the same call stack any more). What I am really afraid is words like: > Sure. That somewhere can be buffer-local variable inside the capture > menu buffer. Or global variable. Or closure. How is it relevant to the > capture menu? I am trying to avoid implementation of menu that would make passing state to handlers unreliable or prohibitively complicated. Global variables are certainly not an option because such approach does not allow several instances of menu created in parallel. To use buffer-local variables some support from the side of menu library is required. Buffer does not exist when menu function is called. So either some callback should be passed to menu to be invoked when a new buffer is created for menu or that buffer should be returned from the menu creating function. Unsure if (current-buffer) would be a reliable approach. Closures should work, but would be it convenient enough? Maybe some intermediate layer should be introduced to make alternative implementation of menu (transient, completing read, etc.) easier. I believe, discussing design of menu without evaluation if it is suitable to features that should use it (capture, agenda, etc.), there is a risk to create unreasonable restrictions on further steps. That is why I consider the following aspects of menu design as essential ones: - A clearly determined way to pass some state from a function that requests creation of menu to handlers of menu items. - When a non-blocking technique to wait user decision is used, multiple instances of the same menu should be allowed. - Defined extension points for alternative implementations to avoid code duplication and divergence of behavior. My fear is that if such points are ignored in the beginning, it may become impossible later.