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: Sat, 18 Jun 2022 17:05:34 +0200 [thread overview]
Message-ID: <AM9PR09MB4977774DC5F189646681FDB496AE9@AM9PR09MB4977.eurprd09.prod.outlook.com> (raw)
In-Reply-To: <t8k1og$qs$1@ciao.gmane.io> (Max Nikulin's message of "Sat, 18 Jun 2022 15:18:23 +0700")
Max Nikulin <manikulin@gmail.com> writes:
> On 11/06/2022 12:26, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>
>>> However if two org-protocol handlers are launched without specified
>>> template then behavior of Org becomes confusing. I meant this case.
>>> Currently reading key from minibuffer serves as a kind of
>>> synchronization tool.
>>>
>>> Imagine what would happen if Emacs decided to show several capture menus
>>> with keymap non-blocking interface in different virtual desktops.
>>> Capture data should be saved somewhere till the user would discover
>>> initially hidden menu.
>> Note that there is not much happening when capture menu is called. Only
>> the link is stored into link ting. Otherwise, no capture data is
>> altered. All the fragile staff is happening after selecting capture
>> template.
>
> Ihor, magic is impossible. If several captures may be requested in parallel then
> snapshot of data required to fill capture template should be stored somewhere at
> the moment when capture is initiated. Otherwise the user may kill the buffer she
> is going to capture before selecting particular template.
>
> There are enough side band communication channels in Org. I did not remember a
> variable from which properties are obtained. Before I have realized that it is
> `org-store-link-plist', I noticed at least `org-overriding-default-time',
> `org-capture-initial'. Unsure that the list is complete.
I have a question here: what is meant by this:
>>> Imagine what would happen if Emacs decided to show several capture menus
>>> with keymap non-blocking interface in different virtual desktops.
Different Emacs processes, or just different Emacs frames?
In case of different Emacs processes, there is no way to guarantee consistence
unless one locks file in the file system. Windows can do it, I am not sure what
is Linux API to do this, don't know if Emacs exposes this functionality, have
never tried.
Otherewise, if it is only different Emacs frames/clients, the capture should
always find the capture buffer and return that one instead of creating new
ones. That way there is only one capture buffer, so multiple captures should not
be possible, i.el, it creates same effect as locking the input to minibuffer. I
am not sure how org-capture does, I haven't studied the code in-depth yet, but
what I see currently a user cancels it with C-c C-k. org-capture buffer could
setup hooks to clean everything, even if user kills buffer by other means, c-x
k, or whatever. It maybe already does, as said I haven't looked at those
details.
I just haven't done that in demo yet, so that is why I said when I posted the
code, I haven't implemented that "correctly", bit I am quite sure it is not very
hard to do.
Am I correct about the principle? If not, than I will have to rething about it.
next prev parent reply other threads:[~2022-06-18 15:11 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
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 ` Arthur Miller [this message]
2022-06-19 10:53 ` Proposal: 'executable' org-capture-templaes 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=AM9PR09MB4977774DC5F189646681FDB496AE9@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).