From: Ihor Radchenko <email@example.com>
To: Arthur Miller <firstname.lastname@example.org>
Cc: Tim Cross <email@example.com>, firstname.lastname@example.org
Subject: Re: Proposal: 'executable' org-capture-templaes
Date: Sat, 18 Jun 2022 12:03:51 +0800 [thread overview]
Message-ID: <87mteawrbs.fsf@localhost> (raw)
Arthur Miller <email@example.com> writes:
> Anyway, I have been playing and testing a bit, and didn't want to prolong
> discussion untill I have something to show. So here is a small prototype. It is
> just a rough sketch of the idea.
I will not comment on Elisp part just yet. Let's first settle down the design.
> this example the mode map approach seems slightly more convenient. I don't know,
> in org-agenda-test, I haven't implemented all of org-agenda, restrictions,
> prefixes and some other stuff, mostly because I don't really understand the
In the nutshell, agenda restrictions will execute some elisp that sets
certain global variables affecting other agenda commands. selecting the
restriction should not leave the agenda menu.
Also, unlike other selections being echoed literally upon selection,
restriction echo must depend on the global state. If you press "<" in
the menu, the menu prompt should change between "Press key for agenda
command (unrestricted):", Press key for agenda command (restricted to
buffer):, ... etc
Note that there is not much point echoing the selection.
Tim, do I understand correctly that changed minibuffer prompt will be
also spoken out by emacspeak?
> About the name: org-select; i really have no idea what to call it, so better
> name would be nice. Sorry for the bugs, I am aware of many, but it still
> displays the idea I think.
It does not matter at this point. We can discuss it at the very end. It
is not like M-x replace-regexp is difficult to run later.
> (defun osl--make-mode-map ()
> (let ((map (make-sparse-keymap)))
> (define-key map [?q] #'org-select-quit)
> (define-key map [?\C-g] #'org-select-abort)
> (define-key map [left] #'osl--back)
> (define-key map [?\C-p] #'osl--back)
binding left and C-p is unexpected. C-n and C-p are usually dedicated to
moving around. A very conservative alternative could be creating a new
buffer for sub-menus and letting the user use the usual previous-buffer
> ;;; API
> (defun org-select (tables &rest args)
> "Select a member of an alist with multiple keys.
> TABLE is an alist which should contain entries where the car is a string.
> There should be two types of entries.
This is confusing because there is no TABLE argument in the command.
I it not immediately clear that you can use multiple tables to build a
> ARGS is a property list containing following members:
Does it apply to individual menu entries? I am a bit confused here.
> :text a string placed over the selection in the buffer.
> :label a string used for the selections buffer name.
:label name is confusing. Why not directly :buffer-name?
> :always when `t', this menu is shown; even descended into submenus
> :transient when `t', the menu is dissmised after user perform an
Does it apply to the whole table? Individual entries?
> TABLES are additional menus in the same format as TABLE. If there are more
> than one menus, they will be separated by a separator line rendered with
> character as specified in `org-select-horizontal-separator'"
> (defun org-capture-test (&optional goto keys)
> (defun org-capture--handle (entry)
> (org-select-quit "")
> ((or (equal "C" (car entry)) (equal "q" (car entry)))
> (eval (nth 2 entry)))
> (let* ((orig-buf (current-buffer))
This looks fragile. It is hard to know what is the value of
(current-buffer) after exiting the manu. It is not guaranteed to be the
buffer where the menu was called initially.
A more proper alternative could be allowing the menu to setup some
variables _before_ running the menu. For example, org-select can store
some setting as buffer-local variables in the menu buffer. This way, the
caller can fill some initial settings at the calling time. The settings
will then be available at the time user actually select the menu option.
> (defvar org-agenda--menu
> '((("a" "Agenda for current week or day" (org-agenda--exec
It's nice that I can instead do
`((("a" ,(propertize "Agenda for current week or day"
and the face is actually preserved (:
next prev parent reply other threads:[~2022-06-18 4:31 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-26 15:27 Proposal: 'executable' org-capture-templaes Arthur Miller
2022-05-27 5:27 ` Ihor Radchenko
2022-05-27 12:17 ` Arthur Miller
2022-05-27 14:35 ` Max Nikulin
2022-05-28 3:51 ` Ihor Radchenko
2022-05-30 2:04 ` Arthur Miller
2022-05-30 5:05 ` Ihor Radchenko
2022-05-30 12:40 ` Arthur Miller
2022-05-31 4:58 ` Ihor Radchenko
2022-05-31 14:46 ` Arthur Miller
2022-06-04 15:35 ` Arthur Miller
2022-06-05 0:04 ` Ihor Radchenko
2022-06-05 15:16 ` Arthur Miller
2022-06-05 23:05 ` Tim Cross
2022-06-08 12:43 ` Ihor Radchenko
2022-06-08 21:13 ` Tim Cross
2022-06-09 4:00 ` Ihor Radchenko
2022-06-17 4:40 ` Arthur Miller
2022-06-18 4:03 ` Ihor Radchenko [this message]
2022-06-18 4:26 ` Tim Cross
2022-06-18 12:25 ` Max Nikulin
2022-06-08 12:24 ` Ihor Radchenko
2022-06-05 7:36 ` Max Nikulin
2022-06-05 15:07 ` Arthur Miller
2022-06-06 17:06 ` Max Nikulin
2022-06-07 3:09 ` Samuel Wales
2022-06-07 3:16 ` Samuel Wales
2022-06-08 12:48 ` Ihor Radchenko
2022-06-10 16:53 ` Max Nikulin
2022-06-11 5:26 ` Ihor Radchenko
2022-06-18 8:18 ` Max Nikulin
2022-06-18 8:25 ` Ihor Radchenko
2022-06-19 11:20 ` Max Nikulin
2022-06-20 12:10 ` Ihor Radchenko
2022-06-20 17:24 ` Max Nikulin
2022-06-21 4:07 ` Ihor Radchenko
2022-06-21 7:38 ` Arthur Miller
2022-06-21 15:48 ` Max Nikulin
2022-06-22 12:13 ` Arthur Miller
2022-06-22 16:29 ` Max Nikulin
2022-06-26 4:50 ` Arthur Miller
2022-06-29 17:02 ` Max Nikulin
2022-06-30 23:30 ` Arthur Miller
2022-07-01 15:53 ` Proposal: 'executable' org-capture-templates Max Nikulin
2022-06-25 7:32 ` Proposal: 'executable' org-capture-templaes Ihor Radchenko
2022-06-26 4:25 ` Arthur Miller
2022-06-26 4:37 ` Ihor Radchenko
2022-06-26 4:52 ` Arthur Miller
2022-06-21 7:37 ` Arthur Miller
2022-07-02 11:31 ` Max Nikulin
2022-07-03 15:12 ` Arthur Miller
2022-07-07 16:14 ` Proposal: 'executable' org-capture-templates Max Nikulin
2022-06-18 15:05 ` Proposal: 'executable' org-capture-templaes Arthur Miller
2022-06-19 10:53 ` Max Nikulin
2022-06-19 15:34 ` Arthur Miller
2022-07-03 3:32 ` Max Nikulin
2022-06-08 12:35 ` Ihor Radchenko
2022-05-31 16:37 ` Max Nikulin
2022-06-01 1:45 ` arthur miller
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).