From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id CPBQETBQ1l8XagAA0tVLHw (envelope-from ) for ; Sun, 13 Dec 2020 17:32:32 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id uBkDDTBQ1l8tdAAAbx9fmQ (envelope-from ) for ; Sun, 13 Dec 2020 17:32:32 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id DC0AB940418 for ; Sun, 13 Dec 2020 17:32:31 +0000 (UTC) Received: from localhost ([::1]:33066 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koVET-00084I-LI for larch@yhetil.org; Sun, 13 Dec 2020 12:32:29 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55214) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koVDs-00083p-Ht for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 12:31:52 -0500 Received: from stw1.rcdrun.com ([217.170.207.13]:58887) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koVDq-00028w-NZ for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 12:31:52 -0500 Received: from localhost ([::ffff:197.157.34.185]) (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 00000000000308F8.000000005FD65004.00004CD6; Sun, 13 Dec 2020 10:31:47 -0700 Date: Sun, 13 Dec 2020 13:24:56 +0300 From: Jean Louis To: pietru@caramail.com Subject: Re: Org Capture Menu cannot be fully viewed Message-ID: References: <87y2i2ttl7.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -3 X-Spam_score: -0.4 X-Spam_bar: / X-Spam_report: (-0.4 / 5.0 requ) BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.80 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: DC0AB940418 X-Spam-Score: -1.80 X-Migadu-Scanner: scn1.migadu.com X-TUID: TtUDsdzszvWJ * 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