Re: Org Capture Menu cannot be fully viewed

[Tim Cross <theophilusx@gmail.com>]

Jean Louis <bugs@gnu.support> writes:

> * Tim Cross <theophilusx@gmail.com> [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 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