From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id UkcuNk5R1l/UfwAA0tVLHw (envelope-from ) for ; Sun, 13 Dec 2020 17:37:18 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id yFKfMU5R1l+3QwAAB5/wlQ (envelope-from ) for ; Sun, 13 Dec 2020 17:37:18 +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 72F2D940363 for ; Sun, 13 Dec 2020 17:37:18 +0000 (UTC) Received: from localhost ([::1]:50866 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koVJ7-0007AU-7N for larch@yhetil.org; Sun, 13 Dec 2020 12:37:17 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55438) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koVEs-0001V5-Tu for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 12:32:54 -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 1koVEq-00028w-QF for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 12:32:54 -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 00000000000308F7.000000005FD65043.00004D83; Sun, 13 Dec 2020 10:32:50 -0700 Date: Sun, 13 Dec 2020 18:12:10 +0300 From: Jean Louis To: Tim Cross 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: <87y2i2ttl7.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: 72F2D940363 X-Spam-Score: -1.80 X-Migadu-Scanner: scn1.migadu.com X-TUID: 7yFL5UmZBRx7 * Tim Cross [2020-12-13 03:54]: > > pietru@caramail.com writes: > > > Dear All, > > > > When making a relatively long Org Capture Menu for Archaeological Field Management, > > the relevant capture window cannot be scrolled down. This becomes particularly > > problematic with small field laptops. > > > > I'm assuming you mean the window which pops up where you select the > capture template to use. > > Just wondering if perhaps what we really need to do is provide some sort > of support for using Emacs completion facilities to select > templates? That is very right. I have 1140+ "Sets" which are equivalent to capture templates. Imagine if I would be "defining it" by using Emacs custom, forget it, I would rather break my computer down and switch to paper. I define the set one time as a set. If I wish to capture into that set I use quick relevance search or semantic access. I would not like remembering any "keys" for that purpose. > realise this is challenging because of the huge wealth of completion > frameworks available in Emacs, but perhaps adding support for something > like fido-mode would be beneficial. Ah, no. Completions shall be available by standard. Emacs's standard completion is just fine and any comletion package can extend it. That is how it works. Would org-capture functions be programmed in more functional style I would already make the function. Maybe somebody else finds time to do it. Or somebody can help me and tell how to use function, which function, to file into specific Org file from org-templates, then I will make function for completing-read as it is trivial. I am missing only that. > To some extent, it feels like org is re-inventing a wheel here and > we would be better off using an existing facility rather than > develop/maintain an org specific version. Good observation, welcome to club. > I see a very similar problem with the export menu, but that is a > more complex situation. Since quite some time I am using Org mode as display mode, not editing mode. The compiled related information about person is displayed as Org mode on the fly. I can have persons' images, SMS sent, notes, tasks, transactions, emails received, including statistics all in one Org file as display that is read-only. Similar derived mode could be used to display export menu and capture menu. Instead they block user's interface, cursor cannot move to other buffers, one has to interrupt those screens to do something else. Incredibly user unfriendly. (define-derived-mode my-org-view-mode org-mode "My View Org" "My Org View") (define-key my-org-view-mode-map (kbd "q") 'kill-this-buffer) (define-key my-org-view-mode-map (kbd "e") 'export-somewhere) etc. Even multiple screens for multiple org files can be made to work with their buffer local text in a different way. One can export the other file, the other this file, Same for Capture menu, just same. Make the Org file, define keys on the fly or simply hyperlinks and let users capture where they wish without limit. Jean