emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Arthur Miller <arthur.miller@live.com>
To: Max Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Proposal: 'executable' org-capture-templaes
Date: Sun, 05 Jun 2022 17:07:49 +0200	[thread overview]
Message-ID: <AM9PR09MB497735C473682613E3854A9496A39@AM9PR09MB4977.eurprd09.prod.outlook.com> (raw)
In-Reply-To: <t7hmd6$86r$1@ciao.gmane.io> (Max Nikulin's message of "Sun, 5 Jun 2022 14:36:05 +0700")

Max Nikulin <manikulin@gmail.com> writes:

> On 04/06/2022 22:35, Arthur Miller wrote:
>>
>> However before I continue, I am thinking of ditching the 'read-key' completely
>> and switching to "standard" Emacs way of implementing interactivity via mode and
>> mode-map. I am currently playing with such implementation, which to me appears
>> both simpler (code reduction) and more flexible, but it does change the mental
>> model of how clients of org-mks are used, for example org-capture.
>
> Frankly speaking, I am quite confused concerning what you are trying to do in
> particular. At some moment I had an impression that you were going to factor out
> of `org-capture' the menu that is already a separate function `org-mks'.

From the beginning I relized I can easily create menus with org-capture, bu just
definiing org-templates, which are simply lists, and wanted to generalize the
org-capture to create menus that can execute ordinary functions, which 'exec'
keyword did. 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:

#+begin_src emacs-lisp

(defun demo1 ()
  "Simple illustration to recreate org-capture menu (visually only)."
  (interactive)
  (let ((quick-menu-key-decorator-chars "[]")
        (return
         (quick-menu
          ;; table
          test-templates
          ;; description
          '(:label "*Quick Select*"
                   :text "Select a capture template\n=========================")
          ;; more tables
          '(("C" "Customize org-capture-templates"
             (customize-variable 'org-capture-templates))
            ("q" "Abort" (user-error "Abort"))))))
    (if (called-interactively-p 'interactive)
        (message "%S" return)
      return)))

(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"))))))
     
"quick-menu" is my refactoring of org-mks, definition looks like this:



(defun quick-menu (table &optional description &rest tables)
  "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.

1. prefix descriptions like (\"a\" \"Description\")
   This indicates that `a' is a prefix key for multi-letter selection, and
   that there are entries following with keys like \"ab\", \"ax\"...

2. Select-able members must have more than two elements, with the first
   being the string of keys that lead to selecting it, and the second a
   short description string of the item. 

The command will then make a temporary buffer listing all entries
that can be selected with a single key, and all the single key
prefixes.  When you press the key for a single-letter entry, it is selected.
When you press a prefix key, the commands (and maybe further prefixes)
under this key will be shown and offered for selection.

DESCRIPTON is a property list containing following members:

:text          a string placed over the selection in the buffer.
:label         a string used for the selections buffer name.
:prompt        a string used when prompting for a key.
:always        when `t', this menu is shown; even descended into submenus
:horizontal    when `t', if multiple menus are present they are rendered from
left to right, otherwise from top to bottom.
:key-decorator a two-character string used to decorate command characters. When
this string is specified, it will take precedence over the global variable
`quick-menu-key-decorator-chars'.

TABLES are additional menus in the same format as TABLE. If there are more
then one menus, they will be separated by a separator line rendered with
character as specified in `quick-menu-vertical-separator'")

#+end_src

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, and I am currently trying to implement horizontal
layout, where menus are stacked from left to right. I also have a not so nice
bug when drawing nested menu that it leaves undesired space where menus not
visible after descension into current are; I have to redraw the entire menu but
haven't yet implemented it so I don't want to post a demo yet. But before I fix
redrawing and implement horizontal layout, I would like to switch to the
different model of interaction and use ordinary mode map idioms instead of
blocking read key. Since I need to rework current prototype for the re-drawing
part, I can as well rework it to skip read-key at the same time.

> Interface is blocking for purpose. Capture has single-task workflow
> currently.

Yes, I am aware of that. That is why I ask if it would be acceptable to switch
away from non-blocking interface. I totally agree that capture is a single-task
workflow, however more generalized menu should allow for other applications as
well. We can still achieve single-task workflow with org-capture, by simply not
allowing more then one org-capture menu buffer at a time, it is just that it
won't block entire Emacs. So one could have more than one application of
quick-menu, where for example org-capture is one application, some imaingary
greating-app would be a different application, etc.

>            Capture data are stored in global variables, so parallel captures may
> cause problems. Likely it is assumed that a user quickly selects template and
> necessary data are added to the target document buffer.

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.

> The following complain is mainly related to selection of a window to show the
> menu, but it should have in mind that some people use Emacs as window manager
> and menu should not hide windows related to current activity.
>
> Eric S Fraga. Re: Bug: org-no-popups disregards
> display-buffer-fallback-action. Mon, 15 Nov 2021 09:57:46
> +0000. https://list.orgmode.org/87fsrxeo6d.fsf@ucl.ac.uk
>
> 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 :-). 


  reply	other threads:[~2022-06-05 15:08 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 [this message]
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

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=AM9PR09MB497735C473682613E3854A9496A39@AM9PR09MB4977.eurprd09.prod.outlook.com \
    --to=arthur.miller@live.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).