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 oOHPK36M1l/hUwAA0tVLHw (envelope-from ) for ; Sun, 13 Dec 2020 21:49:50 +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 6KiwJ36M1l/6MgAAbx9fmQ (envelope-from ) for ; Sun, 13 Dec 2020 21:49:50 +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 F223F94014B for ; Sun, 13 Dec 2020 21:49:49 +0000 (UTC) Received: from localhost ([::1]:33680 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koZFU-0002Th-TW for larch@yhetil.org; Sun, 13 Dec 2020 16:49:48 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60210) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koZCd-00086b-QG for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 16:46:52 -0500 Received: from stw1.rcdrun.com ([217.170.207.13]:32979) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koZCY-0006wB-KL for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 16:46:51 -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 00000000000308F9.000000005FD68BC3.00006617; Sun, 13 Dec 2020 14:46:43 -0700 Date: Mon, 14 Dec 2020 00:43:52 +0300 From: Jean Louis To: TEC Subject: Re: Org Capture Menu cannot be fully viewed Message-ID: References: <87eejtphlq.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <87eejtphlq.fsf@gmail.com> 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: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham 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: F223F94014B X-Spam-Score: -1.80 X-Migadu-Scanner: scn1.migadu.com X-TUID: Qmf7J1RzidQy * TEC [2020-12-13 23:38]: > > Hi Jean, a few thoughts. > > Jean Louis writes: > > > In other words program like Org capture is not meant for people having > > too many templates and that shall be explained right away both in > > function definitions and in the manual. Important people lose their > > time and effort in customizing org capture which was not meant to be > > used by people with too many templates. > > Categorising your capture templates can help a lot with this I think. > See [1]. > [1]: > https://www.reddit.com/r/emacs/comments/fzuv4f/my_prettified_orgcapture/ Yes, and I see also this: https://github.com/tecosaur/emacs-config/compare/6bcdbaa..49c790e If that looks friendly fine, to me it looks as a lot of work to construct a list. As capturing information anyway need to be sorted somewhere, things that contain other sorted things I call "Sets". When I create a set one time such set has its name, right? Later I can access the name by using semantic search (I write what I think) by using standard Emacs completion. There are 1148 sets and I can quicker access the set then some people one among 10 of their capture templates. My workflow is this: 1. No templates and nonsense, no Org settings at all. I work in database. 2. Press key 3. Type what I think and choose a set equivalent to capture template. 4. Write the note and close. Or just "Create new set" from menu or by using "a s" for "Add set". If I have chosen already categories why should I again include some org files into templates? I don't want. If I already have Org files and Agenda can go through all the Org files and Org files mostly have their Titles inside defined, then Org capture could simply complete among all the Org files anyway somehow indexed and offer me completing function to choose one from. Files are already on file system, computer has to find it and offer me the choice. It is contra-productive that I have to tell to computer which files to be offered to myself. That is too much low level for users. Org files like any files have their access and modification times. Those recently modified or accessed should be shown first among all. Even if there are 5000 Org files computer function to prioritize among them by displaying those frequently used, or recently modified would already be relevant enough for users. > > Why not provide completing-read for Org capture templates? That would > > solve the problem fully. > > Eh, personally I'm not convinced this is the way to go. I find > category use is sufficiant to keep a number of templates well-organised > and accesible. As purpose of org capture is to quickly put it somewhere for later sorting, the more templates there are the more is that purpose defeated. Then it becomes better to sort it right away at the moment of capture like some of us do. Maybe there are two types of capturing: 1. Capturing information that is already well known with or without annotation. Such information may be WWW hyperlink, file and some of its properties, like image, video, some other Org file, email subject or SMS, If annotation is not necessary, these items should be captured without any menu screen, it should be just captured. Minibuffer could say "captured" or similar. No need to interrupt and annotate. If you already annotate, then why not sort it right away? Cut the procrastination and finalize that item. If there is nothing to be written by user, just capture, do not show screen, menu, nothing. 2. Then there are free notes, something user has to create. Or those annotated items from first group. But even for this type of capture if there are many templates then is better to sort it correctly right away. Choose file and write the free text note. Because there is so much writing why not sort it right away? Also desirable would be to choose not only file but heading where it should be captured. Present design is that Org capture goes basically on the end of various files. Org agenda indexes all files and knows about all headings. Good! That means that Org capture could take place anywhere in any heading of any file. Files could be shown in completing-read function in minibuffer as: My-org-file.org >> My heading one My-org-file.org >> My heading two My-other-file.org >> My heading one My-other-file.org >> My heading two user could select proper heading and file by: "oth two" for the heading number 4 above. It is real time filter available in completion packages. Jean