From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id KAD8EkwZv2KnTwEAbAwnHQ (envelope-from ) for ; Fri, 01 Jul 2022 17:57:00 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id +Le1EkwZv2LX7wAAauVa8A (envelope-from ) for ; Fri, 01 Jul 2022 17:57: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 12802384EC for ; Fri, 1 Jul 2022 17:57:00 +0200 (CEST) Received: from localhost ([::1]:48254 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o7J0t-0002zr-7O for larch@yhetil.org; Fri, 01 Jul 2022 11:56:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39516) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o7IxR-0000sI-8f for emacs-orgmode@gnu.org; Fri, 01 Jul 2022 11:53:25 -0400 Received: from ciao.gmane.io ([116.202.254.214]:59986) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o7IxG-0006gy-GW for emacs-orgmode@gnu.org; Fri, 01 Jul 2022 11:53:24 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1o7IxD-0005QJ-E2 for emacs-orgmode@gnu.org; Fri, 01 Jul 2022 17:53:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: Proposal: 'executable' org-capture-templates Date: Fri, 1 Jul 2022 22:53:06 +0700 Message-ID: References: <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: 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=1656691020; 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=n4PPdxoCn5tzehzoDEndQr1HqiY2cDPj0szikQrWNoc=; b=FBWw9rRZnGHAH214U3mqv/DN3fhOBgLqweTk18dFMhcKGwElVkZ8x6a3jswC4pdOThR1kd R58EW3nvnPssX5elwvSdlbqAtOaDy8DXaDALQVcGqkDtm+uEWkZ9YU2zMyvjuzXH1WVfNt VrPJIGTVBWjuVZj53qi11OjgVtGrgX1HzNUZPIhQt6gGjrX3jrWnNoNcGyY4a1lwxW3w29 x9UC8UZzBNEFP/mz4neCsN23HO70DKhDnw3FUwzMLn/c74N2vFkLIjKHCJvTOLMAXOacYn us90hrQgv6giDNRbYn2dzfzR4Hnl+fM8Z3C/80slJ9X3QRmFhmeBBdoG/All2Q== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1656691020; a=rsa-sha256; cv=none; b=jy7PphA9WN8IQJn/OW/+YmtFHEq9LLA4aBvybNz8Xy0ckIrwhcdrxrTPrBZlEo10kFdmn7 0SQP6zburT5MIr6cpF2asLckSZuIzBmMk3x7bm7NENXp+mYt4STgSCOwxzEjGQiIvjCGQC +fjoe1iRReAnzcNT6YWTm5R1BaIlV+zC2TzKOYERSlfffeGOqReRb++eg0nbB/vcIp8yhP SPX3tIzYf6oqn1dr7W3klrslQgtT1fJtQeg9iT2vF+bEZSyNctYDDsECw+lV7bZhssqN+q jViaulf0BxYCJ7NdpC4VkPqOPc2tdHIGw7uGlz6m4sqW1a7y7YCYb0gZAcOL9Q== 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: 2.25 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: 12802384EC X-Spam-Score: 2.25 X-Migadu-Scanner: scn0.migadu.com X-TUID: SuNKleAcwmqY On 01/07/2022 06:30, Arthur Miller wrote: > Max Nikulin writes: >> >> (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? I am feeling myself confused now. It seems you have got the idea mostly right, but I suspect some resistance though. For org-capture there are menu entries data in `org-capture-templates' that is the same set of rules (how to expand templates where to store result) for all instances of menu. I do not see any point to make each entry an executable closure. State specific to each menu instance consists from the following parts: - requested action (prefix argument: goto target location, insert at point) - data required to expand template when it is selected, namely `org-overriding-default-time', `org-capture-initial' and maybe something else. Template properties and capture data are quite orthogonal and for me it is rather natural to keep them independently. I would prefer to have support of state at low level, but it can be added on the top of basic functions through a closure. In a different use case, when menu is just a collection of independent actions, there is no point in the state shared by all entries of the menu instance. >> 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. There are two types of actionable menu entries: 1. Ones that modify the state associated with menu instance without real action. Currently they are e.g. toggles like body only or complete document with headers for the export dispatcher. Menu should be retained when such action is called. 2. Entries that call real action. In the case of export dispatcher or `org-capture' menu buffer should be destroyed before a new one to display export result or expanded template is created or selected. So generally it is not possible to determine in advance if menu should be "closed" before calling its handler. It is too late to close menu when the handler returns some value. I considered a predicate function that accepts menu entry data and the state and returns decision if menu should be retained. Looking into your implementation I realized that `org-select-quit' is almost ready to be a better solution. If the handler just changes the state then it does not call the quit function. Actions must invoke `org-select-quit' to notify menu implementation that the instance may (or must) be destroyed. The only problem is currently with multi-instance menu. Buffer is not destroyed by this function. Despite it is possible to kill the buffer since it is passed as an argument, I would prefer to delegate this action to `org-select-quit', so menu caller becomes completely unaware if menu implementation uses buffers or something else. There are may be a convenience keyword argument that adds call of `org-select-quit' before invoking a handler. It should be handy for simple menu with no options that can be changed before calling an action. > The buffer text is just dead text; It is unfortunate, I hope, you will reconsider it. >> 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)? I suppose, it is necessary to provide some visual feedback, so it is obvious to user that some options is changed (e.g. "C-b" for "C-c C-e" export). It may be a kind of always visible status line, however in some cases it is better to display option value close to its menu entry. In a minimal variant there may be a function to set status line and menu keeps a pair of markers, so text between them are erased and new status is inserted when the function is called. In the beginning I was afraid that menu instance state may become a serious problem with implementation you proposed. Actually it appeared to be a matter of convenience. Entry-dependent behavior (if menu should be kept or closed) would benefit from some polishing. Presenting to the user changes in menu state in response to their actions should be addressed somehow.