From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 UBqQBWIAr2JhrAAAbAwnHQ (envelope-from ) for ; Sun, 19 Jun 2022 12:54:26 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id uHSMBWIAr2IhKAEA9RJhRA (envelope-from ) for ; Sun, 19 Jun 2022 12:54:26 +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 9E4B233E3C for ; Sun, 19 Jun 2022 12:54:25 +0200 (CEST) Received: from localhost ([::1]:55176 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o2sZU-00079T-Fi for larch@yhetil.org; Sun, 19 Jun 2022 06:54:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60666) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2sZ5-00079L-AZ for emacs-orgmode@gnu.org; Sun, 19 Jun 2022 06:53:59 -0400 Received: from ciao.gmane.io ([116.202.254.214]:42926) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o2sYw-0000kY-SG for emacs-orgmode@gnu.org; Sun, 19 Jun 2022 06:53:56 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1o2sYt-0007GU-OG for emacs-orgmode@gnu.org; Sun, 19 Jun 2022 12:53:47 +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, 19 Jun 2022 17:53:40 +0700 Message-ID: References: <87mtf3tui1.fsf@localhost> <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_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=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=1655636065; 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=ytGSB58OXLTN4Ko2U2vkl/DD4IwWAQNkNWbuiESPBGo=; b=P3VOHYu/1o5EhSW4BWnWU5x+F57SUDYxIITTFDubKT7W/Aw1JdM0sBNWH+fXtB3fbMnQDh 0w5jz6X3dYQXtNmXiYwUJnMHlngdXlqUdgzcQytHekELLgiBhE1sC800y0g1I7VJEvUub5 PBEzqEOTrY4KynO8ptGn3xYuTpJgsOrDPC7CEMFyLwQJbgUcYX/WXrBcPKuBYbgDHOYKdh JKnI+fpn4T7q0KE2bObc6Zu//pUnk2QrqfaN7M1Wb8o5ERrwyde5KP0+rNkCJZxSU4AqIM uD7sC0td8RWqZv/ozxxtAep4Nr+zL3vdYQzI+cmcgqp9u1frO9UF7xRRfT4pfw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1655636065; a=rsa-sha256; cv=none; b=PIFTwbkj3jnLjY5w6XyA/2BAGx6bF2BC5vubn+lckEhGeqcYtRzt6/cjkFigIwjFTBO1k/ 6xtjlCNbu/onIs5BVDxcTkMntnPN1jVZ497uKO3BSwlxgZ8blJgHYyYlt9vxXdKuApNtCl GdzKUGL1Mf+zuNZ3O87D0B4KVdxqzR3Jb7p72x9eX+xV2lE1ZhmgUOArfhIjXe3RQdaIfF HJqx2me1t7jQYjXF9zul3JInbqgx30ck22w3uCgKDtKOzXf/YjGK2HKxQ1ITGTxrv2iczZ /ubox2RFGcbULZkJJ1HvJNcI5X8MM9YtyM6iqJnOuO/XBFgwRMU8HjP0qRil3g== 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.11 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: 9E4B233E3C X-Spam-Score: 3.11 X-Migadu-Scanner: scn0.migadu.com X-TUID: pP1H5tLmGtee 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. > 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 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. 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. 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. 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. 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. > 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. 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