Org Capture Menu cannot be fully viewed

Org Capture Menu cannot be fully viewed

[pietru]

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.

Regards
Pietru

Pietru Caxaro
Director General - Subsurface Imaging
Archaeological Superintendency of Rome

Re: Org Capture Menu cannot be fully viewed

[TRS-80]

On 2020-12-12 13:02, pietru@caramail.com wrote:
> 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.

Hi Pietru,

Capture templates are great, but I suppose there are a lot of advantages
to doing some custom Elisp which is why I do a lot more stuff that way
now that I have learned a little bit of Elisp.

Sorry, I guess that's not helpful if you are not comfortable with Elisp.
As an aside and thinking long term, I can say the investment was well
worth the payoff.  However back to the issue at hand.

Maybe if you are willing (or able) to share some more information, we
could help you through some basics.  Or maybe someone else might even
have some better idea (not involving Elisp) which might be more
appealing to you.

Cheers,
TRS-80

Re: Org Capture Menu cannot be fully viewed

[pietru]

> Sent: Saturday, December 12, 2020 at 11:09 PM
> 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 13:02, pietru@caramail.com wrote:
> > 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.
>
> Hi Pietru,
>
> Capture templates are great, but I suppose there are a lot of advantages
> to doing some custom Elisp which is why I do a lot more stuff that way
> now that I have learned a little bit of Elisp.

The problem also exists when making capture templates.  The solution could
be additional functionality coded in elisp that can then be used for handling
longer template entries.  As the problem is dependent on screen size, the problem
is likely to occur, requiring the patch.  It then becomes natural that the fix
is introduced without the template developer having to call the fix explicitely.

> Sorry, I guess that's not helpful if you are not comfortable with Elisp.
> As an aside and thinking long term, I can say the investment was well
> worth the payoff.  However back to the issue at hand.

I assume it would involve some elisp and would be willing to word towards
a solution.  But it would be even better that the solution would be
incorporated in the official version of emacs.

> Maybe if you are willing (or able) to share some more information, we
> could help you through some basics.  Or maybe someone else might even
> have some better idea (not involving Elisp) which might be more
> appealing to you.

I can send a long capture template.  And any additional information people
require.

> Cheers,
> TRS-80
>
>

Re: Org Capture Menu cannot be fully viewed

[TRS-80]

On 2020-12-12 17:46, pietru@caramail.com wrote:
>> From: "TRS-80" <lists.trs-80@isnotmyreal.name>
> 
> The problem also exists when making capture templates.  The solution
> could be additional functionality coded in elisp that can then be used
> for handling longer template entries.  As the problem is dependent on
> screen size, the problem is likely to occur, requiring the patch.  It
> then becomes natural that the fix is introduced without the template
> developer having to call the fix explicitely.

All true!

> I assume it would involve some elisp and would be willing to word 
> towards
> a solution.  But it would be even better that the solution would be
> incorporated in the official version of emacs.

What gets into Org / Emacs is up to maintainer(s?) and pending list
discussion.  Which might take some time, but in many cases (I imagine
even including this one) is probably The Right Thing to do.

If you can wait for that, it will end up improving Org and likely
helping a lot of people, including yourself (eventually).

I guess some times I just prefer my own local "quick and dirty" solution
which can be "good enough" or a workaround pending a more proper
solution.  Although, to be fair, the ability to maintain such solutions
(long term) is sort of dependent on knowing a bit of Elisp.  So it's a
bit of a trade-off.

> I can send a long capture template.  And any additional information 
> people
> require.

Well, it's up to you.  If you want we can pursue either option, or both
(one potentially as a temporary workaround).  Or we can wait for more
list replies and see what others think.  As I said there may also be a
better way I am not aware of.  If I'm being honest, I have plenty other
things to work on, too.  ;)  But since I open my big mouth now, I can't
very well leave you hanging, now can I?  :D  It also depends on how
complicated stuff we are talking...

Actually, another option just occurred to me.  I don't know where you
are sending results of the capture template, but if you are just
appending to file(s) perhaps you could break the one big template up
into some number of smaller ones?

Cheers,
TRS-80

Re: Org Capture Menu cannot be fully viewed

[pietru]

> Sent: Sunday, December 13, 2020 at 12:13 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 17:46, pietru@caramail.com wrote:
> >> From: "TRS-80" <lists.trs-80@isnotmyreal.name>
> >
> > The problem also exists when making capture templates.  The solution
> > could be additional functionality coded in elisp that can then be used
> > for handling longer template entries.  As the problem is dependent on
> > screen size, the problem is likely to occur, requiring the patch.  It
> > then becomes natural that the fix is introduced without the template
> > developer having to call the fix explicitely.
>
> All true!
>
> > I assume it would involve some elisp and would be willing to word
> > towards
> > a solution.  But it would be even better that the solution would be
> > incorporated in the official version of emacs.
>
> What gets into Org / Emacs is up to maintainer(s?) and pending list
> discussion.  Which might take some time, but in many cases (I imagine
> even including this one) is probably The Right Thing to do.

That is understood.

> If you can wait for that, it will end up improving Org and likely
> helping a lot of people, including yourself (eventually).
>
> I guess some times I just prefer my own local "quick and dirty" solution
> which can be "good enough" or a workaround pending a more proper
> solution.  Although, to be fair, the ability to maintain such solutions
> (long term) is sort of dependent on knowing a bit of Elisp.  So it's a
> bit of a trade-off.

> > I can send a long capture template.  And any additional information
> > people
> > require.
>
> Well, it's up to you.  If you want we can pursue either option, or both
> (one potentially as a temporary workaround).  Or we can wait for more
> list replies and see what others think.  As I said there may also be a
> better way I am not aware of.  If I'm being honest, I have plenty other
> things to work on, too.  ;)  But since I open my big mouth now, I can't
> very well leave you hanging, now can I?  :D  It also depends on how
> complicated stuff we are talking...

Very good of you.  If you let me give a basic long template (perhaps
"Investigation Site").  I can do both, get a fix, and work for an Emacs
incorporation .

> Actually, another option just occurred to me.  I don't know where you
> are sending results of the capture template, but if you are just
> appending to file(s) perhaps you could break the one big template up
> into some number of smaller ones?

One problem with that is that new entries are appended in vertical (newline)
and cannot put options in a table.

> Cheers,
> TRS-80
>
>

Re: Org Capture Menu cannot be fully viewed

[TRS-80]

On 2020-12-12 18:30, pietru@caramail.com wrote:
>> From: "TRS-80" <lists.trs-80@isnotmyreal.name>
>> 
>> Well, it's up to you.  If you want we can pursue either option, or 
>> both
>> (one potentially as a temporary workaround).  Or we can wait for more
>> list replies and see what others think.  As I said there may also be a
>> better way I am not aware of.  If I'm being honest, I have plenty 
>> other
>> things to work on, too.  ;)  But since I open my big mouth now, I 
>> can't
>> very well leave you hanging, now can I?  :D  It also depends on how
>> complicated stuff we are talking...
> 
> Very good of you.  If you let me give a basic long template (perhaps
> "Investigation Site").  I can do both, get a fix, and work for an
> Emacs incorporation .
> 
>> Actually, another option just occurred to me.  I don't know where you
>> are sending results of the capture template, but if you are just
>> appending to file(s) perhaps you could break the one big template up
>> into some number of smaller ones?
> 
> One problem with that is that new entries are appended in vertical 
> (newline)
> and cannot put options in a table.

How about post up your long template somewhere and we can have a look?
Maybe a paste site is better than the mailing list?  If you want to do
that and are not aware of any good (non proprietary) one, I like and use
a lot https://bpaste.net/ (which redirects now to https://bpa.st/,
apparently).

Maybe while I am at it I have a play about what might be required to get
some scrolling to work with the template.  For all I know, it could be a
simple fix...

Others please feel free to jump in, too, maybe you know something I
don't (about scrolling, I mean).

Cheers,
TRS-80

Re: Org Capture Menu cannot be fully viewed

[pietru]

> Sent: Sunday, December 13, 2020 at 1:00 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 18:30, pietru@caramail.com wrote:
> >> From: "TRS-80" <lists.trs-80@isnotmyreal.name>
> >>
> >> Well, it's up to you.  If you want we can pursue either option, or
> >> both
> >> (one potentially as a temporary workaround).  Or we can wait for more
> >> list replies and see what others think.  As I said there may also be a
> >> better way I am not aware of.  If I'm being honest, I have plenty
> >> other
> >> things to work on, too.  ;)  But since I open my big mouth now, I
> >> can't
> >> very well leave you hanging, now can I?  :D  It also depends on how
> >> complicated stuff we are talking...
> >
> > Very good of you.  If you let me give a basic long template (perhaps
> > "Investigation Site").  I can do both, get a fix, and work for an
> > Emacs incorporation .
> >
> >> Actually, another option just occurred to me.  I don't know where you
> >> are sending results of the capture template, but if you are just
> >> appending to file(s) perhaps you could break the one big template up
> >> into some number of smaller ones?
> >
> > One problem with that is that new entries are appended in vertical
> > (newline)
> > and cannot put options in a table.
>
> How about post up your long template somewhere and we can have a look?
> Maybe a paste site is better than the mailing list?  If you want to do
> that and are not aware of any good (non proprietary) one, I like and use
> a lot https://bpaste.net/ (which redirects now to https://bpa.st/,
> apparently).
>
> Maybe while I am at it I have a play about what might be required to get
> some scrolling to work with the template.  For all I know, it could be a
> simple fix...

That would be very good.  Very appreciative.  I am currently making a standalone example template
to play with.

> Others please feel free to jump in, too, maybe you know something I
> don't (about scrolling, I mean).
>
> Cheers,
> TRS-80
>
>

Re: Org Capture Menu cannot be fully viewed

[Jean Louis]

* TRS-80 <lists.trs-80@isnotmyreal.name> [2020-12-13 01:11]:
> On 2020-12-12 13:02, pietru@caramail.com wrote:
> > 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.
> 
> Hi Pietru,
> 
> Capture templates are great, but I suppose there are a lot of advantages
> to doing some custom Elisp which is why I do a lot more stuff that way
> now that I have learned a little bit of Elisp.

I find myself there. Things that are great in Emacs need not be really
practically great, that is why we need to make things great again.

In other words program like Org capture is not meant for people having
too many templates and that shall be explained right away both in
function definitions and in the manual. Important people lose their
time and effort in customizing org capture which was not meant to be
used by people with too many templates.

Which turns back to exact subject of that email. Now question is who
is going to improve it? Can it be done better?

Can interface be improved that people with larger number of templates
become free to use it?

My proposal is to quit using blocking interface where user cannot move
from buffer to buffer, instead to open up new buffer with new key mode
map that assigns those keys to those capture template functions. That
way the buffer becomes unlimited, user can open it, it is familiar
org-mode buffer and it can be unlimited.

> Sorry, I guess that's not helpful if you are not comfortable with
> Elisp.  As an aside and thinking long term, I can say the investment
> was well worth the payoff.  However back to the issue at hand.

I have also realized, that is why I have dropped the Org mode for
planning and project management, including for capturing notes.

> Maybe if you are willing (or able) to share some more information, we
> could help you through some basics.  Or maybe someone else might even
> have some better idea (not involving Elisp) which might be more
> appealing to you.

Why not provide completing-read for Org capture templates? That would
solve the problem fully.

Jean

Re: Org Capture Menu cannot be fully viewed

[pietru]

> Sent: Sunday, December 13, 2020 at 12:06 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: "TRS-80" <lists.trs-80@isnotmyreal.name>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> * TRS-80 <lists.trs-80@isnotmyreal.name> [2020-12-13 01:11]:
> > On 2020-12-12 13:02, pietru@caramail.com wrote:
> > > 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.
> >
> > Hi Pietru,
> >
> > Capture templates are great, but I suppose there are a lot of advantages
> > to doing some custom Elisp which is why I do a lot more stuff that way
> > now that I have learned a little bit of Elisp.
>
> I find myself there. Things that are great in Emacs need not be really
> practically great, that is why we need to make things great again.
>
> In other words program like Org capture is not meant for people having
> too many templates and that shall be explained right away both in
> function definitions and in the manual. Important people lose their
> time and effort in customizing org capture which was not meant to be
> used by people with too many templates.
>
> Which turns back to exact subject of that email. Now question is who
> is going to improve it? Can it be done better?
>
> Can interface be improved that people with larger number of templates
> become free to use it?
>
> My proposal is to quit using blocking interface where user cannot move
> from buffer to buffer, instead to open up new buffer with new key mode
> map that assigns those keys to those capture template functions. That
> way the buffer becomes unlimited, user can open it, it is familiar
> org-mode buffer and it can be unlimited.

