emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: pietru@caramail.com
To: Jean Louis <bugs@gnu.support>
Cc: emacs-orgmode@gnu.org
Subject: Re: Org Capture Menu cannot be fully viewed
Date: Sun, 13 Dec 2020 19:41:13 +0100	[thread overview]
Message-ID: <trinity-e12bbbd0-61d7-43b3-8755-9c6a75ce5d3a-1607884873499@3c-app-mailcom-bs09> (raw)
In-Reply-To: <X9Xr+E5/UOMvbp20@protected.rcdrun.com>

> Sent: Sunday, December 13, 2020 at 11:24 AM
> From: "Jean Louis" <bugs@gnu.support>
> To: pietru@caramail.com
> Cc: "TRS-80" <lists.trs-80@isnotmyreal.name>, emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> * 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.

Haven't ever exceeded 21.

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

It would be beneficial to extend "%:keyword".  This way we can capture
data from a project file.  Someone suggested, getting keyword values from
recfiles (defined in Gnu Recutils).  That would be quick to accomplish in
the  field.

> ;; 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.


I have to take some time to chew into this.

> Jean
>


  reply	other threads:[~2020-12-13 18:43 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-12 18:02 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
2020-12-13 18:41             ` pietru [this message]
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=trinity-e12bbbd0-61d7-43b3-8755-9c6a75ce5d3a-1607884873499@3c-app-mailcom-bs09 \
    --to=pietru@caramail.com \
    --cc=bugs@gnu.support \
    --cc=emacs-orgmode@gnu.org \
    --subject='Re: Org Capture Menu cannot be fully viewed' \
    /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

Code repositories for project(s) associated with this 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).