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 BLZ5FfwNwWLS+gAAbAwnHQ (envelope-from ) for ; Sun, 03 Jul 2022 05:33:16 +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 uOhyFPwNwWIfVgEAauVa8A (envelope-from ) for ; Sun, 03 Jul 2022 05:33:16 +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 046E7394CE for ; Sun, 3 Jul 2022 05:33:15 +0200 (CEST) Received: from localhost ([::1]:50518 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o7qMD-0004md-Bc for larch@yhetil.org; Sat, 02 Jul 2022 23:33:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43586) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o7qLX-0004mV-GI for emacs-orgmode@gnu.org; Sat, 02 Jul 2022 23:32:31 -0400 Received: from ciao.gmane.io ([116.202.254.214]:44590) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o7qLT-0004ks-9c for emacs-orgmode@gnu.org; Sat, 02 Jul 2022 23:32:31 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1o7qLR-0003Cx-4u for emacs-orgmode@gnu.org; Sun, 03 Jul 2022 05:32:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: Proposal: 'executable' org-capture-templaes Date: Sun, 3 Jul 2022 10:32:16 +0700 Message-ID: References: <87pmjyco0x.fsf@localhost> <87fskrobiw.fsf@localhost> <87a6ay1enh.fsf@localhost> <87edzvdb44.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=1656819195; 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=bqwSxFo4ZcJ9QR4DeK86dnEDw0o0LPi5P+yGULNY1xE=; b=PXV5j/vdgoQb9gck0mmwngMmEm6c0I5WTXdJThvcYONEVjtWwM6g8wb1pVfGxHZgo4Vlj9 Hew++p6g6KTHH0i1vGdYuA+CU5fyDqqNghmJFbYwnx07TqVU5NWMiHOJH6txP5bIeDkWeo woCYnsLOBzcAFUAj/dLyrrGPCS1AQxSPLBsOfvQerDmFKzfG3RBnXYrQXoUJsumdpqfSbG OUWPY/VA7kl+AmZno/Daqfn0Co3picMS0/Id6Iou3AEaltQdyk9oST8lKOgV2VNnbe6ctu gYxMAh2mUhu0Esne/z8LU/KZls9CJaFDgcwC9Wv1A7gFcw228Oqr3CSZJxVlxA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1656819195; a=rsa-sha256; cv=none; b=BBAWuWfpCFLxh2k1nQ7Vaj84yQIhZP7vOyQRsxxXnIeAKUXYqX9jtxmFD4DdgtBamISqR4 kSrE/In20zn53PocriinGH9UiKnLnZwA7z4cddR3uNI8OeO9LVH10lIQ5bTZWJWLZE5HEV mHf2WyNciKpWnYeI1QezNzZEYm01xNmWmo44MskbDb/I2DQSILyHZLSaur+l3WsP06+txj VBr2/vUBrPhyjsbolZ1WOzKgAsGFsbI4VyYu6Ow5eCmPy4Mlpg1CsJLJL9nYuVHnmLvWuM DeWdi5KjjXIryNWyO6SPFvxnNJwOZCvVHJwIAZDpjZv972mq9OiuMJ2OdbHfqw== 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.75 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: 046E7394CE X-Spam-Score: 3.75 X-Migadu-Scanner: scn0.migadu.com X-TUID: +GgBj6dbIYya On 19/06/2022 22:34, Arthur Miller wrote: > Max Nikulin writes: >> 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? I am going through older messages trying to find possible sources of different assumptions. I am at least partially repeating myself, but I consider this point as an important one. When a capture template is selected, `org-capture-fill-template' adds capture text to the proper heading of the target document. Capture windows display narrowed down buffers of target documents. Disk operations happen on C-c C-s hit by user (it can be done for a capture buffer as well) or on autosave timer. Aborting capture by C-c C-k reverts the change by erasing earlier added text from the target document. It is safe to have multiple capture buffers, but some amount of work is required to make parallel menu buffers straightforward. >> 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. It is related to code calling menu rather than implementation of menu. It is a way to improve handling of parallel capture template selection menus even with `org-mks'. Certainly I expect that new menu library will not add any new obstacles. Assume a modal template selection is configured, e.g. based on completing read and such "menu" is currently active. The user may switch to another application and request new capture through "org-protocol:" URI. The best way to handle such case from my point of view is to detect that the menu is active, collect values necessary to expand template and put this capture state to some queue. As soon as the user selects template for the capture started earlier, next state is popped from the queue and next template selection prompt is activated. >> 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. At that moment I considered it as a feature request to add text properties to keys displayed in the menu. Later I realized that it is not a problem even for `org-mks' since strings with keys may be propertized in advance. It is unrelated to user state, but the patch adds another implementation of menu. I hope that it will be possible to avoid dedicated menu code for this particular query and rely on org-select your proposed. Timothy wrote that a reason for custom menu was modal nature of `org-mks', so it would made impossible to inspect the document before decision if a remote URL should be allowed. org-select should relieve this limitation.