emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: Max Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Proposal: 'executable' org-capture-templaes
Date: Mon, 6 Jun 2022 20:16:20 -0700	[thread overview]
Message-ID: <CAJcAo8sru7zBVonCwbEKL2PGOHLGAABne7t-GmK5+b8iYMnxRw@mail.gmail.com> (raw)
In-Reply-To: <CAJcAo8ubWWnjsSBLE37-JVevL-vNTUV7a9tVf=0etyz5Jwg_aQ@mail.gmail.com>

[i put an unnecessary and not really meant word truly there.
accessbililty reasons could of course make it necessary.]

i think it is needed to do accessibility and great to do factoring.
shows our maturity as a project and developers.

[accessbilty/refactoring aside, i want to say i really like many
aspects of the care taken to make many of our menus.  e.g. kw
selection or tag selection use colors, have low key count.  date
selection too.  i wonder how much of this will survive?]


On 6/6/22, Samuel Wales <samologist@gmail.com> wrote:
> 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 <manikulin@gmail.com> 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
>>> 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.
>>
>>
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com


  reply	other threads:[~2022-06-07  3:18 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
2022-06-07  3:16                         ` Samuel Wales [this message]
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

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJcAo8sru7zBVonCwbEKL2PGOHLGAABne7t-GmK5+b8iYMnxRw@mail.gmail.com \
    --to=samologist@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=manikulin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

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).