From: Samuel Wales <firstname.lastname@example.org>
To: Max Nikulin <email@example.com>
Subject: Re: Proposal: 'executable' org-capture-templaes
Date: Mon, 6 Jun 2022 20:09:21 -0700 [thread overview]
Message-ID: <CAJcAo8ubWWnjsSBLE37-JVevL-vNTUV7a9tVf=0etyz5Jwg_aQ@mail.gmail.com> (raw)
i must be confused. menus aside, you can currently capture and it
uses the org forest itself, so it is both crash-proof and snappy. and
you can yakshave as much as you want, starting a capture while doing a
capture. those were design goals.
you can even be in the middle of a capture, get distracted, navigate
around your forest, and find where you are in the middle of a capture.
goes with the original crash-proof and yakshave and snappy
use-original-buffer design goal.
so are we talking about menus then? is there truly a need to make
/menu state/ persistent or yakshaveable?
On 6/6/22, Max Nikulin <firstname.lastname@example.org> wrote:
> 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
>> 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 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
>> (let ((quick-menu-key-decorator-chars "<>")
>> (quick-menu-vertical-separator ?─))
>> ;; table
>> '(("g" "Greetings")
>> ("gh" "Hello, World!" (message "Hello, World!"))
>> ("gb" "Bar" (message "Hello, Bar!")))
>> ;; description
>> ;; 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
>> 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
>> hard-coded in org-capture,
> I agree that org-mks may have additional argument to specify menu
>> Exactly. It is important that org-capture is one capture at the time so
>> 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
>> 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
>> 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.
The Kafka Pandemic
A blog about science, health, human rights, and misopathy:
next prev parent reply other threads:[~2022-06-07 3:13 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
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 [this message]
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).