From: firstname.lastname@example.org To: Jean Louis <email@example.com> Cc: firstname.lastname@example.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" <email@example.com> > To: firstname.lastname@example.org > Cc: "TRS-80" <email@example.com>, firstname.lastname@example.org > Subject: Re: Org Capture Menu cannot be fully viewed > > * email@example.com <firstname.lastname@example.org> [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 >
next prev parent 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --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).