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 oPXZDUY0nmJyJwEAbAwnHQ (envelope-from ) for ; Mon, 06 Jun 2022 19:07:18 +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 cGnIDUY0nmIywgAA9RJhRA (envelope-from ) for ; Mon, 06 Jun 2022 19:07:18 +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 A9A572EAD2 for ; Mon, 6 Jun 2022 19:07:15 +0200 (CEST) Received: from localhost ([::1]:37122 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nyGCA-0005tj-QF for larch@yhetil.org; Mon, 06 Jun 2022 13:07:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60990) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nyGBk-0005sX-NC for emacs-orgmode@gnu.org; Mon, 06 Jun 2022 13:06:48 -0400 Received: from ciao.gmane.io ([116.202.254.214]:38618) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nyGBj-0000uQ-3g for emacs-orgmode@gnu.org; Mon, 06 Jun 2022 13:06:48 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nyGBg-0005Yy-Mv for emacs-orgmode@gnu.org; Mon, 06 Jun 2022 19:06:44 +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, 7 Jun 2022 00:06:39 +0700 Message-ID: References: <87mtf3tui1.fsf@localhost> <87pmjyco0x.fsf@localhost> <87fskrobiw.fsf@localhost> <87a6ay1enh.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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=1654535235; 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=kv2vAVm34NvtYv3QLzCXBS3ZYv9qt+5G/LDt4CAYUbQ=; b=QwYFbkbWReKasBX5eIeS+RAcGNl3vYes1CeFovexA6aEuC6nRaNEiT/RisbADNz9lFMUCo RPv6fU6PEaKOokMM986MIMpNRRmqewyv53Hg2e5nEGt5H2xkI3wQXyvIbBg8mbmmlw6/xR Whf911v/datkm/3nbCXg8Z/1lTo/PyBJwVhMf3dfFdUOpMbcO+DQ+bwETMNs9b+To+OIHa EfydNuqSBYGsq5EjCsFcx/evKmZ7dbAIOOfs70miHwQAWJrZh+yDSVDSIaebvsIg/Amg6u pDtwP2+NQ8J/M/7W0ne+eMip9lJ4L/AxKwU34Nni9oAtFa4t1h56XLphKK9bfA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1654535235; a=rsa-sha256; cv=none; b=II2AWiez5Rh770ReqjCqXRFfg++LgVVL9TIXuWDhw8icah0TYJjLtKPMEQxGWQLKOFryEb A6y7BEgi/NWzvXObl6cQL5ZqD8mz8TEqFdIat/Up4XVDojRPuO0SQYPYuy22sH3ebwfqcp xDv5OMR5FMfjem001qNixbs32wNly1RXsG2+lCBRrGrt/+3IcfNerulc0tlNofQ25j4dJ5 6UV2cTwbOM08Ys23i1olUjqGcnQ1ShD+5cJ6tdta46Yvk2guq286Pz0BOE0eWzzAgsf3QU jDgvr91efhNFIOdUgAjEg9YG6ArRKZuu2cDYC8UX8ouZvD6Ry5953Rut5wUO8g== 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.69 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: A9A572EAD2 X-Spam-Score: 2.69 X-Migadu-Scanner: scn1.migadu.com X-TUID: k+sdkJRuGqQs On 05/06/2022 22:07, Arthur Miller wrote: > Max Nikulin writes: > > After input from Ihor I agree that it isn't the best way, and was > able to refactor org-mks to create a menu where I can execute any lisp form, > when it comes in a list like this : ("h" "hello-word" (message "Hello, > World")), where third element is just a lisp form. I have something like this: This message is merely my opinion that you may disagree. I am not trying to prevent you from going forward. From my point of view current `org-mks' is more general giving you opportunity to treat extra elements as you wish. A thin wrapper allows to evaluate 3rd element of returned list. You have not convinced me that built-in executable form is the essential feature. > (defun demo3 () > "Illustrate nested menus, unicode separator and alternative decorator." > (interactive) > (let ((quick-menu-key-decorator-chars "<>") > (quick-menu-vertical-separator ?─)) > (quick-menu > ;; table > '(("g" "Greetings") > ("gh" "Hello, World!" (message "Hello, World!")) > ("gb" "Bar" (message "Hello, Bar!"))) > ;; description > nil > ;; more tables > '(("f" "Functions") > ("ff" "Find File" (call-interactively #'find-file)) > ("fo" "Open File" (flet ((next-read-file-uses-dialog-p () t)) > (call-interactively 'find-file)))) > '(("q" "Abort" (user-error "Abort")))))) It is tightly based on org-mks, but actually it is way to represent list of choices with some hints to possible hierarchy and accelerator keys. Quite similar list may be fed to completion read or represented as a hierarchical GUI menu. The only specific is "always visible" elements like "abort". When Ubuntu used Unity desktop their had a nice feature of searching in application menu. There should be an extension point that allows users to replace representation e.g. to improve accessibility. > DESCRIPTON is a property list containing following members: ... > :horizontal when `t', if multiple menus are present they are rendered from > left to right, otherwise from top to bottom. It may depend on whether a window created to display menu is tall and narrow or wide. > I have paramterized decorator character for shortcut keys as they appear in the > buffer, org-capture uses "[]", as well as menu separator, which is currently > hard-coded in org-capture, I agree that org-mks may have additional argument to specify menu decoration. > Exactly. It is important that org-capture is one capture at the time so people > don't mess their note files, agenda files etc. > >> Unsure if some >> intermediate persistent store would be an improvement. > > Not sure what you mean here, but I don't plan to change anything in org-capture > itself, it should still be one-task at the time. Changing interface to less degree of blocking may be confusing for users. Capture template selection menu may be displayed in another frame hidden behind other application, on another monitor, on another virtual desktop, so invisible. So a user earlier distracted by something urgent may try to start another capture. Captures may be initiated from other applications using org-protocol. To avoid data loss while other capture is in progress, the data of next capture may be temporary saved to some place till the user pops it from the queue. I mentioned persistence since something may unexpectedly crash, so it should be possible to resurrect enqueued captures in next Emacs session. >> Likely nobody performed any steps toward `transient' as the interface, but due >> to such requests it would be nice to have possibility to switch between menu >> implementations. > > I am not building some generalized framework, as I said in my first respone to > Ihor :-). I am not requesting for a framework, I mean API compatible with other frameworks to let user choose their preferred ones. So tunables to control decoration sounds interesting. I am in doubts concerning fixing some element as executable. Mode-map instead of minibuffer may be a great step to more convenient interface (it resembles help buffers), but may require more changes in functions that do actual job. From other messages on this list my impression is that API should be designed having in mind flexibility and other UI packages.