emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jean Louis <bugs@gnu.support>
To: TEC <tecosaur@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Org Capture Menu cannot be fully viewed
Date: Mon, 14 Dec 2020 00:43:52 +0300	[thread overview]
Message-ID: <X9aLGPJnyzAJS1ma@protected.rcdrun.com> (raw)
In-Reply-To: <87eejtphlq.fsf@gmail.com>

* TEC <tecosaur@gmail.com> [2020-12-13 23:38]:
> Hi Jean, a few thoughts.
> Jean Louis <bugs@gnu.support> writes:
> > In other words program like Org capture is not meant for people having
> > too many templates and that shall be explained right away both in
> > function definitions and in the manual. Important people lose their
> > time and effort in customizing org capture which was not meant to be
> > used by people with too many templates.
> Categorising your capture templates can help a lot with this I think.
> See [1].

> [1]:
> https://www.reddit.com/r/emacs/comments/fzuv4f/my_prettified_orgcapture/

Yes, and I see also this:

If that looks friendly fine, to me it looks as a lot of work to
construct a list.

As capturing information anyway need to be sorted somewhere, things
that contain other sorted things I call "Sets". When I create a set
one time such set has its name, right?

Later I can access the name by using semantic search (I write what I
think) by using standard Emacs completion. There are 1148 sets and I
can quicker access the set then some people one among 10 of their
capture templates.

My workflow is this:

1. No templates and nonsense, no Org settings at all. I work in

2. Press key

3. Type what I think and choose a set equivalent to capture template.

4. Write the note and close.

Or just "Create new set" from menu or by using "a s" for "Add set".

If I have chosen already categories why should I again include some
org files into templates? I don't want.

If I already have Org files and Agenda can go through all the Org
files and Org files mostly have their Titles inside defined, then Org
capture could simply complete among all the Org files anyway somehow
indexed and offer me completing function to choose one from. Files are
already on file system, computer has to find it and offer me the
choice. It is contra-productive that I have to tell to computer which
files to be offered to myself. That is too much low level for users.

Org files like any files have their access and modification
times. Those recently modified or accessed should be shown first among
all. Even if there are 5000 Org files computer function to prioritize
among them by displaying those frequently used, or recently modified
would already be relevant enough for users. 

> > Why not provide completing-read for Org capture templates? That would
> > solve the problem fully.
> Eh, personally I'm not convinced this is the way to go. I find
> category use is sufficiant to keep a number of templates well-organised
> and accesible.

As purpose of org capture is to quickly put it somewhere for later
sorting, the more templates there are the more is that purpose
defeated. Then it becomes better to sort it right away at the moment
of capture like some of us do.

Maybe there are two types of capturing:

1. Capturing information that is already well known with or without
   annotation. Such information may be WWW hyperlink, file and some of
   its properties, like image, video, some other Org file, email
   subject or SMS, If annotation is not necessary, these items should
   be captured without any menu screen, it should be just
   captured. Minibuffer could say "captured" or similar. No need to
   interrupt and annotate. If you already annotate, then why not sort
   it right away? Cut the procrastination and finalize that item. If
   there is nothing to be written by user, just capture, do not show
   screen, menu, nothing.

2. Then there are free notes, something user has to create. Or those
   annotated items from first group. But even for this type of capture
   if there are many templates then is better to sort it correctly
   right away. Choose file and write the free text note. Because there
   is so much writing why not sort it right away?

Also desirable would be to choose not only file but heading where it
should be captured. Present design is that Org capture goes basically
on the end of various files. Org agenda indexes all files and knows
about all headings. Good!

That means that Org capture could take place anywhere in any heading
of any file.

Files could be shown in completing-read function in minibuffer as:

My-org-file.org >> My heading one
My-org-file.org >> My heading two
My-other-file.org >> My heading one
My-other-file.org >> My heading two

user could select proper heading and file by:

"oth two" for the heading number 4 above. It is real time filter
available in completion packages.


  reply	other threads:[~2020-12-13 21:49 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-12 18:02 Org Capture Menu cannot be fully viewed pietru
2020-12-12 22:09 ` TRS-80
2020-12-12 22:46   ` pietru
2020-12-12 23:13     ` TRS-80
2020-12-12 23:30       ` pietru
2020-12-13  0:00         ` TRS-80
2020-12-13  0:10           ` pietru
2020-12-13 11:06   ` Jean Louis
2020-12-13 18:28     ` pietru
2020-12-13 20:37       ` Jean Louis
2020-12-13 20:52         ` TRS-80
2020-12-13 21:02         ` pietru
2020-12-13 21:48           ` Jean Louis
2020-12-13 22:08             ` pietru
2020-12-13 22:20             ` pietru
2020-12-13 22:00           ` TRS-80
2020-12-13 22:36             ` pietru
2020-12-13 20:32     ` TEC
2020-12-13 21:43       ` Jean Louis [this message]
2020-12-13  0:46 ` Tim Cross
2020-12-13  1:32   ` pietru
2020-12-13  2:08     ` pietru
2020-12-13  3:16       ` TRS-80
2020-12-13  3:49         ` pietru
2020-12-13  4:30           ` TRS-80
2020-12-13  9:58             ` pietru
2020-12-13 16:52             ` Jean Louis
2020-12-13 10:24           ` Jean Louis
2020-12-13 18:41             ` pietru
2020-12-13 20:48               ` TRS-80
2020-12-13  4:57         ` pietru
2020-12-13  9:24           ` Christopher Dimech
2020-12-13 23:08           ` TRS-80
2020-12-14  0:04             ` pietru
2020-12-13  9:44       ` Jean Louis
2020-12-13 18:46         ` Christopher Dimech
2020-12-16 18:46         ` No Wayman
2020-12-16 16:58       ` No Wayman
2020-12-13 15:12   ` Jean Louis
2020-12-13 18:08     ` pietru
2020-12-13 20:06     ` Tim Cross
2020-12-13 21:37       ` pietru
2020-12-13 21:57       ` Bastien
2020-12-13 22:31         ` pietru
2020-12-13 23:30         ` Jean Louis
2020-12-13 23:52           ` Bastien
2020-12-13 22:34       ` Jean Louis
2020-12-14 12:41 ` Marco Wahl
2020-12-14 13:00   ` pietru
2020-12-14 13:18     ` Marco Wahl
2020-12-14 20:02   ` Org Capture Menu cannot be fully viewed - Results of testing C-n, C-p, C-v pietru
2020-12-16 21:46     ` Marco Wahl
2020-12-16 23:25       ` pietru

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=X9aLGPJnyzAJS1ma@protected.rcdrun.com \
    --to=bugs@gnu.support \
    --cc=emacs-orgmode@gnu.org \
    --cc=tecosaur@gmail.com \


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