Re: Org Capture Menu cannot be fully viewed

[pietru]

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