Re: Org Capture Menu cannot be fully viewed

[pietru@caramail.com]

> Sent: Sunday, December 13, 2020 at 9:06 PM
> From: "Tim Cross" <theophilusx@gmail.com>
> To: "Jean Louis" <bugs@gnu.support>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
>
> 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.

My commentary has been to

1.  Allow more entries by making the menu buffer similar to a normal buffer
2.  Possibility to insert pre-defined text in the destination org file, that
    could be too verbose for people to write.
    Example: Side scan sonar frequency
3.  As most sites would have already had work completed, go through all fields
    and inserting then as nil can be time consuming.  For instance, come up with
    a way to pre-select the ones you want displayed without having to construct a
    new template.

I feel you could be overthinking the whole setup. The ideas in org-capture
and org mode are relatively straightforward.  They simply got to a stage that
if they can be beefed up to allow for actual job duties in high paced environments
where people do not have much time to think and organise as in an office.
Yet the most important information gets best documented in the field, as far as
the work does.   Lots of things can get messed up due to environmental conditions,
another reason as to why pace varies a lot, and quite difficult to predict how
they get to manage their particular case.

> >> 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
>
>