From: Tim Cross <email@example.com> To: Jean Louis <firstname.lastname@example.org> Cc: email@example.com Subject: Re: Org Capture Menu cannot be fully viewed Date: Mon, 14 Dec 2020 07:06:38 +1100 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <X9YvSoEQUU+7ADYm@protected.rcdrun.com> Jean Louis <email@example.com> writes: > * 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 have no clue as to why your dragging Emacs custom into this discussion. The issue being discussed here is making it easier to select from a larger list of capture templates, not defining custom templates. Your ability to drag a thread off topic is quite incredible and somewhat frustrating. >> 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. > I have not programmed any completion functionality in elisp, but as a user I certainly have had to configure it and it doesn't seem as easy to me as you imply. Would ge good to hear concrete suggestion on how Emacs completion could be used for capture template selection for users who use icomplete, ido or fido in a way where the user is not required to configure anything i.e. works out of the box just like the current capture selection window 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. > Again, not what this thread was about. I also find this confusing as you write as though you are very informed and knowledgeable about Org capture and why it is not very good and yet don't seem to be aware of the most basic aspects of what is already available. For example, the target entry for a template can be a function that takes no arguments and returns the path to the location where you want the template to store its contents. Is that not what your after? >> 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. > Again, don't see the relevance to this thread. Also don't see anything terribly noteworthy here - with the exception of SMS and statistics, which is not relevant to my use case, I have pretty much the same, but in my case it is all editable and available and synced across all my devices (including tablet). I also have no dependencies on anything else, like external database, so if Emacs is not available, I can edit/update just using any text editor. > 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. I disagree and thing your over stating the problem. For many people, the existing export screen works fine and provides a good interface. It doesn't work well for me because I have a lot of additional export targets and because I have to use a much larger than normal font. While your solution may work better for edge cases such as in my situation, it sounds like it would be less convenient for many other users as it would require a lot more keystrokes. It currently takes me 3 keystrokes to export to any of the available export target options in my system. I only need the export window for export targets I seldom use and don't remember exactly which keystrokes to enter. > 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. > There currently is no restriction on where you can capture to. If you have complex requirements, you need to define a function which returns the path to where you want to store the data. That function can be as comp[ex or as simple as you want. -- Tim Cross
next prev parent reply other threads:[~2020-12-13 20:49 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 2020-12-13 18:08 ` pietru 2020-12-13 20:06 ` Tim Cross [this message] 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --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).