Yes, that's the way forward.  If we organise templates in different files
it turns out ok.  Then simply append what we need.  Most field planners
would like to insert what they need without regard if short or long.
Unfortunately some professional terminology is quite verbose in contrast
to how most people use capture.  Field personnel also tend to use small
devices.

> > Sorry, I guess that's not helpful if you are not comfortable with
> > Elisp.  As an aside and thinking long term, I can say the investment
> > was well worth the payoff.  However back to the issue at hand.
>
> I have also realized, that is why I have dropped the Org mode for
> planning and project management, including for capturing notes.
>
> > Maybe if you are willing (or able) to share some more information, we
> > could help you through some basics.  Or maybe someone else might even
> > have some better idea (not involving Elisp) which might be more
> > appealing to you.
>
> Why not provide completing-read for Org capture templates? That would
> solve the problem fully.

I think it might work fine as you say.  Is that similar to what
"%^{prompt|default|completion2|completion3...}" does?  Or something similar?
I also know of icomplete.


> Jean
>
>

Re: Org Capture Menu cannot be fully viewed

[Jean Louis]

* pietru@caramail.com <pietru@caramail.com> [2020-12-13 21:28]:
> > Why not provide completing-read for Org capture templates? That would
> > solve the problem fully.
> 
> I think it might work fine as you say.  Is that similar to what
> "%^{prompt|default|completion2|completion3...}" does?  Or something similar?
> I also know of icomplete.

I suggest that you install package ivy that you see how it works. Then
you could try find-file or open file function to see completions.

You can try evaluating this here:

