emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Proposal: 'executable' org-capture-templaes
Date: Sat, 2 Jul 2022 18:31:57 +0700	[thread overview]
Message-ID: <t9pabf$12ed$1@ciao.gmane.io> (raw)
In-Reply-To: <AM9PR09MB4977E03A1B053903627B30A596B39@AM9PR09MB4977.eurprd09.prod.outlook.com>

On 21/06/2022 14:37, Arthur Miller wrote:
> Emacs as a whole is not designed to work in the way I
> percieve it has clean separation between contexts in each frame. Menu
> buffer is "global" for entire Emacs process, and there are other
> features of Emacs that does not work well in such scenarion. Some people
> prefer to keep an Emacs process per project/task for that reason.

A side note rather unrelated to menu for Org mode.

My impression is that Emacs process per task scenario is not supported. 
It is almost certainly requires different init files, but request for a 
command line option overriding init.el was refused:

setting user-emacs-directory at command line invocation
> So I think the conclusion to this long thread was that we don't want to
> add a specific switch for this, and instead people can say
> "XDG_CONFIG_HOME=/whatever emacs" when they want to change these paths.
> So I'm closing this bug report.

Unfortunately initialization in Emacs is rather tricky and
     emacs -q -l init.el
may behave differently.

On the other hand the latest variant of org-select is quite close to 
reasonable level of support of multiple instances of the same menu.

>>>> 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.
> Current org-capture is one at a time because of how org-mks works. There
> is nothing that prevents org-capture to open enumerated buffers,
> org-caputre<1>, org-capture<2> etc. User has to manually serialize data
> anyway, via C-c C-c from withing capture buffer? So in principle it is
> still one capture buffer at a time that manipulates the file on the disk
> itself?

I would like to avoid confusion here. "*CAPTURE*" buffers are created 
after selection of template. Menu is gone away and content is already 
added to the target document, so it will be saved in response to C-x C-s 
or autosaved after some interval. There is no need of additional 
persistence at this stage.

And to be clear, example I provided is broken, it creates 2 template 
selection menus existing at the same time, but second request overwrites 
capture data. When one template is selected, menu disappears, but 
session is still blocked by waiting for a key specifying second 
template. It is really ugly. I expect that new menu implementation will 
allow to improve user experience.

I was writing about interval between invocation of `org-capture' and 
selection of some template. During this period capture data exist only 
as values of runtime variable. Currently it is acceptable because it is 
almost impossible to do anything else in Emacs till capture template is 

Non-blocking menu makes the issue more severe for some (likely small) 
fraction of users. Of course, it is responsibility of code calling menu 
and arranging menu item handler, not the code implementing menu.

The priority of this issue is certainly less than choosing proper menu 
API and implementing it. However it should not be forgotten at the 
moment when new menu implementation will be committed to Org.

  reply	other threads:[~2022-07-02 11:32 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 [this message]
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:

  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='t9pabf$12ed$1@ciao.gmane.io' \
    --to=manikulin@gmail.com \
    --cc=emacs-orgmode@gnu.org \


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