Re: Org Capture Menu cannot be fully viewed

[pietru@caramail.com]

> Sent: Monday, December 14, 2020 at 12:08 AM
> From: "TRS-80" <lists.trs-80@isnotmyreal.name>
> To: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> On 2020-12-12 23:57, pietru@caramail.com wrote:
> > TRS-80 wrote:
> >> If you care to share a slightly bigger picture view, particularly
> >> about the structure of the data you are trying to capture (and/or,
> >> your workflow) we could likely come up with something that would work
> >> much better for you than a capture template, at least in this
> >> particular case.
> >
> > In many instances, previous work would have been done, so people would
> > want to quickly skip entries.
>
> I think perhaps plain old Org headline folding might be great for
> quickly navigating to the incomplete portion of the document?
> Especially if the sections each might contain a lot of prose and/or
> notes, and/or the sections are logically organized in any sort of tree
> structure.

Yes, the prose seems a challenging to capture, except for extracting from
emails perhaps.

> If it's more about key: value type data, I would (again) recommend Org
> Properties.  I'm sure there might be a way (or we could whip one up) to
> help automate searching through the document looking for empty
> Properties if that's the sort of workflow you would like.

I got to discuss this key-value with some people.  This is quite related to
link types using keywords.  Will will find it useful if not restricted to email
etc.  But we would like to specify the key ourselves.

But having completion would be really super , especially if people can use
regexp search on entries in a master file).

> > The plan for Org-Mode Capture is primarily for such Exclusive and
> > Unsystematic Surveys where we do not necessarily use standard forms.
> > I'm not sure if you capture the drift concerning unsystematic surveys.
> > Most times I cannot tell you exactly what people in the field came up
> > with.  The pace can be rapid and some could be working in challenging
> > conditions.  The plan is for the Crew Chief to make a quick template,
> > and which could change each day.  maintain and review notebooks and
> > records and overseeing quality control is done daily.  It is customary
> > to split the day.  One of the best ways we improve survey efficiency
> > is to anticipate bottlenecks and invent creative logistical solutions
> > right in the field.
> >
> > The long template situation then occurs.  You can access better than
> > myself as you know what org and org-capture can do and what not.

> Overall, what I am imagining is some set of Orgmode files as templates.

Absolutely correct.

> Each template containing all requirements of data collection for that
> type.  So you would simply make new copy of empty template file for each
> new instance of that particular case / template.  Inside would be
> headings organizing the different parts of the survey or whatever the
> work is.  And then Org Properties as needed for key: value data, located
> within the tree structure on headings as appropriate (remembering that
> Property inheritance is possible).
>
> You could even use the TODO functionality to mark sections as being
> complete.  It then becomes easy to find sections which have not been
> finished yet.  With org-log-done and org-log-into-drawer (and other
> related) settings you could even have different teams make (timestamped)
> metadata notes about what they accomplished, making it easier to hand
> off partially completed work between teams and allow them to communicate
> between each other in a sort of side channel without that info being
> directly in the report.
>
> As you can see, there are often many options, so it's mostly about "what
> workflow do you want?"  ;)

Let's concentrate on essential parts first and not too much hassle to implement.

> > I briefly reported on what we found problematic in practice.  But
> > we're at the beginning of this, and would likely report on other
> > things as we progress.
>
> Yes, please let us know how you are getting on!

> > Nevertheless, we see some aspects where your scheme can be improved to
> > cater for more serious work.  Emacs is quite good software.
>
> This is probably the strongest point.  Emacs can be almost whatever you
> want it to be.  Even non-programmers (with a little effort) can stitch
> together their own custom interfaces using some combination of
> package(s), built-in functionality, and perhaps a bit of Elisp.  Which
> makes it a bit of a universal User Interface framework, in a way.

That's the kind of people we have.  If they can conveniently set up a capture
template suitable for archaeological work.  Completion (including regexp)
would really help them.  We can have a number of master files (with definitions,
categories, etc).  They can then concentrate on jotting useful comments
and progress, rather than playing with Academese.  The latter part can be
searched and selected from the master files.

> > Hope my comments helped somewhat.
>
> Yes, I think so.  Hopefully my replies will therefore heve been equally
> helpful to you.

Now that the topic is understood, what can we tackle?  Don't think it would
be useful elaborating on extremely specific archaeo things.  Just things
that would be useful to many people, although inspired by our discussion.

Bit more flexibility so we can continue doing some more things with org-mode.

Thank you so very much
Pietro

> Cheers,
> TRS-80
>
>