(setq collection '("I think it might" "Is that similar" "Or something similar"))

(completing-read "Choose: " collection)

You may then use TAB or C-j to complete among various options.

ivy and helm packages (maybe) enhances that and allow you to type just
"som" to reach to "Or something similar" or "think" to reach to "I
think it might" and offers basic relevance search if you use few
words.

Standard completion may use joker symbol *

Choose: *thingTAB

would expand to "Or something similar"

That is good way to go in Emacs if you have to chose among large
number of items of anything.

Jean

Re: Org Capture Menu cannot be fully viewed

[TRS-80]

On 2020-12-13 15:37, Jean Louis wrote:
> * pietru@caramail.com <pietru@caramail.com> [2020-12-13 21:28]:
> 
> I suggest that you install package ivy that you see how it works. Then
> you could try find-file or open file function to see completions.
> 
> You can try evaluating this here:
> 
> (setq collection '("I think it might" "Is that similar" "Or something 
> similar"))
> 
> (completing-read "Choose: " collection)
> 
> You may then use TAB or C-j to complete among various options.
> 
> ivy and helm packages (maybe) enhances that and allow you to type just
> "som" to reach to "Or something similar" or "think" to reach to "I
> think it might" and offers basic relevance search if you use few
> words.
> 
> Standard completion may use joker symbol *
> 
> Choose: *thingTAB
> 
> would expand to "Or something similar"
> 
> That is good way to go in Emacs if you have to chose among large
> number of items of anything.

This is much more along lines of what I had in mind.  A nice simple
example of plain completing-read interface.  However I am still not sure
that Org Properties are not the answer...

Cheers,
TRS-80

Re: Org Capture Menu cannot be fully viewed

[pietru]

> Sent: Sunday, December 13, 2020 at 9:37 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: pietru@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> * pietru@caramail.com <pietru@caramail.com> [2020-12-13 21:28]:
> > > Why not provide completing-read for Org capture templates? That would
> > > solve the problem fully.
> >
> > I think it might work fine as you say.  Is that similar to what
> > "%^{prompt|default|completion2|completion3...}" does?  Or something similar?
> > I also know of icomplete.
>
> I suggest that you install package ivy that you see how it works. Then
> you could try find-file or open file function to see completions.
>
> You can try evaluating this here:
>
> (setq collection '("I think it might" "Is that similar" "Or something similar"))
>
> (completing-read "Choose: " collection)
>
> You may then use TAB or C-j to complete among various options.

Similar to what I thought.  Put things in a file, thun capture from there.
One would not need to write long entries to the org file, but simply go through
the possibilities, then insert in capture org file.

> ivy and helm packages (maybe) enhances that and allow you to type just
> "som" to reach to "Or something similar" or "think" to reach to "I
> think it might" and offers basic relevance search if you use few
> words.
>
> Standard completion may use joker symbol *
>
> Choose: *thingTAB
>
> would expand to "Or something similar"
>
> That is good way to go in Emacs if you have to chose among large
> number of items of anything.

Would that apply with respect to inserting long headings or descriptions
in org file?


Example:

;;                "Site_SubType:
;;                   [1a] Settlement > Encampment
;;                   [1a] Settlement > Hamlet or Village
;;                   [1a] Settlement > Town or City
;;                   [1b] Domestic Structure > Brush Structure
;;                   [1b] Domestic Structure > Cave
;;                   [1b] Domestic Structure > House
;;                   [1b] Domestic Structure > House Mound
;;                   [1b] Domestic Structure > Wattle & Daub (Jacal) Structure
;;                   [1b] Domestic Structure > Long House
;;                   [1b] Domestic Structure > Pit House / Earth Lodge
;;                   [1b] Domestic Structure > Room Block / Compound / Pueblo
;;                   [1b] Domestic Structure > Rock Shelter
;;                   [1b] Domestic Structure > Shade Structure / Ramada
;;                   [1b] Domestic Structure > Tent Ring / Tipi Ring
;;                   [1b] Domestic Structure > Platform Mound
;;                   [1b] Domestic Structure > Shell Mound
;;                   [1b] Domestic Structure > Wigwam / Wetu
;;                   [1b] Domestic Structure > Plank House"


> Jean
>
>
>
>
>

Re: Org Capture Menu cannot be fully viewed

[Jean Louis]

* pietru@caramail.com <pietru@caramail.com> [2020-12-14 00:03]:
> > ivy and helm packages (maybe) enhances that and allow you to type just
> > "som" to reach to "Or something similar" or "think" to reach to "I
> > think it might" and offers basic relevance search if you use few
> > words.
> >
> > Standard completion may use joker symbol *
> >
> > Choose: *thingTAB
> >
> > would expand to "Or something similar"
> >
> > That is good way to go in Emacs if you have to chose among large
> > number of items of anything.
> 
> Would that apply with respect to inserting long headings or descriptions
> in org file?
> 
> 
> Example:
> 
> ;;                "Site_SubType:
> ;;                   [1a] Settlement > Encampment
> ;;                   [1a] Settlement > Hamlet or Village
> ;;                   [1a] Settlement > Town or City
> ;;                   [1b] Domestic Structure > Brush Structure
> ;;                   [1b] Domestic Structure > Cave
> ;;                   [1b] Domestic Structure > House
> ;;                   [1b] Domestic Structure > House Mound
> ;;                   [1b] Domestic Structure > Wattle & Daub (Jacal) Structure
> ;;                   [1b] Domestic Structure > Long House
> ;;                   [1b] Domestic Structure > Pit House / Earth Lodge
> ;;                   [1b] Domestic Structure > Room Block / Compound / Pueblo
> ;;                   [1b] Domestic Structure > Rock Shelter
> ;;                   [1b] Domestic Structure > Shade Structure / Ramada
> ;;                   [1b] Domestic Structure > Tent Ring / Tipi Ring
> ;;                   [1b] Domestic Structure > Platform Mound
> ;;                   [1b] Domestic Structure > Shell Mound
> ;;                   [1b] Domestic Structure > Wigwam / Wetu
> ;;                   [1b] Domestic Structure > Plank House"

That is well suited for completing functions in Emacs. Same way I work
with my 1148 sets where I capture notes into.

struc plat would find Platform Mound

Jean

Re: Org Capture Menu cannot be fully viewed

[pietru]

> Sent: Sunday, December 13, 2020 at 10:48 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: pietru@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> * pietru@caramail.com <pietru@caramail.com> [2020-12-14 00:03]:
> > > ivy and helm packages (maybe) enhances that and allow you to type just
> > > "som" to reach to "Or something similar" or "think" to reach to "I
> > > think it might" and offers basic relevance search if you use few
> > > words.
> > >
> > > Standard completion may use joker symbol *
> > >
> > > Choose: *thingTAB
> > >
> > > would expand to "Or something similar"
> > >
> > > That is good way to go in Emacs if you have to chose among large
> > > number of items of anything.
> >
> > Would that apply with respect to inserting long headings or descriptions
> > in org file?
> >
> >
> > Example:
> >
> > ;;                "Site_SubType:
> > ;;                   [1a] Settlement > Encampment
> > ;;                   [1a] Settlement > Hamlet or Village
> > ;;                   [1a] Settlement > Town or City
> > ;;                   [1b] Domestic Structure > Brush Structure
> > ;;                   [1b] Domestic Structure > Cave
> > ;;                   [1b] Domestic Structure > House
> > ;;                   [1b] Domestic Structure > House Mound
> > ;;                   [1b] Domestic Structure > Wattle & Daub (Jacal) Structure
> > ;;                   [1b] Domestic Structure > Long House
> > ;;                   [1b] Domestic Structure > Pit House / Earth Lodge
> > ;;                   [1b] Domestic Structure > Room Block / Compound / Pueblo
> > ;;                   [1b] Domestic Structure > Rock Shelter
> > ;;                   [1b] Domestic Structure > Shade Structure / Ramada
> > ;;                   [1b] Domestic Structure > Tent Ring / Tipi Ring
> > ;;                   [1b] Domestic Structure > Platform Mound
> > ;;                   [1b] Domestic Structure > Shell Mound
> > ;;                   [1b] Domestic Structure > Wigwam / Wetu
> > ;;                   [1b] Domestic Structure > Plank House"
>
> That is well suited for completing functions in Emacs. Same way I work
> with my 1148 sets where I capture notes into.
>
> struc plat would find Platform Mound

Can see there is some convergence of experience.

How orp-capture works is that extracting fields from emails is pretty good.
But that concept has not been extended to extract fields from plain text
record formats such as that provided by recutils.

That would make org-capture great indeed.

> Jean
>
>
>
>
>

Re: Org Capture Menu cannot be fully viewed

[pietru]

> Sent: Sunday, December 13, 2020 at 10:48 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: pietru@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> * pietru@caramail.com <pietru@caramail.com> [2020-12-14 00:03]:
> > > ivy and helm packages (maybe) enhances that and allow you to type just
> > > "som" to reach to "Or something similar" or "think" to reach to "I
> > > think it might" and offers basic relevance search if you use few
> > > words.
> > >
> > > Standard completion may use joker symbol *
> > >
> > > Choose: *thingTAB
> > >
> > > would expand to "Or something similar"
> > >
> > > That is good way to go in Emacs if you have to chose among large
> > > number of items of anything.
> >
> > Would that apply with respect to inserting long headings or descriptions
> > in org file?
> >
> >
> > Example:
> >
> > ;;                "Site_SubType:
> > ;;                   [1a] Settlement > Encampment
> > ;;                   [1a] Settlement > Hamlet or Village
> > ;;                   [1a] Settlement > Town or City
> > ;;                   [1b] Domestic Structure > Brush Structure
> > ;;                   [1b] Domestic Structure > Cave
> > ;;                   [1b] Domestic Structure > House
> > ;;                   [1b] Domestic Structure > House Mound
> > ;;                   [1b] Domestic Structure > Wattle & Daub (Jacal) Structure
> > ;;                   [1b] Domestic Structure > Long House
> > ;;                   [1b] Domestic Structure > Pit House / Earth Lodge
> > ;;                   [1b] Domestic Structure > Room Block / Compound / Pueblo
> > ;;                   [1b] Domestic Structure > Rock Shelter
> > ;;                   [1b] Domestic Structure > Shade Structure / Ramada
> > ;;                   [1b] Domestic Structure > Tent Ring / Tipi Ring
> > ;;                   [1b] Domestic Structure > Platform Mound
> > ;;                   [1b] Domestic Structure > Shell Mound
> > ;;                   [1b] Domestic Structure > Wigwam / Wetu
> > ;;                   [1b] Domestic Structure > Plank House"
>
> That is well suited for completing functions in Emacs. Same way I work
> with my 1148 sets where I capture notes into.
>
> struc plat would find Platform Mound

For instacce, in a particular field, the user could put tipi, but then the
full text is inserted that includes the full classification.

[86A25] Domestic Structure > Tent Ring / Tipi Ring

Nothing too fancy and things like icomplete or autocomplete on some
field would be handy.  People will be pleased with that.  Things can
get pretty dirty and writing on paper can be obfuscated quite easily.
Some have complained about technology failure in the field.

But, with proper care (things still very heavy duty) failures are usually
minimal compared to the amount of work we do get done.


> Jean
>
>
>
>
>

Re: Org Capture Menu cannot be fully viewed

[TRS-80]

On 2020-12-13 16:02, pietru@caramail.com wrote:
> 
> Would that apply with respect to inserting long headings or
> descriptions in org file?

Yes.  If you have not used completing-read, just play around with it a
bit and you will very quickly see how it works.  It takes a list (Elisp
data type) as input, on which you can do narrowing selection as you
type.

Ivy was one of recommendations which I can second, I prefer it's more
intuitive (to me) interaction style and support for native
completing-read format.  But there are (many) others, too.

> Example:
> 
> ;;                "Site_SubType:
> ;;                   [1a] Settlement > Encampment
> ;;                   [1a] Settlement > Hamlet or Village
> ;;                   [1a] Settlement > Town or City
> [...]

However to make it even simpler to use / maintain your candidate lists,
I would just put them in a simple plain text file, aligned to left
margin.  Example:

File name: Site_SubType

[1a] Settlement > Encampment
[1a] Settlement > Hamlet or Village
[1a] Settlement > Town or City

Then you need a function to read from plain text file with your "list"
of candidates, and turn that into an (Elisp data type) list:

#+begin_src emacs-lisp

(defun my-file-to-list (file)
     "Read FILE and return it as a list of strings.

   List items will be split upon newlines."
     (with-temp-buffer
       (insert-file-contents file)
       (split-string (buffer-string) "\n" t)))

#+end_src

You then use the above function (with filename argument) for your
candidate list in completing-read.  Modifying Jean Louis' earlier
example, it now becomes:

#+begin_src emacs-lisp

   (completing-read "Choose: "
		   (my-file-to-list "/path/to/Site_SubType"))

#+end_src

You can even use this to fill in Org Properties.  Or you can use Org
Properties similar native completion, although by default that only uses
whatever values already exist in the buffer (which therefore could be
"none"), instead of your specified controlled vocabulary file as I used
above.  I (by far) prefer the controlled vocabulary method, for lots of
reasons.

Cheers,
TRS-80

Re: Org Capture Menu cannot be fully viewed

[pietru]

> Sent: Sunday, December 13, 2020 at 11:00 PM
> 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-13 16:02, pietru@caramail.com wrote:
> >
> > Would that apply with respect to inserting long headings or
> > descriptions in org file?
>
> Yes.  If you have not used completing-read, just play around with it a
> bit and you will very quickly see how it works.  It takes a list (Elisp
> data type) as input, on which you can do narrowing selection as you
> type.
>
> Ivy was one of recommendations which I can second, I prefer it's more
> intuitive (to me) interaction style and support for native
> completing-read format.  But there are (many) others, too.
>
> > Example:
> >
> > ;;                "Site_SubType:
> > ;;                   [1a] Settlement > Encampment
> > ;;                   [1a] Settlement > Hamlet or Village
> > ;;                   [1a] Settlement > Town or City
> > [...]
>
> However to make it even simpler to use / maintain your candidate lists,
> I would just put them in a simple plain text file, aligned to left
> margin.  Example:
>
> File name: Site_SubType
>
> [1a] Settlement > Encampment
> [1a] Settlement > Hamlet or Village
> [1a] Settlement > Town or City

That would be my way to attack it, by storing any pre-defined things
with a field and a value in a record master file.

> Then you need a function to read from plain text file with your "list"
> of candidates, and turn that into an (Elisp data type) list:
>
> #+begin_src emacs-lisp
>
> (defun my-file-to-list (file)
>      "Read FILE and return it as a list of strings.
>
>    List items will be split upon newlines."
>      (with-temp-buffer
>        (insert-file-contents file)
>        (split-string (buffer-string) "\n" t)))
>
> #+end_src
>
> You then use the above function (with filename argument) for your
> candidate list in completing-read.  Modifying Jean Louis' earlier
> example, it now becomes:
>
> #+begin_src emacs-lisp
>
>    (completing-read "Choose: "
> 		   (my-file-to-list "/path/to/Site_SubType"))
>
> #+end_src
>
> You can even use this to fill in Org Properties.  Or you can use Org
> Properties similar native completion, although by default that only uses
> whatever values already exist in the buffer (which therefore could be
> "none"), instead of your specified controlled vocabulary file as I used
> above.  I (by far) prefer the controlled vocabulary method, for lots of
> reasons.
>
> Cheers,
> TRS-80
>
>

Re: Org Capture Menu cannot be fully viewed

[TEC]

Hi Jean, a few thoughts.

Jean Louis <bugs@gnu.support> writes:

> In other words program like Org capture is not meant for people having
> too many templates and that shall be explained right away both in
> function definitions and in the manual. Important people lose their
> time and effort in customizing org capture which was not meant to be
> used by people with too many templates.

Categorising your capture templates can help a lot with this I think.
See [1].

> Can interface be improved that people with larger number of templates
> become free to use it?

IMO just styling it nicer can make it easier to use. For instance, I
find symbols and colour help with at-a-glance use. Also see [1].

> My proposal is to quit using blocking interface where user cannot move
> from buffer to buffer, instead to open up new buffer with new key mode
> map that assigns those keys to those capture template functions. That
> way the buffer becomes unlimited, user can open it, it is familiar
> org-mode buffer and it can be unlimited.

This sounds like a good idea IMO 👍.

> Why not provide completing-read for Org capture templates? That would
> solve the problem fully.

Eh, personally I'm not convinced this is the way to go. I find
category use is sufficiant to keep a number of templates well-organised
and accesible.

All the best,

Timothy.


[1]: https://www.reddit.com/r/emacs/comments/fzuv4f/my_prettified_orgcapture/

Re: Org Capture Menu cannot be fully viewed

[Jean Louis]

* TEC <tecosaur@gmail.com> [2020-12-13 23:38]:
> 
> Hi Jean, a few thoughts.
> 
> Jean Louis <bugs@gnu.support> writes:
> 
> > In other words program like Org capture is not meant for people having
> > too many templates and that shall be explained right away both in
> > function definitions and in the manual. Important people lose their
> > time and effort in customizing org capture which was not meant to be
> > used by people with too many templates.
> 
> Categorising your capture templates can help a lot with this I think.
> See [1].

> [1]:
> https://www.reddit.com/r/emacs/comments/fzuv4f/my_prettified_orgcapture/

Yes, and I see also this:
https://github.com/tecosaur/emacs-config/compare/6bcdbaa..49c790e

If that looks friendly fine, to me it looks as a lot of work to
construct a list.

As capturing information anyway need to be sorted somewhere, things
that contain other sorted things I call "Sets". When I create a set
one time such set has its name, right?

Later I can access the name by using semantic search (I write what I
think) by using standard Emacs completion. There are 1148 sets and I
can quicker access the set then some people one among 10 of their
capture templates.

My workflow is this:

1. No templates and nonsense, no Org settings at all. I work in
   database.

2. Press key

3. Type what I think and choose a set equivalent to capture template.

4. Write the note and close.

Or just "Create new set" from menu or by using "a s" for "Add set".

If I have chosen already categories why should I again include some
org files into templates? I don't want.

If I already have Org files and Agenda can go through all the Org
files and Org files mostly have their Titles inside defined, then Org
capture could simply complete among all the Org files anyway somehow
indexed and offer me completing function to choose one from. Files are
already on file system, computer has to find it and offer me the
choice. It is contra-productive that I have to tell to computer which
files to be offered to myself. That is too much low level for users.

Org files like any files have their access and modification
times. Those recently modified or accessed should be shown first among
all. Even if there are 5000 Org files computer function to prioritize
among them by displaying those frequently used, or recently modified
would already be relevant enough for users. 

> > Why not provide completing-read for Org capture templates? That would
> > solve the problem fully.
> 
> Eh, personally I'm not convinced this is the way to go. I find
> category use is sufficiant to keep a number of templates well-organised
> and accesible.

As purpose of org capture is to quickly put it somewhere for later
sorting, the more templates there are the more is that purpose
defeated. Then it becomes better to sort it right away at the moment
of capture like some of us do.

Maybe there are two types of capturing:

1. Capturing information that is already well known with or without
   annotation. Such information may be WWW hyperlink, file and some of
   its properties, like image, video, some other Org file, email
   subject or SMS, If annotation is not necessary, these items should
   be captured without any menu screen, it should be just
   captured. Minibuffer could say "captured" or similar. No need to
   interrupt and annotate. If you already annotate, then why not sort
   it right away? Cut the procrastination and finalize that item. If
   there is nothing to be written by user, just capture, do not show
   screen, menu, nothing.

2. Then there are free notes, something user has to create. Or those
   annotated items from first group. But even for this type of capture
   if there are many templates then is better to sort it correctly
   right away. Choose file and write the free text note. Because there
   is so much writing why not sort it right away?

Also desirable would be to choose not only file but heading where it
should be captured. Present design is that Org capture goes basically
on the end of various files. Org agenda indexes all files and knows
about all headings. Good!

That means that Org capture could take place anywhere in any heading
of any file.

Files could be shown in completing-read function in minibuffer as:

My-org-file.org >> My heading one
My-org-file.org >> My heading two
My-other-file.org >> My heading one
My-other-file.org >> My heading two

user could select proper heading and file by:

"oth two" for the heading number 4 above. It is real time filter
available in completion packages.


Jean

Re: Org Capture Menu cannot be fully viewed

[Tim Cross]

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? I
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. 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.

I see a very similar problem with the export menu, but that is a more
complex situation.
--
Tim Cross

Re: Org Capture Menu cannot be fully viewed

[pietru]

> Sent: Sunday, December 13, 2020 at 1:46 AM
> From: "Tim Cross" <theophilusx@gmail.com>
> To: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
>
> 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.

Correct

> Just wondering if perhaps what we really need to do is provide some sort
> of support for using Emacs completion facilities to select templates? I
> 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. 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.

I have used icomplete, which works really well.  But I am not in a position
to claim it is the right solution

> I see a very similar problem with the export menu, but that is a more
> complex situation.
> --
> Tim Cross
>
>

Org Capture Menu cannot be fully viewed

[pietru]

Here is one version of a template

(setq capture-template-investigation-type '(

 ("a" "Historic Background Research Site Evaluation/Testing" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("b" "Systematic Survey Data Recovery/Excavation" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("c" "Records Search or Inventory Checking" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("d" "Site Stewardship Monitoring" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("e" "Site Stabilization" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("f" "Heritage Management" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("g" "Environment Research" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("h" "Reconnaissance or Survey" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("i" "Methodology, Theory, or Synthesis" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("j" "Collections Research" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("k" "Consultation" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("l" "Ethnographic Research" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("m" "Research Design or Data Recovery Plan" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("n" "Architectural Survey" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("o" "Ethnohistoric Research" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("p" "Ground Disturbance Monitoring" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("q" "Geophysical Survey" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("r" "Archaeological Overview" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("s" "Bioarchaeological Research" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("t" "Architectural Documentation" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n")

 ("u" "Remote Sensing" entry
  (file "~/histr/archaeol.org")
  "* Site_Type: %?\n %T\n") ))



> Sent: Sunday, December 13, 2020 at 2:32 AM
> From: pietru@caramail.com
> To: "Tim Cross" <theophilusx@gmail.com>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> > Sent: Sunday, December 13, 2020 at 1:46 AM
> > From: "Tim Cross" <theophilusx@gmail.com>
> > To: emacs-orgmode@gnu.org
> > Subject: Re: Org Capture Menu cannot be fully viewed
> >
> >
> > 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.
>
> Correct
>
> > Just wondering if perhaps what we really need to do is provide some sort
> > of support for using Emacs completion facilities to select templates? I
> > 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. 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.
>
> I have used icomplete, which works really well.  But I am not in a position
> to claim it is the right solution
>
> > I see a very similar problem with the export menu, but that is a more
> > complex situation.
> > --
> > Tim Cross
> >
> >
>
>

Re: Org Capture Menu cannot be fully viewed

[TRS-80]

On 2020-12-12 21:08, pietru@caramail.com wrote:
> Here is one version of a template
> 
> (setq capture-template-investigation-type '(
> 
>  ("a" "Historic Background Research Site Evaluation/Testing" entry
>   (file "~/histr/archaeol.org")
>   "* Site_Type: %?\n %T\n")
> 
> [...]
> 
>  ("u" "Remote Sensing" entry
>   (file "~/histr/archaeol.org")
>   "* Site_Type: %?\n %T\n") ))
> 

Are there any more to these templates you did not show?

Because, (and unless I am missing something) what I see are essentially
all the same (and quite simple).  You would end up with something like
the following in your target file (with the cursor ending up at the x):

#+begin_example

* Site_Type: x
[2020-12-12 Sat 21:58]

#+end_example

In fact I don't even see where the type name ends up in the result?

If all my assumptions above are true, I think you would probably be
better served with a simple completing-read (or similar) function to
select the "Investigation Type" from a list and then simply insert that
along with a timestamp.  Which it will take you longer to reply to this
email and confirm than it would take me to write such a function.  :)

Benefit of that way also removes possibility of typos in the type name.

In fact, the above could even be done with something as simple as
Yankpad[0].

I have no idea what your workflow looks like, or where this data ends
up.  However, thinking further, I would imagine it might even be helpful
to set one or more Org properties[1] for things like "Investigation
Type" (along with some other things I could speculate like "Location"
etc.).  But all of that depends on even more things I don't know about.

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.

Cheers,
TRS-80

[0] https://github.com/Kungsgeten/yankpad
[1] https://orgmode.org/manual/Properties-and-Columns.html

Re: Org Capture Menu cannot be fully viewed

[pietru]

> Sent: Sunday, December 13, 2020 at 4:16 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 21:08, pietru@caramail.com wrote:
> > Here is one version of a template
> >
> > (setq capture-template-investigation-type '(
> >
> >  ("a" "Historic Background Research Site Evaluation/Testing" entry
> >   (file "~/histr/archaeol.org")
> >   "* Site_Type: %?\n %T\n")
> >
> > [...]
> >
> >  ("u" "Remote Sensing" entry
> >   (file "~/histr/archaeol.org")
> >   "* Site_Type: %?\n %T\n") ))
> >
>
> Are there any more to these templates you did not show?
>
> Because, (and unless I am missing something) what I see are essentially
> all the same (and quite simple).  You would end up with something like
> the following in your target file (with the cursor ending up at the x):

It was an example for long agenda option.  Wanted to send a basic one
without the details that could bother you.  The real one will have information
regarding Site_Type [Domestic, Funerary, Water-Related, Settlement].  But we
don't have the things in org though.

> #+begin_example
>
> * Site_Type: x
> [2020-12-12 Sat 21:58]
>
> #+end_example
>
> In fact I don't even see where the type name ends up in the result?
>
> If all my assumptions above are true, I think you would probably be
> better served with a simple completing-read (or similar) function to
> select the "Investigation Type" from a list and then simply insert that
> along with a timestamp.  Which it will take you longer to reply to this
> email and confirm than it would take me to write such a function.  :)

Yes, I know about
"  %^{Investigation Type: |Site Stabilization|Heritage Management|Environment Research} %?\n"

At any rate, we come across long capture menus at one point or another.  The list is not fixed
but can vary by project that we cannot always predict (i.e. it could be changed in the field).

> Benefit of that way also removes possibility of typos in the type name.
>
> In fact, the above could even be done with something as simple as
> Yankpad[0].
>
> I have no idea what your workflow looks like, or where this data ends
> up.  However, thinking further, I would imagine it might even be helpful
> to set one or more Org properties[1] for things like "Investigation
> Type" (along with some other things I could speculate like "Location"
> etc.).  But all of that depends on even more things I don't know about.

Data can then be parsed into database once we get tho data files at home
base.

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

What sort of thing better than template capture?  My basic idea was to see
what org tools are available, see what kind of problems me get to, without
asking too much things specific to us.  We can then work through things
ourselves.  Perhaps share them with some other organisations.

> Cheers,
> TRS-80
>
> [0] https://github.com/Kungsgeten/yankpad
> [1] https://orgmode.org/manual/Properties-and-Columns.html
>
>

Re: Org Capture Menu cannot be fully viewed

[TRS-80]

On 2020-12-12 22:49, pietru@caramail.com wrote:
> TRS-80 wrote:
>> 
>> Are there any more to these templates you did not show?
>> 
>> Because, (and unless I am missing something) what I see are 
>> essentially
>> all the same (and quite simple).  You would end up with something like
>> the following in your target file (with the cursor ending up at the 
>> x):
> 
> It was an example for long agenda option.  Wanted to send a basic one
> without the details that could bother you.  The real one will have
> information regarding Site_Type [Domestic, Funerary, Water-Related,
> Settlement].  But we don't have the things in org though.

It's no bother.  In fact I am already thinking ahead as to the structure
of the data, which is the most important consideration.  Choice of
tool(s) should flow from that, and also from the desired workflow,
instead of the other way around.

Just so you know, you /could/ have the things in Org, if you wanted to
(or even in a separate plain text file, and use that as input for your
narrowing selection list).  Maybe they change, or there are other
reasons, but you could have the options in a list to choose from.  This
sort of thing reduce typos and errors.  You could limit to such list
strictly, or not (the latter allowing flexibility to add things on the
fly).

>> If all my assumptions above are true, I think you would probably be
>> better served with a simple completing-read (or similar) function to
>> select the "Investigation Type" from a list and then simply insert 
>> that
>> along with a timestamp.  Which it will take you longer to reply to 
>> this
>> email and confirm than it would take me to write such a function.  :)
> 
> Yes, I know about " %^{Investigation Type: |Site
> Stabilization|Heritage Management|Environment Research} %?\n"

I am beginning to suspect you have bigger data and more options than fit
comfortably into a capture template.  I could be wrong, but in my mind
at least, the idea of capture templates is to quickly store small ideas,
notes, TODOs, etc. so you can go back to what you were working on in the
first place, with minimal interruption to your original train of
thought.

> Data can then be parsed into database once we get tho data files at 
> home
> base.

True, however well designed "capture" mechanism (in reality, data
structure) will make this job much easier.

> What sort of thing better than template capture?  My basic idea was to 
> see
> what org tools are available, see what kind of problems me get to, 
> without
> asking too much things specific to us.  We can then work through things
> ourselves.  Perhaps share them with some other organisations.

As I mentioned in last mail, I think Org Properties might be more what
you might be looking for.  You may or may not even need any custom Elisp
in addition to that.

>> [1] https://orgmode.org/manual/Properties-and-Columns.html

Try and just play around with that, create some heading and do
org-set-property and then enter a key and value.  If you want to set a
list to choose from, you put at top of file something like:

#+PROPERTY: Investigation_Type_ALL Site_Stabilize Heritage_Management
#+PROPERTY: District_ALL 1 2 3
#+PROPERTY: Site_Type_ALL Domestic Funerary Water-Related Settlement
[...]

You may need to press C-c C-c within the above to re-load and make it
live.

If you like something like that, it's easy to copy blank template and
just open new one for each survey or whatever you are doing and go from
there.  And then here is where Emacs and Orgmode really shine, as they
are unparalleled as note taking tools.  You can include pictures,
tables, etc. headlines and lists, etc.  But you probably know all that
already.

Cheers,
TRS-80

Re: Org Capture Menu cannot be fully viewed

[pietru]

I have also seen that the following command puts all options
on same line as "Site_Type:", buts puts "Funerary" on a new
line.

 "Site_Type: %^{Site_Type: |default|Domestic|Resource|Transportation|
Funerary|Non-Domestic|Archaeological|Rock Art|Water-Related}\n"


> Sent: Sunday, December 13, 2020 at 5:30 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 22:49, pietru@caramail.com wrote:
> > TRS-80 wrote:
> >>
> >> Are there any more to these templates you did not show?
> >>
> >> Because, (and unless I am missing something) what I see are
> >> essentially
> >> all the same (and quite simple).  You would end up with something like
> >> the following in your target file (with the cursor ending up at the
> >> x):
> >
> > It was an example for long agenda option.  Wanted to send a basic one
> > without the details that could bother you.  The real one will have
> > information regarding Site_Type [Domestic, Funerary, Water-Related,
> > Settlement].  But we don't have the things in org though.
>
> It's no bother.  In fact I am already thinking ahead as to the structure
> of the data, which is the most important consideration.  Choice of
> tool(s) should flow from that, and also from the desired workflow,
> instead of the other way around.
>
> Just so you know, you /could/ have the things in Org, if you wanted to
> (or even in a separate plain text file, and use that as input for your
> narrowing selection list).  Maybe they change, or there are other
> reasons, but you could have the options in a list to choose from.  This
> sort of thing reduce typos and errors.  You could limit to such list
> strictly, or not (the latter allowing flexibility to add things on the
> fly).
>
> >> If all my assumptions above are true, I think you would probably be
> >> better served with a simple completing-read (or similar) function to
> >> select the "Investigation Type" from a list and then simply insert
> >> that
> >> along with a timestamp.  Which it will take you longer to reply to
> >> this
> >> email and confirm than it would take me to write such a function.  :)
> >
> > Yes, I know about " %^{Investigation Type: |Site
> > Stabilization|Heritage Management|Environment Research} %?\n"
>
> I am beginning to suspect you have bigger data and more options than fit
> comfortably into a capture template.  I could be wrong, but in my mind
> at least, the idea of capture templates is to quickly store small ideas,
> notes, TODOs, etc. so you can go back to what you were working on in the
> first place, with minimal interruption to your original train of
> thought.
>
> > Data can then be parsed into database once we get tho data files at
> > home
> > base.
>
> True, however well designed "capture" mechanism (in reality, data
> structure) will make this job much easier.
>
> > What sort of thing better than template capture?  My basic idea was to
> > see
> > what org tools are available, see what kind of problems me get to,
> > without
> > asking too much things specific to us.  We can then work through things
> > ourselves.  Perhaps share them with some other organisations.
>
> As I mentioned in last mail, I think Org Properties might be more what
> you might be looking for.  You may or may not even need any custom Elisp
> in addition to that.
>
> >> [1] https://orgmode.org/manual/Properties-and-Columns.html
>
> Try and just play around with that, create some heading and do
> org-set-property and then enter a key and value.  If you want to set a
> list to choose from, you put at top of file something like:
>
> #+PROPERTY: Investigation_Type_ALL Site_Stabilize Heritage_Management
> #+PROPERTY: District_ALL 1 2 3
> #+PROPERTY: Site_Type_ALL Domestic Funerary Water-Related Settlement
> [...]
>
> You may need to press C-c C-c within the above to re-load and make it
> live.
>
> If you like something like that, it's easy to copy blank template and
> just open new one for each survey or whatever you are doing and go from
> there.  And then here is where Emacs and Orgmode really shine, as they
> are unparalleled as note taking tools.  You can include pictures,
> tables, etc. headlines and lists, etc.  But you probably know all that
> already.
>
> Cheers,
> TRS-80
>
>

Re: Org Capture Menu cannot be fully viewed

[Jean Louis]

* TRS-80 <lists.trs-80@isnotmyreal.name> [2020-12-13 07:31]:
> I am beginning to suspect you have bigger data and more options than fit
> comfortably into a capture template.  I could be wrong, but in my mind
> at least, the idea of capture templates is to quickly store small ideas,
> notes, TODOs, etc. so you can go back to what you were working on in the
> first place, with minimal interruption to your original train of
> thought.

That is really great idea and also as a built-in good as a teaching
jump board for people. It obviously has to be extended to
completing-read function or something better usable than the original
screen made in way how BBS was made back in 1994.

> As I mentioned in last mail, I think Org Properties might be more what
> you might be looking for.  You may or may not even need any custom Elisp
> in addition to that.

That is also another good concept. It also shows that Org mode wish to
become relational database.

> Try and just play around with that, create some heading and do
> org-set-property and then enter a key and value.  If you want to set a
> list to choose from, you put at top of file something like:
> 
> #+PROPERTY: Investigation_Type_ALL Site_Stabilize Heritage_Management
> #+PROPERTY: District_ALL 1 2 3
> #+PROPERTY: Site_Type_ALL Domestic Funerary Water-Related Settlement

That is great tool and I used it to assign Org tasks to people. Since
short time I do not use it any more, as it will become more and more
waste of time with the enlargement of my work. Yet it shows how people
can relate headings to other imaginary objects.

Later, a simple function may iterate over all headings, capture the
headings and insert into different type of databases. Of course all
hard coded properties have to be matched by the function as well to
the other database fields.

> You may need to press C-c C-c within the above to re-load and make it
> live.

Sad is that computer does not think about that for human. When
abandoning this line #+PROPERTY: update properties...

> If you like something like that, it's easy to copy blank template and
> just open new one for each survey or whatever you are doing and go from
> there.  And then here is where Emacs and Orgmode really shine, as they
> are unparalleled as note taking tools.  You can include pictures,
> tables, etc. headlines and lists, etc.  But you probably know all that
> already.

Hmm, ok fine, I see you like Emacs, me too. But not as much to be
blind that other ways of note taking do not exist.

I would like that it shines, but is not user friendly compared to
other tools. It is our beloed mode within Emacs, yet I do not see how
it is unparalleled to everything else that exists. One good result of
Org mode as buggy software is that many people start learning
programming.

The shiny software:

Leo editor vs Org-mode
https://leoeditor.com/emacs.html

Leo programmable editor -- really inspired by Org mode, supports code
execution and much better hyperlinking of elementary objects. Shines.
http://leoeditor.com/

Cherrytree - hierarchical note taking application with rich text and
syntax highlighting. Supports code execution like Org babel and
exports to plethora of formats. Shines.
https://www.giuspen.com/cherrytree/

Joplin -- shines
https://joplinapp.org/

Turtleapp note taking application, shines.
https://turtlapp.com/download/


Let us shine.

Re: Org Capture Menu cannot be fully viewed

[Jean Louis]

* pietru@caramail.com <pietru@caramail.com> [2020-12-13 06:51]:
> > Are there any more to these templates you did not show?

I was thinking some users will get surprised on this. They may even
say it is not necessary.

I have 1148 sets where I am capturing different
information. Imagine if I would be spending my time adjusting
what is not adjustable. Or spending time in configuring entries
and system asks me to assign "key" to the template. Which flaming
key?!

> > Because, (and unless I am missing something) what I see are essentially
> > all the same (and quite simple).  You would end up with something like
> > the following in your target file (with the cursor ending up at the x):
> 
> It was an example for long agenda option.  Wanted to send a basic one
> without the details that could bother you.  The real one will have information
> regarding Site_Type [Domestic, Funerary, Water-Related, Settlement].  But we
> don't have the things in org though.

It allos speaks loud that you need not a key based filing but semantic
based filing.

If we have few templates like 5-10 templates, key based filing is
fine.

If we have 20-50 or 1148 places where to sort captured note than we
need a larger list type of a menu or filtering functions, completing
functions with the semantic search.

Initially bad design corrupts user's habits to now start thinking of
"keys" instead of thinking of meanings like "domestic" "historical"
"background" and similar. Writing "dom his bac" would probably find
what you mean, and if not, similar candidates could be shown along.

I feel inclined to write a completing read function but on the other
hand I do not find it as a true solution.

> What sort of thing better than template capture?  My basic idea was
> to see what org tools are available, see what kind of problems me
> get to, without asking too much things specific to us.  We can then
> work through things ourselves.  Perhaps share them with some other
> organisations.

While your work is totally understandable and logical and reasonable
it obviously cannot be handled with Org capture easily.

If you would be fine not to use those heading templates, maybe a
simple completion list of files where you wish to capture something
would be enough.

;; Create hash
(setq my-files-hash (make-hash-table))

;; Try putting something into the hash, define your files and their meanings
(puthash (intern "One file") "~/tmp/new.org" my-files-hash)
(puthash (intern "Something else") "~/tmp/else.org" my-files-hash)
;; You could continue feeding various files while only making sure
;; that they description differ from each other

;; Take it back from hash to verify
(gethash (intern "Something else") my-files-hash)
"~/tmp/else.org"

;; Construct list of semantic meanings of those files
(hash-table-keys my-files-hash)
=> (One\ file Something\ else)

(defun my-capture ()
  (interactive)
  (let* ((my-files (hash-table-keys my-files-hash))
	 (my-files (mapcar #'symbol-name my-files))
	 (my-selection (completing-read "File to capture: " my-files))
	 (my-selected-file (gethash (intern my-selection) my-files-hash)))
    (when selected-file
      (find-file selected-file)
      (goto-char (point-max))
      (insert "\n")
      (insert ** ))))

Now the function would let you choose semantic description. You
could use ivy-mode for basic relevance search. It would help you
choose "back" and "hist" for some historical background. It would
then open your Org file and move you to the end of it and prepare
heading.

But it does not include heading templates. When I look into Org
capture I do not find to me expected functional style of
programming so right now I would not know where to start to
implement the template. At least this way you could quickly
choose among large number of files, and insert the entry on the
end of the file.

I am not sure of Org capture used the built-in Emacs skeleton
templates. But that is something I could rather think of.

Then I would define various skeleton templates like:

(define-skeleton my-template-1
  "Prepares template"
  nil
  "** " (skeleton-read "Heading: ") "

  URL: " (skeleton-read "URL: ") "
  ")

Such can be invoked from M-x my-template-1

then something like:

(puthash (intern "Something else") '("~/tmp/else.org" my-template-1) my-files-hash)

would define that the file "Something else" is using the skeleton
template. This way all templates become separate and reusable for various files.

Then the function would be enhanced:

(defun my-capture ()
  (interactive)
  (let* ((my-files (hash-table-keys my-files-hash))
	 (my-files (mapcar #'symbol-name my-files))
	 (my-selection (completing-read "File to capture: " my-files))
	 (data (gethash (intern my-selection) my-files-hash))
	 (selected-file (car data))
	 (template (cadr data)))
    (when selected-file
      (find-file selected-file)
      (goto-char (point-max))
      (insert "\n")
      (call-interactively template))))

Then by calling my-capture you are semantically choosing where to
file, and you may have unlimited number of files and
corresponding template is also chosen automatically for you. You
may edit templates separately from files.

It would be trivial to even choose a different template at time
of capturing.

Jean

Re: Org Capture Menu cannot be fully viewed

[pietru]

> Sent: Sunday, December 13, 2020 at 11:24 AM
> From: "Jean Louis" <bugs@gnu.support>
> To: pietru@caramail.com
> Cc: "TRS-80" <lists.trs-80@isnotmyreal.name>, emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> * pietru@caramail.com <pietru@caramail.com> [2020-12-13 06:51]:
> > > Are there any more to these templates you did not show?
>
> I was thinking some users will get surprised on this. They may even
> say it is not necessary.
>
> I have 1148 sets where I am capturing different
> information. Imagine if I would be spending my time adjusting
> what is not adjustable. Or spending time in configuring entries
> and system asks me to assign "key" to the template. Which flaming
> key?!
>
> > > Because, (and unless I am missing something) what I see are essentially
> > > all the same (and quite simple).  You would end up with something like
> > > the following in your target file (with the cursor ending up at the x):
> >
> > It was an example for long agenda option.  Wanted to send a basic one
> > without the details that could bother you.  The real one will have information
> > regarding Site_Type [Domestic, Funerary, Water-Related, Settlement].  But we
> > don't have the things in org though.
>
> It allos speaks loud that you need not a key based filing but semantic
> based filing.
>
> If we have few templates like 5-10 templates, key based filing is
> fine.
>
> If we have 20-50 or 1148 places where to sort captured note than we
> need a larger list type of a menu or filtering functions, completing
> functions with the semantic search.

Haven't ever exceeded 21.

> Initially bad design corrupts user's habits to now start thinking of
> "keys" instead of thinking of meanings like "domestic" "historical"
> "background" and similar. Writing "dom his bac" would probably find
> what you mean, and if not, similar candidates could be shown along.

> I feel inclined to write a completing read function but on the other
> hand I do not find it as a true solution.
>
> > What sort of thing better than template capture?  My basic idea was
> > to see what org tools are available, see what kind of problems me
> > get to, without asking too much things specific to us.  We can then
> > work through things ourselves.  Perhaps share them with some other
> > organisations.
>
> While your work is totally understandable and logical and reasonable
> it obviously cannot be handled with Org capture easily.
>
> If you would be fine not to use those heading templates, maybe a
> simple completion list of files where you wish to capture something
> would be enough.

It would be beneficial to extend "%:keyword".  This way we can capture
data from a project file.  Someone suggested, getting keyword values from
recfiles (defined in Gnu Recutils).  That would be quick to accomplish in
the  field.

> ;; Create hash
> (setq my-files-hash (make-hash-table))
>
> ;; Try putting something into the hash, define your files and their meanings
> (puthash (intern "One file") "~/tmp/new.org" my-files-hash)
> (puthash (intern "Something else") "~/tmp/else.org" my-files-hash)
> ;; You could continue feeding various files while only making sure
> ;; that they description differ from each other
>
> ;; Take it back from hash to verify
> (gethash (intern "Something else") my-files-hash)
> "~/tmp/else.org"
>
> ;; Construct list of semantic meanings of those files
> (hash-table-keys my-files-hash)
> => (One\ file Something\ else)
>
> (defun my-capture ()
>   (interactive)
>   (let* ((my-files (hash-table-keys my-files-hash))
> 	 (my-files (mapcar #'symbol-name my-files))
> 	 (my-selection (completing-read "File to capture: " my-files))
> 	 (my-selected-file (gethash (intern my-selection) my-files-hash)))
>     (when selected-file
>       (find-file selected-file)
>       (goto-char (point-max))
>       (insert "\n")
>       (insert ** ))))
>
> Now the function would let you choose semantic description. You
> could use ivy-mode for basic relevance search. It would help you
> choose "back" and "hist" for some historical background. It would
> then open your Org file and move you to the end of it and prepare
> heading.
>
> But it does not include heading templates. When I look into Org
> capture I do not find to me expected functional style of
> programming so right now I would not know where to start to
> implement the template. At least this way you could quickly
> choose among large number of files, and insert the entry on the
> end of the file.
>
> I am not sure of Org capture used the built-in Emacs skeleton
> templates. But that is something I could rather think of.
>
> Then I would define various skeleton templates like:
>
> (define-skeleton my-template-1
>   "Prepares template"
>   nil
>   "** " (skeleton-read "Heading: ") "
>
>   URL: " (skeleton-read "URL: ") "
>   ")
>
> Such can be invoked from M-x my-template-1
>
> then something like:
>
> (puthash (intern "Something else") '("~/tmp/else.org" my-template-1) my-files-hash)
>
> would define that the file "Something else" is using the skeleton
> template. This way all templates become separate and reusable for various files.
>
> Then the function would be enhanced:
>
> (defun my-capture ()
>   (interactive)
>   (let* ((my-files (hash-table-keys my-files-hash))
> 	 (my-files (mapcar #'symbol-name my-files))
> 	 (my-selection (completing-read "File to capture: " my-files))
> 	 (data (gethash (intern my-selection) my-files-hash))
> 	 (selected-file (car data))
> 	 (template (cadr data)))
>     (when selected-file
>       (find-file selected-file)
>       (goto-char (point-max))
>       (insert "\n")
>       (call-interactively template))))
>
> Then by calling my-capture you are semantically choosing where to
> file, and you may have unlimited number of files and
> corresponding template is also chosen automatically for you. You
> may edit templates separately from files.
>
> It would be trivial to even choose a different template at time
> of capturing.


I have to take some time to chew into this.

> Jean
>

Re: Org Capture Menu cannot be fully viewed

[TRS-80]

On 2020-12-13 13:41, pietru@caramail.com wrote:
>> From: "Jean Louis" <bugs@gnu.support>
>> 
>> ;; Create hash
>> (setq my-files-hash (make-hash-table))
>> 
>> ;; Try putting something into the hash, define your files and their 
>> meanings
>> (puthash (intern "One file") "~/tmp/new.org" my-files-hash)
>> (puthash (intern "Something else") "~/tmp/else.org" my-files-hash)
>> ;; You could continue feeding various files while only making sure
>> ;; that they description differ from each other
>> 
>> ;; Take it back from hash to verify
>> (gethash (intern "Something else") my-files-hash)
>> "~/tmp/else.org"
>> 
>> ;; Construct list of semantic meanings of those files
>> (hash-table-keys my-files-hash)
>> => (One\ file Something\ else)
>> 
>> (defun my-capture ()
>>   (interactive)
>>   (let* ((my-files (hash-table-keys my-files-hash))
>> 	 (my-files (mapcar #'symbol-name my-files))
>> 	 (my-selection (completing-read "File to capture: " my-files))
>> 	 (my-selected-file (gethash (intern my-selection) my-files-hash)))
>>     (when selected-file
>>       (find-file selected-file)
>>       (goto-char (point-max))
>>       (insert "\n")
>>       (insert ** ))))
>> 
> 
> I have to take some time to chew into this.
> 
>> Jean
>> 

All due respect, particularly for such an effort, however I think Jean
Louis' solution is far too complex, especially for someone not well
versed in Elisp.  Which I am still assuming, as Pietru have not
explicitly stated so (or not) yet.

My path of questioning was trying to draw out relevent info, with the
end goal of suggesting the right solution.  If that solution is a simple
completing-read then so be it but I am not even sure we have determined
that is the correct (or preferred) solution yet.

In particular, hash tables are not needed with the sorts of numbers of
candidates I think we are talking about here.

Cheers,
TRS-80

Re: Org Capture Menu cannot be fully viewed

[pietru]

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

Most agencies, universities, museums and archaeological organizations use
standard forms for recording sites. Generally speaking these are used but
with a couple of caveats.  First, there are occasions when a standard form
may not call for recording enough data or the right kinds of data to satisfy
particular needs.  Then there are Exclusive Surveys (Incomplete coverage,
portions of the project are excluded) and Unsystematic Surveys (done without
a specific plan, methods at varied level of intensity; coverage random,
opportunistic, or intuitive). In many instances, previous work would have
been done, so people would want to quickly skip entries.

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.  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.  Still, most things are likely
to be done by the "Institute for Technologies applied to Cultural Heritage (itabc)".

Nevertheless, we see some aspects where your scheme can be improved to cater for more
serious work.  Emacs is quite good software.

Hope my comments helped somewhat.

Pietru





> Sent: Sunday, December 13, 2020 at 4:16 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 21:08, pietru@caramail.com wrote:
> > Here is one version of a template
> >
> > (setq capture-template-investigation-type '(
> >
> >  ("a" "Historic Background Research Site Evaluation/Testing" entry
> >   (file "~/histr/archaeol.org")
> >   "* Site_Type: %?\n %T\n")
> >
> > [...]
> >
> >  ("u" "Remote Sensing" entry
> >   (file "~/histr/archaeol.org")
> >   "* Site_Type: %?\n %T\n") ))
> >
>
> Are there any more to these templates you did not show?
>
> Because, (and unless I am missing something) what I see are essentially
> all the same (and quite simple).  You would end up with something like
> the following in your target file (with the cursor ending up at the x):

> #+begin_example
>
> * Site_Type: x
> [2020-12-12 Sat 21:58]
>
> #+end_example
>
> In fact I don't even see where the type name ends up in the result?
>
> If all my assumptions above are true, I think you would probably be
> better served with a simple completing-read (or similar) function to
> select the "Investigation Type" from a list and then simply insert that
> along with a timestamp.  Which it will take you longer to reply to this
> email and confirm than it would take me to write such a function.  :)
>
> Benefit of that way also removes possibility of typos in the type name.
>
> In fact, the above could even be done with something as simple as
> Yankpad[0].
>
> I have no idea what your workflow looks like, or where this data ends
> up.  However, thinking further, I would imagine it might even be helpful
> to set one or more Org properties[1] for things like "Investigation
> Type" (along with some other things I could speculate like "Location"
> etc.).  But all of that depends on even more things I don't know about.
>
> 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.
>
> Cheers,
> TRS-80
>
> [0] https://github.com/Kungsgeten/yankpad
> [1] https://orgmode.org/manual/Properties-and-Columns.html
>
>

Re: Org Capture Menu cannot be fully viewed

[Christopher Dimech]

Org Capture has the ability to get specific information
using "%:keyword" (e.g., for rmail one can use %:subject
to get the specific email subject).

An extension to "%:keyword", would be to allow the extraction of
keywords taken from recfiles, which are also text based.

You could then have %:Investigation_Type in Org-Capture entry.
There needs to be some way to specify the recfile.

The specification of recfiles is described by Gnu Recutils.
https://www.gnu.org/software/recutils/

----- file.rec -----
Investigation_Type: Historic Background Research Site Evaluation/Testing
----- file.rec -----

This could make easier capture because instead of
%^{prompt|default|completion2|completion3...}

you could have

%:Site_Type

The scheme would work very well if you have hierarchical
lists that you can use for specificity.

Domestic Structure > Settlement > Hamlet or Village

%:Domestic_Structure: %:Settlement\n

----- file.rec -----
Domestic_Structure: Settlement
Settlement: Hamlet or Village
----- file.rec -----

rather than using

    "Site_Type: %^{Site_Type: |default|
+ Domestic Structure or Architectural Complex|
+ Resource Extraction or Production|
+ Transportation Structure or Features|
+ Funerary and Burial Structures or Features|
+ Non-Domestic Structures|
+ Archaeological Feature|
+ Rock Art|
+ Water-Related}\n%?"



> Sent: Sunday, December 13, 2020 at 5:57 AM
> From: pietru@caramail.com
> To: "TRS-80" <lists.trs-80@isnotmyreal.name>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> > 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.
>
> Most agencies, universities, museums and archaeological organizations use
> standard forms for recording sites. Generally speaking these are used but
> with a couple of caveats.  First, there are occasions when a standard form
> may not call for recording enough data or the right kinds of data to satisfy
> particular needs.  Then there are Exclusive Surveys (Incomplete coverage,
> portions of the project are excluded) and Unsystematic Surveys (done without
> a specific plan, methods at varied level of intensity; coverage random,
> opportunistic, or intuitive). In many instances, previous work would have
> been done, so people would want to quickly skip entries.
>
> 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.  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.  Still, most things are likely
> to be done by the "Institute for Technologies applied to Cultural Heritage (itabc)".
>
> Nevertheless, we see some aspects where your scheme can be improved to cater for more
> serious work.  Emacs is quite good software.
>
> Hope my comments helped somewhat.
>
> Pietru
>
>
>
>
>
> > Sent: Sunday, December 13, 2020 at 4:16 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 21:08, pietru@caramail.com wrote:
> > > Here is one version of a template
> > >
> > > (setq capture-template-investigation-type '(
> > >
> > >  ("a" "Historic Background Research Site Evaluation/Testing" entry
> > >   (file "~/histr/archaeol.org")
> > >   "* Site_Type: %?\n %T\n")
> > >
> > > [...]
> > >
> > >  ("u" "Remote Sensing" entry
> > >   (file "~/histr/archaeol.org")
> > >   "* Site_Type: %?\n %T\n") ))
> > >
> >
> > Are there any more to these templates you did not show?
> >
> > Because, (and unless I am missing something) what I see are essentially
> > all the same (and quite simple).  You would end up with something like
> > the following in your target file (with the cursor ending up at the x):
>
> > #+begin_example
> >
> > * Site_Type: x
> > [2020-12-12 Sat 21:58]
> >
> > #+end_example
> >
> > In fact I don't even see where the type name ends up in the result?
> >
> > If all my assumptions above are true, I think you would probably be
> > better served with a simple completing-read (or similar) function to
> > select the "Investigation Type" from a list and then simply insert that
> > along with a timestamp.  Which it will take you longer to reply to this
> > email and confirm than it would take me to write such a function.  :)
> >
> > Benefit of that way also removes possibility of typos in the type name.
> >
> > In fact, the above could even be done with something as simple as
> > Yankpad[0].
> >
> > I have no idea what your workflow looks like, or where this data ends
> > up.  However, thinking further, I would imagine it might even be helpful
> > to set one or more Org properties[1] for things like "Investigation
> > Type" (along with some other things I could speculate like "Location"
> > etc.).  But all of that depends on even more things I don't know about.
> >
> > 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.
> >
> > Cheers,
> > TRS-80
> >
> > [0] https://github.com/Kungsgeten/yankpad
> > [1] https://orgmode.org/manual/Properties-and-Columns.html
> >
> >
>
>

---------------------
Christopher Dimech
General Administrator - Naiad Informatics - GNU Project (Geocomputation)
- Geophysical Simulation
- Geological Subsurface Mapping
- Disaster Preparedness and Mitigation
- Natural Resource Exploration and Production
- Free Software Advocacy

Re: Org Capture Menu cannot be fully viewed

[TRS-80]

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.

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.

> 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.
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?"  ;)

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

> Hope my comments helped somewhat.

Yes, I think so.  Hopefully my replies will therefore heve been equally
helpful to you.

Cheers,
TRS-80

Re: Org Capture Menu cannot be fully viewed

[pietru]

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

Re: Org Capture Menu cannot be fully viewed

[Jean Louis]

* pietru@caramail.com <pietru@caramail.com> [2020-12-13 05:09]:
> Here is one version of a template
> 
> (setq capture-template-investigation-type '(
> 
>  ("a" "Historic Background Research Site Evaluation/Testing" entry
>   (file "~/histr/archaeol.org")
>   "* Site_Type: %?\n %T\n")
> 
>  ("b" "Systematic Survey Data Recovery/Excavation" entry
>   (file "~/histr/archaeol.org")
>   "* Site_Type: %?\n %T\n")

Your example is good real world practical example.

The capture menu was designed in the same degraded way as Org agenda
menu. Difference is that Capture menu is customizable and not meant
for users like you who need more than few categories. It is not
expandable.

Would the menu be made as read only Org displayed in a buffer then:

- Emacs interface, such as using other windows during capture process,
  would not be blocked during Capture selection

- User could at least scroll or enlarge the buffer what currently does
  not work

Comparing it to my Hyperscope system if I wish to file or capture
anything I may choose any set where to file it by using completion
function which dwelles below in `hyperscope-select-set'. I am using
semantic or meaning related search.

(defun hyperscope-add-note-to-set ()
  (interactive)
  (let ((parent (hyperscope-select-set)))
    (hlink-add-generic name nil 9 parent nil note)))

When key press is invoked I am capturing a note or some other type of
a node into a set. Could be anything, it could be URL, Action similar
to TODO, note, file, picture, voice note, just anything:

- press key

- type what you think where it should be filed, press ENTER on selection

- edit the note

Description of `org-capture'

org-capture is an autoloaded interactive compiled Lisp function in
‘org-capture.el’.

It is bound to C-c c.

(org-capture &optional GOTO KEYS)

Capture something.

This will let you select a template from ‘org-capture-templates’, and
then file the newly captured information.  The text is immediately
inserted at the target location, and an indirect buffer is shown where
you can edit it.  Pressing ‘C-c C-c’ brings you back to the previous
state of Emacs, so that you can continue your work.

-----------

In your case "This will NOT let you select a template from
org-capture-template". Function org-capture is written more in
structured way of programming than functional way. It wants to do
everything for user at once.

https://en.wikipedia.org/wiki/Structured_programming
versus
https://en.wikipedia.org/wiki/Functional_programming

What is here missing is `org-capture-by-completing-read' so that
user may select among many various capture templates.

Compensating for initial bad design is expensive effort.

Jean

Re: Org Capture Menu cannot be fully viewed

[Christopher Dimech]

> Sent: Sunday, December 13, 2020 at 10:44 AM
> From: "Jean Louis" <bugs@gnu.support>
> To: pietru@caramail.com
> Cc: "Tim Cross" <theophilusx@gmail.com>, emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> * pietru@caramail.com <pietru@caramail.com> [2020-12-13 05:09]:
> > Here is one version of a template
> > 
> > (setq capture-template-investigation-type '(
> > 
> >  ("a" "Historic Background Research Site Evaluation/Testing" entry
> >   (file "~/histr/archaeol.org")
> >   "* Site_Type: %?\n %T\n")
> > 
> >  ("b" "Systematic Survey Data Recovery/Excavation" entry
> >   (file "~/histr/archaeol.org")
> >   "* Site_Type: %?\n %T\n")
> 
> Your example is good real world practical example.
> 
> The capture menu was designed in the same degraded way as Org agenda
> menu. Difference is that Capture menu is customizable and not meant
> for users like you who need more than few categories. It is not
> expandable.
> 
> Would the menu be made as read only Org displayed in a buffer then:
> 
> - Emacs interface, such as using other windows during capture process,
>   would not be blocked during Capture selection
> 
> - User could at least scroll or enlarge the buffer what currently does
>   not work
> 
> Comparing it to my Hyperscope system if I wish to file or capture
> anything I may choose any set where to file it by using completion
> function which dwelles below in `hyperscope-select-set'. I am using
> semantic or meaning related search.
> 
> (defun hyperscope-add-note-to-set ()
>   (interactive)
>   (let ((parent (hyperscope-select-set)))
>     (hlink-add-generic name nil 9 parent nil note)))
> 
> When key press is invoked I am capturing a note or some other type of
> a node into a set. Could be anything, it could be URL, Action similar
> to TODO, note, file, picture, voice note, just anything:
> 
> - press key
> 
> - type what you think where it should be filed, press ENTER on selection
> 
> - edit the note
> 
> Description of `org-capture'
> 
> org-capture is an autoloaded interactive compiled Lisp function in
> ‘org-capture.el’.
> 
> It is bound to C-c c.
> 
> (org-capture &optional GOTO KEYS)
> 
> Capture something.
> 
> This will let you select a template from ‘org-capture-templates’, and
> then file the newly captured information.  The text is immediately
> inserted at the target location, and an indirect buffer is shown where
> you can edit it.  Pressing ‘C-c C-c’ brings you back to the previous
> state of Emacs, so that you can continue your work.
> 
> -----------
> 
> In your case "This will NOT let you select a template from
> org-capture-template". Function org-capture is written more in
> structured way of programming than functional way. It wants to do
> everything for user at once.
> 
> https://en.wikipedia.org/wiki/Structured_programming
> versus
> https://en.wikipedia.org/wiki/Functional_programming
> 
> What is here missing is `org-capture-by-completing-read' so that
> user may select among many various capture templates.
> 
> Compensating for initial bad design is expensive effort.

It looks that way. 
 
> Jean
> 

---------------------
Christopher Dimech
General Administrator - Naiad Informatics - GNU Project (Geocomputation)
- Geophysical Simulation
- Geological Subsurface Mapping
- Disaster Preparedness and Mitigation
- Natural Resource Exploration and Production
- Free Software Advocacy

Re: Org Capture Menu cannot be fully viewed

[No Wayman]

> What is here missing is `org-capture-by-completing-read' so that
> user may select among many various capture templates.

> Compensating for initial bad design is expensive effort.

Are you suggesting something like this?:

#+begin_src emacs-lisp
(defun +org-capture-read (&optional arg)
  "completing read interface for org-capture template selection.
ARG is passed to `org-capture'."
  (let (parent)
    (when-let* ((templates
                 (mapcar (lambda (template)
                           (let* ((keys (car template))
                                  (parentkeys (car parent)))
                             (if (= (length template) 2)
                                 (progn (setq parent template) 
                                 nil)
                               (cons (concat (when (and parentkeys 
                               (string-prefix-p parentkeys keys))
                                               (concat (cadr 
                                               parent) "/"))
                                             (cadr template))
                                     keys))))
                         org-capture-templates))
                (selection (alist-get
                            (completing-read "capture template: "
                                             (mapcar #'car (delq 
                                             nil templates))
                                             nil 'require-match)
                            templates
                            nil nil
                            #'string=)))
      (org-capture arg selection))))
#+end_src emacs-lisp

Re: Org Capture Menu cannot be fully viewed

[No Wayman]

Pietru:

If you are extensively using Org's capture templates I suggest 
taking a look at:

https://github.com/progfolio/doct

A brief summary of some of the benefits it provides:

- Allows capture template inheritance
- Checks for certain errors in template declarations *before* 
  capture.
- Automatically computes the keys for nested menus
- Makes per-template hooks/contexts easy to declare.
- Allows for storing custom metadata with templates which can be 
  used within templates
- Declarative: Your template declarations will be easier to 
  read/share.

Taking the list of templates provided earlier as an example,
It could utilize nested menus/inheritance like so:

#+begin_src emacs-lisp :lexical t
(doct
 '( :group "Archaeology"
    :file "~/histr/archaeol.org"
    :template "* Site_Type: %?\n %T\n"
    :children (("Research" :keys "r"
                :children (("Bioarchaeological"     :keys "b")
                           ("Collections"           :keys "c")
                           ("Design/Data Recovery"  :keys "d")
                           ("Environment"           :keys "e")
                           ("Ethnographic"          :keys "g")
                           ("Ethnohistoric"         :keys "h")
                           ("Historic Eval/Testing" :keys "t")))
               ("Survey" :keys "s"
                :children (("Architectural"       :keys "a")
                           ("Geophysical"         :keys "g")
                           ("Reconnaissance"      :keys "r")
                           ("Recovery/Excavation" :keys "R")))
               ("Consultation"                      :keys "c")
               ("Architectural Documentation"       :keys "d")
               ("Site Stabilization"                :keys "e")
               ("Ground Disturbance Monitoring"     :keys "g")
               ("Heritage Management"               :keys "h")
               ("Records Search/Inventory Checking" :keys "i")
               ("Methodology, Theory, Synthesis"    :keys "m")
               ("Archaeological Overview"           :keys "o")
               ("Remote Sensing"                    :keys "R")
               ("Site Stewardship Monitoring"       :keys "d"))))
#+end_src

Each template inherits the :file and :template values.
The keys for the "Research" and "Survey" children templates are 
computed by doct,
so changing the whole groups prefix key only requires a change on 
the parent template's :keys.

I haven't demoed the custom metadata in this example as I don't 
know your exact use case,
but there is an example in the documentation:

https://github.com/progfolio/doct#custom-data


Hope this is useful for you.

~ Nick

Re: Org Capture Menu cannot be fully viewed

[Jean Louis]

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

Re: Org Capture Menu cannot be fully viewed

[pietru]

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

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

Re: Org Capture Menu cannot be fully viewed

[Tim Cross]

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

Re: Org Capture Menu cannot be fully viewed

[pietru]

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

Re: Org Capture Menu cannot be fully viewed

[Bastien]

Hi Tim and Jean,

Tim Cross <theophilusx@gmail.com> writes:

> I have no clue as to why your dragging Emacs custom into this
> discussion.

I agree with Tim.

Let's keep in mind we are more than 2000 subscribers here and make an
effort of not letting our conversations drift too much.

In-depth analyses are welcome on this list as long as we are trying to
stay on-topic.  Each message on a forum is a call for attention, let's
use it with parsimony and consideration for everyone's time.

-- 
 Bastien

Re: Org Capture Menu cannot be fully viewed

[pietru]

> Sent: Sunday, December 13, 2020 at 10:57 PM
> From: "Bastien" <bzg@gnu.org>
> To: "Tim Cross" <theophilusx@gmail.com>
> Cc: emacs-orgmode@gnu.org, "Jean Louis" <bugs@gnu.support>
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> Hi Tim and Jean,
>
> Tim Cross <theophilusx@gmail.com> writes:
>
> > I have no clue as to why your dragging Emacs custom into this
> > discussion.
>
> I agree with Tim.
>
> Let's keep in mind we are more than 2000 subscribers here and make an
> effort of not letting our conversations drift too much.
>
> In-depth analyses are welcome on this list as long as we are trying to
> stay on-topic.  Each message on a forum is a call for attention, let's
> use it with parsimony and consideration for everyone's time.
>

I really don't have more to add.

In summary

1. Org-Capture Flexibility on Menu Buffer.
2. Completion of Expressions from Capture Entry or separate file
   (e.g. taken from recutils fields in a rec file) to Org File.
3. Selecting only a subset of fields from template for display
   and entry to org file.

Then see how things go.  If there is interest of course.

> --
>  Bastien
>
>

Re: Org Capture Menu cannot be fully viewed

[Jean Louis]

* Bastien <bzg@gnu.org> [2020-12-14 01:00]:
> Hi Tim and Jean,
> 
> Tim Cross <theophilusx@gmail.com> writes:
> 
> > I have no clue as to why your dragging Emacs custom into this
> > discussion.
> 
> I agree with Tim.
> 
> Let's keep in mind we are more than 2000 subscribers here and make an
> effort of not letting our conversations drift too much.
> 
> In-depth analyses are welcome on this list as long as we are trying to
> stay on-topic.  Each message on a forum is a call for attention, let's
> use it with parsimony and consideration for everyone's time.

I would also gladly agree if there would be a solution for long list
of templates. But there isn't.

Discussion is brainstorming that may or may not lead to solutions.

Re: Org Capture Menu cannot be fully viewed

[Bastien]

Jean Louis <bugs@gnu.support> writes:

> Discussion is brainstorming that may or may not lead to solutions.

This list is not a place for brainstorming.

Sharing very long emails too frequently might scare other readers
away, discouraging them to participate to a constructive discussion.

Please make an effort to write shorter emails less frequently.

-- 
 Bastien

Re: Org Capture Menu cannot be fully viewed

[Jean Louis]

* Tim Cross <theophilusx@gmail.com> [2020-12-13 23:49]:
> > 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.

It is double work:

- user already has files which is accessing and using, those are most
  probably files where captured notes need to go

- org agenda already indexed most of files including headings

- org capture defeats its purpose with more then few templates, then
  it could be better sorting it right away in proper file. If that is
  right for user like me

- defining custom templates is double work and left to user, instead
  to computer, to calculate it for user. The more templates there are
  the more hand work user does for computer. It is definitely related
  to the speed and efficiency.

The discussion is brainstorming. It may lead to useful selection
of templates where to store notes. Definition of those templates
allows for many various selections by ID, file+heading,
file+regexp etc. Now any enhancement is rather type of a glue
than well designed solution. It looks to me most logical to use
the key and the description to choose the template, as that is
what each template alreadu has:

(defvar my-capture-template-history nil)

(defun my-capture-choice ()
  (interactive)
  (let* ((collection '())
	 (collection (dolist (item org-capture-templates collection)
		       (let* ((key (elt item 0))
			      (description (elt item 1))
			      (headline (car (elt item 3)))
			      (headline (if (string-match "headline"
							 (symbol-name headline))
					    (concat " > " (elt (elt item 3) 2))
					 ""))
			      (item (concat description " " headline " [" key "]")))
			 (push item collection)))))
    (completing-read "Capture to: " collection nil t nil 'my-capture-template-history)))

That function can already choose one among many templates by
using completion. But it shows collection in some peculiar way
with keys being within [] so that by using completion such as
ivy, user would need to enter: [KEY instead of just key. In
standard completion user would need to enter *[KEY and press TAB
to reach to heading/template by using a key.

Key could be used within [KEY] to find the actual org capture
template programmatically from the selection.

The selection would look like:

Protocol Link > Inbox [L]

Following function must programmatically understand what is the
key L within the selected string: "Protocol Link > Inbox [L]"

(defun string-cut-right-square-bracket-reference (s)
  "Returns the reference within square brackets on the end of S."
  (let* ((space (string-match " " (reverse s))))
    (if space
	(let* ((id (substring (reverse s) 0 space)))
	  (if (and (string-match "\\[" id)
		   (string-match "\\]" id))
	      (replace-regexp-in-string "\\[\\\|\\]" "" (reverse id))
	    nil))
      nil)))

(string-cut-right-square-bracket-reference "Protocol Link > Inbox [L]")
"L"

So it can find the key L from the selection of Org templates.

Then `org-capture' function already allows for the key to be
selected, thus running it as (org-capture nil "L") leads user by
the selected key to the proper template.

Putting it together is this:

(defvar my-capture-template-history nil)

(defun my-capture-choice ()
  (let* ((collection '())
	 (collection (dolist (item org-capture-templates collection)
		       (let* ((key (elt item 0))
			      (description (elt item 1))
			      (headline (car (elt item 3)))
			      (headline (if (string-match "headline"
							 (symbol-name headline))
					    (concat " > " (elt (elt item 3) 2))
					 ""))
			      (item (concat description " " headline " [" key "]")))
			 (push item collection)))))
    (completing-read "Capture to: " collection nil t nil 'my-capture-template-history)))

(defun string-cut-right-square-bracket-reference (s)
  "Returns the reference within square brackets on the end of S."
  (let* ((space (string-match " " (reverse s))))
    (if space
	(let* ((id (substring (reverse s) 0 space)))
	  (if (and (string-match "\\[" id)
		   (string-match "\\]" id))
	      (replace-regexp-in-string "\\[\\\|\\]" "" (reverse id))
	    nil))
      nil)))

(defun my-completing-org-capture ()
  (interactive)
  (let* ((my-capture-choice (my-capture-choice))
	 (my-key (string-cut-right-square-bracket-reference my-capture-choice)))
    (when my-key
      (org-capture nil my-key))))

Then user can bind `my-completing-org-capture' to some key to
quickly capture items by using completion. So Pietrum, you can try
using this solution.

Or run M-x my-completing-org-capture

This is not perfect function but I just guess it should work well
for people who have many templates with headlines.

Jean

Re: Org Capture Menu cannot be fully viewed

[Marco Wahl]

Hi Pietru and 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.

Thanks for reporting.

I just committed a fix along the lines of the similar exporter-UI and
the agenda chooser-UI. Now there is at least C-n, C-p, C-v when the
window is too small for all the items.

Unfortunately these similar UIs are not unified when looking at the code
base. E.g. I could not find a simple way to add key M-v to scroll one
page up for the capture menu.

Possibly these UIs could be unified or Org could even switch to
something different. I think you already discussed some ideas. Sorry if
I did not read the whole thread. That was too much information for me.

Would be great if you could check out the fix.


Thanks and HTH,
--
Marco

Re: Org Capture Menu cannot be fully viewed

[pietru]

> Sent: Monday, December 14, 2020 at 1:41 PM
> From: "Marco Wahl" <marcowahlsoft@gmail.com>
> To: pietru@caramail.com
> Cc: "Org-Mode mailing list" <emacs-orgmode@gnu.org>
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> Hi Pietru and 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.
>
> Thanks for reporting.
>
> I just committed a fix along the lines of the similar exporter-UI and
> the agenda chooser-UI. Now there is at least C-n, C-p, C-v when the
> window is too small for all the items.
>
> Unfortunately these similar UIs are not unified when looking at the code
> base. E.g. I could not find a simple way to add key M-v to scroll one
> page up for the capture menu.
>
> Possibly these UIs could be unified or Org could even switch to
> something different. I think you already discussed some ideas. Sorry if
> I did not read the whole thread. That was too much information for me.

Don't worry about it.  I thank you for taking an interest towards a fix.

> Would be great if you could check out the fix.

Of coarse.  Is the following command the right way to get the fix
for testing?

git clone https://code.orgmode.org/bzg/org-mode.git


> Thanks and HTH,
> --
> Marco
>

Re: Org Capture Menu cannot be fully viewed

[Marco Wahl]

pietru@caramail.com writes:

>> Would be great if you could check out the fix.
>
> Of coarse.  Is the following command the right way to get the fix
> for testing?
>
> git clone https://code.orgmode.org/bzg/org-mode.git

This is a step in the right direction. With this line you get a fresh
clone of the latest code.

If you just start using Org from the repo you could check the
instructions for the install over at orgmode.org ~~> Install. In the
long run this is the best way, I think.

In the case of this fix, for which only function org-mks has been
changed, I'd recommend to just evaluate that function.

This means the following. Have the newest function org-mks in an Emacs
buffer. This could be the function org-mks in file org-macs.el from your
fresh clone. Then place the cursor behind the very last paren of
function org-mks and do C-x C-e. And then check the thing.


Best regards,
--
Marco

Org Capture Menu cannot be fully viewed - Results of testing C-n, C-p, C-v

[pietru]

1. Capture Option Selection
===========================

C-n, C-p, C-v work well and one can go through the capture menu easily.

Below the capture buffer, I am seeing another buffer that is displaying events
from the mouse (triple-mouse-1, down-mouse 5, ...) and keyboard (down up up, ...)
that ends getting bigger and bigger and bigger.

It is the buffer in which the user  enters the option.  It does get
bigger than one line, finally taking up most of the frame.  And the
user can do nothing about that - that is you cannot drog the mouse
to resize it.  Not being able to resize the window can become a very
big bother when using org-capture.

2. Problem with %^{prompt|default|completion2|completion3...}
=============================================================

Consider the following prompt template.  When I select "a", one gets

------- org-carture --------
* 7 Via Appia and Catacombs

  Site:
  Investigation: %^{Investigation|...|Historic Background Research Site Evaluation or Testing|Systematic Survey Data Recovery or Excavation|Records Search or Inventory Checking|Site Stewardship Monitoring|Site Stabilization|Heritage Management|Environment Research|Reconnaissance or Survey|Methodology, Theory, or Synthesis|Collections Research|Consultation|Ethnographic Research|Research Design or Data Recovery Plan|Architectural Survey|Ethnohistoric Research|Ground Disturbance Monitoring|Geophysical Survey|Archaeological Overview|Bioarchaeological Research|Architectural Documentation|Remote Sensing}%?
-------- org-capture --------

If one has available the up and down arrows for traversing through the completion list, it is counter-productive
to show the full completion list for Investigation.  The situation becomes even more relevant when the completion
list is a long one.

  ("a" "Via Appia and Catacombs" entry
  (file "~/archaeol.org")

"Site: %^{Site|...|
      Domestic Structure or Architectural Complex|
      Resource Extraction or Production|
      Transportation Structure or Features|
      Funerary and Burial Structures or Features|
      Non-Domestic Structures|
      Archaeological Feature|
      Rock Art|
      Water-Related}\n

  Investigation: %^{Investigation|...|
  Historic Background Research Site Evaluation or Testing|
  Systematic Survey Data Recovery or Excavation|"
  Records Search or Inventory Checking|"
  Site Stewardship Monitoring|
  Site Stabilization|
  Heritage Management|
  Environment Research|
  Reconnaissance or Survey|
  Methodology, Theory, or Synthesis|
  Collections Research|
  Consultation|
  Ethnographic Research|
  Research Design or Data Recovery Plan|
  Architectural Survey|
  Ethnohistoric Research|
  Ground Disturbance Monitoring|
  Geophysical Survey|
  Archaeological Overview|
  Bioarchaeological Research|
  Architectural Documentation|
  Remote Sensing}%?\n"

3 Default Completion Prompt
===========================

When the default consists of a long completion string, the long default is printed together with
default itself.  It could be useful to identify the default, however it should not be permanently
printed next to the prompt "Investigation [Historic Background Research Site Evaluation or Testing]:"

------- org-capture -------
Investigation [Historic Background Research Site Evaluation or Testing]: Historic Background Research Site Evaluation or Testing [No Matches]
------- org-capture -------

This is the capture template

 ("a" "Via Appia and Catacombs" entry
  (file "~/02histr/gadmin/archaeol/archaeol.rcl.org")
  "Investigation: %^{Investigation|Historic Background Research Site Evaluation or Testing|
  Systematic Survey Data Recovery or Excavation|Systematic Survey Data Recovery or Excavation|
  Records Search or Inventory Checking|Site Stewardship Monitoring|Site Stabilization|
  Heritage Management|Environment Research|Reconnaissance or Survey|Methodology, Theory, or Synthesis|
  Collections Research|Consultation|Ethnographic Research|Research Design or Data Recovery Plan|
  Architectural Survey|Ethnohistoric Research|Ground Disturbance Monitoring|Geophysical Survey|
  Archaeological Overview|Bioarchaeological Research|Architectural Documentation|Remote Sensing}%?\n") )

> Sent: Monday, December 14, 2020 at 1:41 PM
> From: "Marco Wahl" <marcowahlsoft@gmail.com>
> To: pietru@caramail.com
> Cc: "Org-Mode mailing list" <emacs-orgmode@gnu.org>
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> Hi Pietru and 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.
>
> Thanks for reporting.
>
> I just committed a fix along the lines of the similar exporter-UI and
> the agenda chooser-UI. Now there is at least C-n, C-p, C-v when the
> window is too small for all the items.
>
> Unfortunately these similar UIs are not unified when looking at the code
> base. E.g. I could not find a simple way to add key M-v to scroll one
> page up for the capture menu.
>
> Possibly these UIs could be unified or Org could even switch to
> something different. I think you already discussed some ideas. Sorry if
> I did not read the whole thread. That was too much information for me.
>
> Would be great if you could check out the fix.
>
>
> Thanks and HTH,
> --
> Marco
>

Re: Org Capture Menu cannot be fully viewed - Results of testing C-n, C-p, C-v

[Marco Wahl]

> 1. Capture Option Selection
> ===========================
>
> C-n, C-p, C-v work well and one can go through the capture menu easily.
>
> Below the capture buffer, I am seeing another buffer that is displaying events
> from the mouse (triple-mouse-1, down-mouse 5, ...) and keyboard (down up up, ...)
> that ends getting bigger and bigger and bigger.
>
> It is the buffer in which the user  enters the option.  It does get
> bigger than one line, finally taking up most of the frame.  And the
> user can do nothing about that - that is you cannot drog the mouse
> to resize it.  Not being able to resize the window can become a very
> big bother when using org-capture.

This is hopefully fixed with the latest commit. Also M-v has been added
to the family of navigation keys.

> 2. Problem with %^{prompt|default|completion2|completion3...}
> 3 Default Completion Prompt

TBH I don't see problems here. But that's just me. Let's see what others
think.

Does Nowayman's hint help?


Best regards,
-- 
Marco

Re: Org Capture Menu cannot be fully viewed - Results of testing C-n, C-p, C-v

[pietru]

> Sent: Wednesday, December 16, 2020 at 10:46 PM
> From: "Marco Wahl" <marcowahlsoft@gmail.com>
> To: pietru@caramail.com
> Cc: "Org-Mode mailing list" <emacs-orgmode@gnu.org>
> Subject: Re: Org Capture Menu cannot be fully viewed - Results of testing C-n, C-p, C-v
>
>
> > 1. Capture Option Selection
> > ===========================
> >
> > C-n, C-p, C-v work well and one can go through the capture menu easily.
> >
> > Below the capture buffer, I am seeing another buffer that is displaying events
> > from the mouse (triple-mouse-1, down-mouse 5, ...) and keyboard (down up up, ...)
> > that ends getting bigger and bigger and bigger.
> >
> > It is the buffer in which the user  enters the option.  It does get
> > bigger than one line, finally taking up most of the frame.  And the
> > user can do nothing about that - that is you cannot drog the mouse
> > to resize it.  Not being able to resize the window can become a very
> > big bother when using org-capture.
>
> This is hopefully fixed with the latest commit. Also M-v has been added
> to the family of navigation keys.
>
> > 2. Problem with %^{prompt|default|completion2|completion3...}
> > 3 Default Completion Prompt
>
> TBH I don't see problems here. But that's just me. Let's see what others
> think.

Problem happens for long completion texts in {PROMPT||||}

When the default is printed as well as the next selection, it creates
a problem.  You can always go through all the options, and I see no need
to continue showing the default when people are moving through the selections.

It is ok to have the default when the selection consist of just one word, but
not when you have longer categorisation sentences.

Archaeological Data Archiving Protocol
Heavy Minerals and Particle Size Analysis
Micromorphology and related Microscopy (SEM Analysis, X-Ray Diffraction)
Thin Section Reference (Polarised Light Microscopy)

> Does Nowayman's hint help?

I had already tackled that problem.  But it is a different problem.

> Best regards,
> --
> Marco
>