From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Proposal: 'executable' org-capture-templaes
Date: Tue, 21 Jun 2022 00:24:26 +0700 [thread overview]
Message-ID: <t8qagc$rv4$1@ciao.gmane.io> (raw)
In-Reply-To: <87zgi7357y.fsf@localhost>
On 20/06/2022 19:10, Ihor Radchenko wrote:
> Max Nikulin writes:
>
> Sure. I was hinting about such functionality in the new library we are
> discussing. Multiple capture menus are not possible now anyway, so it
> will be a new feature if we decide that we need it (I am not 100% sure
> if having multiple menus is not going to be confusing).
In my opinion application logic should be consistent with UI. Do you
think current behavior of help buffers has no problems? If so I have no
chance to convince you that upgrade of menu should be accompanied by
changes in org-capture.
Consider the following case. A user has 2 virtual desktops dedicated to
rather independent tasks and an Emacs frame on each desktop. On desktop
1 she opens help for some function with aim to evaluate if it is
appropriate for some particular purpose. Next she has to switch to
another task and applications for it reside on virtual desktop 2. To
proceed further she has to read several help pages relevant for task 2.
After completion of this task it is time to resume task 1 and to switch
to virtual desktop 1. Does a window with the help buffer still display
the same content as before switching to task 2? No, context on desktop 1
lost due to some actions in the Emacs frame on desktop 2.
Such synchronization is against multitasking and I do not like the idea
to get it for org-capture as well. Currently read-key and modal prompt
is a kind of excuse, but the idea of new menu library is non-blocking
keymap-based selection.
>> Currently several capture menu instances may be requested though
>> org-protocol (or calling org-capture from emacsclient). The behavior is
>> rather confusing. New menu may help to fix the issue, that is why I
>> raised the question about parallel captures.
>
> I am not sure which behavior you have in mind.
try the following commands without selecting a template in an Emacs
frame in between
emacsclient 'org-protocol:/capture?url=url-A&title=title-A&body=body=A'
emacsclient 'org-protocol:/capture?url=url-B&title=title-B&body=body=B'
> What I was thinking as a conservative implementation that would not
> introduce any new features is replacing the old menu with the new one
> every time the same menu is called. So, every time the user calls menu
> (e.g. capture menu), only the last capture environment is preserved. The
> previous, potentially unfinished, capture menus will be destroyed.
Causing loss of user data. Currently it is hard to start new capture
before selecting a template.
next prev parent reply other threads:[~2022-06-20 17:25 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
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 [this message]
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='t8qagc$rv4$1@ciao.gmane.io' \
--to=manikulin@gmail.com \
--cc=emacs-orgmode@gnu.org \
/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).