From: Jean Louis <firstname.lastname@example.org> To: Tim Cross <email@example.com> Cc: firstname.lastname@example.org Subject: Re: Org Capture Menu cannot be fully viewed Date: Sun, 13 Dec 2020 18:12:10 +0300 [thread overview] Message-ID: <X9YvSoEQUU+7ADYm@protected.rcdrun.com> (raw) In-Reply-To: <email@example.com> * Tim Cross <firstname.lastname@example.org> [2020-12-13 03:54]: > > email@example.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
next prev parent reply other threads:[~2020-12-13 17:37 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 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 [this message] 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=X9YvSoEQUU+7ADYm@protected.rcdrun.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --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).