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