> Sent: Sunday, December 13, 2020 at 4:12 PM > From: "Jean Louis" <bugs@gnu.support> > To: "Tim Cross" <theophil...@gmail.com> > Cc: emacs-orgmode@gnu.org > Subject: Re: Org Capture Menu cannot be fully viewed > > * Tim Cross <theophil...@gmail.com> [2020-12-13 03:54]: > > > > pie...@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.
Quite correct. > 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 > >
