emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jean Louis <bugs@gnu.support>
To: pietru@caramail.com
Cc: emacs-orgmode@gnu.org
Subject: Re: Org Capture Menu cannot be fully viewed
Date: Sun, 13 Dec 2020 13:24:56 +0300	[thread overview]
Message-ID: <X9Xr+E5/UOMvbp20@protected.rcdrun.com> (raw)
In-Reply-To: <trinity-9343a8fe-9db1-47db-8cb3-c6521ce93dfe-1607831362919@3c-app-mailcom-bs11>

* pietru@caramail.com <pietru@caramail.com> [2020-12-13 06:51]:
> > Are there any more to these templates you did not show?

I was thinking some users will get surprised on this. They may even
say it is not necessary.

I have 1148 sets where I am capturing different
information. Imagine if I would be spending my time adjusting
what is not adjustable. Or spending time in configuring entries
and system asks me to assign "key" to the template. Which flaming
key?!

> > Because, (and unless I am missing something) what I see are essentially
> > all the same (and quite simple).  You would end up with something like
> > the following in your target file (with the cursor ending up at the x):
> 
> It was an example for long agenda option.  Wanted to send a basic one
> without the details that could bother you.  The real one will have information
> regarding Site_Type [Domestic, Funerary, Water-Related, Settlement].  But we
> don't have the things in org though.

It allos speaks loud that you need not a key based filing but semantic
based filing.

If we have few templates like 5-10 templates, key based filing is
fine.

If we have 20-50 or 1148 places where to sort captured note than we
need a larger list type of a menu or filtering functions, completing
functions with the semantic search.

Initially bad design corrupts user's habits to now start thinking of
"keys" instead of thinking of meanings like "domestic" "historical"
"background" and similar. Writing "dom his bac" would probably find
what you mean, and if not, similar candidates could be shown along.

I feel inclined to write a completing read function but on the other
hand I do not find it as a true solution.

> What sort of thing better than template capture?  My basic idea was
> to see what org tools are available, see what kind of problems me
> get to, without asking too much things specific to us.  We can then
> work through things ourselves.  Perhaps share them with some other
> organisations.

While your work is totally understandable and logical and reasonable
it obviously cannot be handled with Org capture easily.

If you would be fine not to use those heading templates, maybe a
simple completion list of files where you wish to capture something
would be enough.

;; Create hash
(setq my-files-hash (make-hash-table))

;; Try putting something into the hash, define your files and their meanings
(puthash (intern "One file") "~/tmp/new.org" my-files-hash)
(puthash (intern "Something else") "~/tmp/else.org" my-files-hash)
;; You could continue feeding various files while only making sure
;; that they description differ from each other

;; Take it back from hash to verify
(gethash (intern "Something else") my-files-hash)
"~/tmp/else.org"

;; Construct list of semantic meanings of those files
(hash-table-keys my-files-hash)
=> (One\ file Something\ else)

(defun my-capture ()
  (interactive)
  (let* ((my-files (hash-table-keys my-files-hash))
	 (my-files (mapcar #'symbol-name my-files))
	 (my-selection (completing-read "File to capture: " my-files))
	 (my-selected-file (gethash (intern my-selection) my-files-hash)))
    (when selected-file
      (find-file selected-file)
      (goto-char (point-max))
      (insert "\n")
      (insert ** ))))

Now the function would let you choose semantic description. You
could use ivy-mode for basic relevance search. It would help you
choose "back" and "hist" for some historical background. It would
then open your Org file and move you to the end of it and prepare
heading.

But it does not include heading templates. When I look into Org
capture I do not find to me expected functional style of
programming so right now I would not know where to start to
implement the template. At least this way you could quickly
choose among large number of files, and insert the entry on the
end of the file.

I am not sure of Org capture used the built-in Emacs skeleton
templates. But that is something I could rather think of.

Then I would define various skeleton templates like:

(define-skeleton my-template-1
  "Prepares template"
  nil
  "** " (skeleton-read "Heading: ") "

  URL: " (skeleton-read "URL: ") "
  ")

Such can be invoked from M-x my-template-1

then something like:

(puthash (intern "Something else") '("~/tmp/else.org" my-template-1) my-files-hash)

would define that the file "Something else" is using the skeleton
template. This way all templates become separate and reusable for various files.

Then the function would be enhanced:

(defun my-capture ()
  (interactive)
  (let* ((my-files (hash-table-keys my-files-hash))
	 (my-files (mapcar #'symbol-name my-files))
	 (my-selection (completing-read "File to capture: " my-files))
	 (data (gethash (intern my-selection) my-files-hash))
	 (selected-file (car data))
	 (template (cadr data)))
    (when selected-file
      (find-file selected-file)
      (goto-char (point-max))
      (insert "\n")
      (call-interactively template))))

Then by calling my-capture you are semantically choosing where to
file, and you may have unlimited number of files and
corresponding template is also chosen automatically for you. You
may edit templates separately from files.

It would be trivial to even choose a different template at time
of capturing.

Jean


  parent reply	other threads:[~2020-12-13 17:32 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
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 [this message]
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:
  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=X9Xr+E5/UOMvbp20@protected.rcdrun.com \
    --to=bugs@gnu.support \
    --cc=emacs-orgmode@gnu.org \
    --cc=pietru@caramail.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).