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 sPwCD3qtsGKxEQEAbAwnHQ (envelope-from ) for ; Mon, 20 Jun 2022 19:25: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 cB4TDnqtsGLaRAEAG6o9tA (envelope-from ) for ; Mon, 20 Jun 2022 19:25:14 +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 B90BB2D611 for ; Mon, 20 Jun 2022 19:25:13 +0200 (CEST) Received: from localhost ([::1]:40550 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o3L9E-0008T3-3v for larch@yhetil.org; Mon, 20 Jun 2022 13:25:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36518) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3L8e-0008Rb-7e for emacs-orgmode@gnu.org; Mon, 20 Jun 2022 13:24:36 -0400 Received: from ciao.gmane.io ([116.202.254.214]:45312) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3L8c-0005X8-Ss for emacs-orgmode@gnu.org; Mon, 20 Jun 2022 13:24:35 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1o3L8a-0007ZE-Tn for emacs-orgmode@gnu.org; Mon, 20 Jun 2022 19:24:32 +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 00:24:26 +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> 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: <87zgi7357y.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=1655745914; 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=GQKLYgGY9H/PbtcI8OBGcfZqswKgIOrDWOJwbeOcU+o=; b=GD2LYQUKfvzkd2Std+VbyoXYc8yCEcJDIAIAT+GTioZVPZaeUjc+cbPmYvAVW+GB8vWiWu aPyPT4P9SXUIcWH5NMUlZGJcs0RoPyeVZD8HgaYPEgnziFUabpAo5PhiIiIVfdZVpUQf/V XfX5AiiF6g3CVmaXluCphKXs9La2LWJy470f7afy/0hxGSL7w9QVZYlskSfPVXmW4h9xmP 6HguSgPgfhSRLZvDe0+RX5Afj+5B/H8BlqDpZ6lqKlL3Y4LzUpl5269K3lyz9TpLgfLh1b zFXuhKyEcwGwswyD+pY040wdC4KDhFzJx9MVJtDWYash+3Mes1f1plxrC4zPmQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1655745914; a=rsa-sha256; cv=none; b=I6xdy0u6Xz6cN+hz4IKMHANDyB1x65gO8rnnOr+LL9oryTwx7TI6+KbwiTBmddlblh0OQL abvMtPqv4RbCevIXL+NjWlRbA7JKkJLvnzJXPwoGPeWa3Fh0oOfczxBR9g2G5UYFLdiufZ /WJsKfz0kraJY6mLlIk39DsVFUyFU42kPzJV8B8qUKCbmszPnQMfB8m+gjGqRr0cqp8ysY eacX4X96/+L7G4cxqP+9wA/QdoSFRuDAPQ3Gqq1ub2HeYXv0JyyJ4EeX2C2GsQ59eSd5i/ mCeROqvMIWdJDDBdbDkJwdtJwbyIMzw73kxIIAzYlRYFbOwe5LeTJSw2T1ZRow== 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: B90BB2D611 X-Spam-Score: 3.73 X-Migadu-Scanner: scn0.migadu.com X-TUID: qPjoKv8p9zzf On 20/06/2022 19:10, Ihor Radchenko wrote: > Max Nikulin writes: > > Sure. I was hinting about such functionality in the new library we are > discussing. Multiple capture menus are not possible now anyway, so it > will be a new feature if we decide that we need it (I am not 100% sure > if having multiple menus is not going to be confusing). In my opinion application logic should be consistent with UI. Do you think current behavior of help buffers has no problems? If so I have no chance to convince you that upgrade of menu should be accompanied by changes in org-capture. Consider the following case. A user has 2 virtual desktops dedicated to rather independent tasks and an Emacs frame on each desktop. On desktop 1 she opens help for some function with aim to evaluate if it is appropriate for some particular purpose. Next she has to switch to another task and applications for it reside on virtual desktop 2. To proceed further she has to read several help pages relevant for task 2. After completion of this task it is time to resume task 1 and to switch to virtual desktop 1. Does a window with the help buffer still display the same content as before switching to task 2? No, context on desktop 1 lost due to some actions in the Emacs frame on desktop 2. Such synchronization is against multitasking and I do not like the idea to get it for org-capture as well. Currently read-key and modal prompt is a kind of excuse, but the idea of new menu library is non-blocking keymap-based selection. >> Currently several capture menu instances may be requested though >> org-protocol (or calling org-capture from emacsclient). The behavior is >> rather confusing. New menu may help to fix the issue, that is why I >> raised the question about parallel captures. > > I am not sure which behavior you have in mind. try the following commands without selecting a template in an Emacs frame in between emacsclient 'org-protocol:/capture?url=url-A&title=title-A&body=body=A' emacsclient 'org-protocol:/capture?url=url-B&title=title-B&body=body=B' > What I was thinking as a conservative implementation that would not > introduce any new features is replacing the old menu with the new one > every time the same menu is called. So, every time the user calls menu > (e.g. capture menu), only the last capture environment is preserved. The > previous, potentially unfinished, capture menus will be destroyed. Causing loss of user data. Currently it is hard to start new capture before selecting a template.