Re: displaying equations with ob-latex

[pietru]

I've got the same problem.




> Sent: Thursday, May 06, 2021 at 9:54 PM
> From: michael-franz...@gmx.com
> To: "Help Emacs Orgmode" 
> Subject: displaying equations with ob-latex
>
>
> I am trying to use ob-latex but equations are not being displayed in emacs
> when I try to execute with "C-c C-c".
>
>
>
>
>
>

ob-fortran fixes to column position 6 and subroutine keywords

[pietru]

ob-fortran treats code highlighting as "fortran 77" code, starting highlighting
from column position 6.  Can this be changed to use free format?

Also the following call fails, meaning that currently you cannot use
keywords.

call system_clock(cnt_mx=count_max, cnt_rt=count_rate)

Re: orgbabel with fortran code

[pietru]

Perhaps we can have a crack at ob-fortran again, considering you have had
some successes.  With the motivation that this could drive some more work 
on the code if useful.  Would some hacking time of a few days bo possible 
to you?  We can then compile a brief report and send it.  

Thank you so very much Arne.

> Sent: Thursday, May 06, 2021 at 7:50 AM
> From: "Dr. Arne Babenhauserheide" 
> To: pie...@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: orgbabel with fortran code
>
> pie...@caramail.com writes:
> 
> > Have you got exomples with fortran code yourself?  I would like to 
> > scrutinise them. 
> 
> I have this, but I no longer know whether it actually executes fortran
> inline or only tangles it:
> 
> https://www.draketo.de/files/2017-04-10-Mo-fortran-commandline-tool.org
> https://www.draketo.de/files/surprises.org
> 
> From
> https://www.draketo.de/english/free-software/fortran
> https://www.draketo.de/light/english/fortran-surprises
> 
> Best wishes,
> Arne
> -- 
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
> Message-ID: <87h7jh2qh7@web.de>
>

Re: orgbabel with fortran code

[pietru]

> Sent: Thursday, May 06, 2021 at 8:53 AM
> From: "Dr. Arne Babenhauserheide" 
> To: pie...@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: orgbabel with fortran code
>
> 
> pie...@caramail.com writes:
> 
> > Have seen yon also use ob-latex.  Have tried to display equations but was 
> > not
> > successful.  I would be grateful with some help on that Arne.
> 
> Where did you try to use ob-latex? I mainly use latex-export (and quite a
> large amount of it).

It is supposed to work, so tried to crack it.  Could be useful an attempts 
could drive some improvements.



 
> Best wishes,
> Arne
> -- 
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
>

Re: orgbabel with fortran code

[pietru]

Have had a first go with your code

I wrote the following, then went inside the code and slammed "C-c C-c" 

#+BEGIN_SRC fortran :tangle fortran-comline.f90
program cli
  implicit none ! no implicit declaration: all variables must be declared
  character(1000) :: arg
  
  call get_command_argument(1, arg) ! result is stored in arg, see 
  ! https://gcc.gnu.org/onlinedocs/gfortran/GET_005fCOMMAND_005fARGUMENT.html
  
  if (len_trim(arg) == 0) then ! no argument given
  write (*,*) "Call me --world!"
  else
  if (trim(arg) == "--world") then
  call get_command_argument(2, arg)
  if (len_trim(arg) == 0) then
  arg = "again!"
  end if
  write (*,*) "Hello ", trim(arg)
  ! trim reduces the fixed-size array to non-blank letters
  end if
  end if
end program
#+END_SRC

And then I wrote this, went inside the code and slammed "C-c C-c" 

#+BEGIN_SRC sh :results output :exports both
  gfortran -std=gnu -O3 fortran-comline.f90 -o fortran-comline
  ./fortran-comline
  ./fortran-comline --world World
  ./fortran-comline --world
#+END_SRC

But I am getting some major whining

/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o: In function 
`_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
sh: 2: ./fortran-comline: not found
sh: 3: ./fortran-comline: not found
sh: 4: ./fortran-comline: not found



> Sent: Thursday, May 06, 2021 at 7:50 AM
> From: "Dr. Arne Babenhauserheide" 
> To: pie...@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: orgbabel with fortran code
>
> pie...@caramail.com writes:
> 
> > Have you got exomples with fortran code yourself?  I would like to 
> > scrutinise them. 
> 
> I have this, but I no longer know whether it actually executes fortran
> inline or only tangles it:
> 
> https://www.draketo.de/files/2017-04-10-Mo-fortran-commandline-tool.org
> https://www.draketo.de/files/surprises.org
> 
> From
> https://www.draketo.de/english/free-software/fortran
> https://www.draketo.de/light/english/fortran-surprises
> 
> Best wishes,
> Arne
> -- 
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
> Message-ID: <87h7jh2qh7@web.de>
>

Re: orgbabel with fortran code

[pietru]

Have seen yon also use ob-latex.  Have tried to display equations but was not
successful.  I would be grateful with some help on that Arne.

Regards
Pete


> Sent: Thursday, May 06, 2021 at 7:50 AM
> From: "Dr. Arne Babenhauserheide" 
> To: pie...@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: orgbabel with fortran code
>
> pie...@caramail.com writes:
> 
> > Have you got exomples with fortran code yourself?  I would like to 
> > scrutinise them. 
> 
> I have this, but I no longer know whether it actually executes fortran
> inline or only tangles it:
> 
> https://www.draketo.de/files/2017-04-10-Mo-fortran-commandline-tool.org
> https://www.draketo.de/files/surprises.org
> 
> From
> https://www.draketo.de/english/free-software/fortran
> https://www.draketo.de/light/english/fortran-surprises
> 
> Best wishes,
> Arne
> -- 
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
> Message-ID: <87h7jh2qh7@web.de>
>

Re: Multiple calc commands with orgbabel

[pietru]

> Sent: Thursday, May 06, 2021 at 4:39 AM
> From: "Eric S Fraga" 
> To: "Matt Price" 
> Cc: pie...@caramail.com, "Org Mode List" 
> Subject: Re: Multiple calc commands with orgbabel
>
> On Wednesday,  5 May 2021 at 11:11, Matt Price wrote:
> > Can you explain how you get calc embedded mode working in org? I have
> > never used it and it sounds interesting, but I don't understand what
> > hte delimiters are.
>
> Sure.  Here is a mini-tutorial! :-) I recently gave an interactive talk
> on embedded Calc...
>
> The out-of-the-box settings for Emacs embedded mode are such that any
> line surrounded by empty lines (i.e. couple of blank lines before and
> after) can be interpreted as an expression to evaluate by Calc using
> "C-x * u".  You do not need to place these expressions in any src block.
>
> The detection can be somewhat fragile so extra blank lines are sometimes
> necessary for some reason.
>
> For instance, copy the following few lines to a text buffer and type
> "C-x * u" on each line in turn:
>
> --8<---cut here---start->8---
>
>
> x := 180 =>
>
>
> y := sin(x / 4) =>
>
>
> z := 2 y^2 =>
>
>
> --8<---cut here---end--->8---
>
> The general format for an embedded calc expression is
>
>var := expression => value
>
> where only "expression" is required.  If you don't have "=>", evaluating
> the expression will replace the expression with its value.
>
> If you have lines as above, with assignments and values after the actual
> expression, you can then go back to the first line and change the value,
> say to 90, type "C-x *u" on that line again and all of them should
> update.
>
> The calculations can involve calculus (derivatives, integration), linear
> algebra, and units.  Calc is actually an incredibly powerful (and
> relatively unknown) computer algebra system hiding within Emacs.

Calc is a great piece of work.  Has it been long that work was done on it?

> The variables that could be customised to have org specific recognition
> would be calc-embedded-open-formula and calc-embedded-close-formula.  It
> might be useful for the community to think about whether org should have
> org specific settings for these variables.  I actually define settings
> for org so that only lines that look like this:
>
> #+calc: expression
>
> are interpreted (without requiring empty lines around such lines)
> [1].  I then have code for processing these lines on export to LaTeX to
> present the equations and results in a more accessible way as I use
> embedded calc a lot for teaching (beamer slides).
>
> Final note: the info manual for embedded Calc mode emphasises editing
> the expressions and interacting with Calc while doing so.  I find that
> method of working rather confusing, tiring, and unproductive (for my use
> case) so I write the calc lines using normal editing and only "update"
> the expressions to get the results.  YMMV, of course.
>
> Let me know if this helped at all,
> eric
>
>
> Footnotes:
> [1] it would be nice to have some generic way to hijack C-c C-c on such
>  lines to do what I want, e.g. calc-embedded-update-formula.
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd
>
>

Re: Multiple calc commands with orgbabel

[pietru]

 

Example

 

(require 'ob-calc)

 (org-babel-do-load-languages
 'org-babel-load-languages
 '( (calc . t) )

 

 calc.org 

 

# To execute, place cursor point on a line, then hit "C-c * u" hard with no harm.

 

#+name: Simplifying Formulas
#+begin_src calc

simplify((x + y) (x + y)) =>

simplify(a x^2 b / (c x^3 d)) =>

simplify((4 x + 6) / (8 x)) =>

simplify((1 + 2 i) (3 + 4 i)) =>

simplify(5 + i^2 + i - 8 i) =>

simplify((1, 2) + (3, 4)) =>

simplify((1, 2) (3, 4)) =>

#+end_src

 

 

 

Sent: Thursday, May 06, 2021 at 3:11 AM
From: "Matt Price" 
To: "Org Mode List" 
Cc: pie...@caramail.com
Subject: Re: Multiple calc commands with orgbabel


Can you explain how you get calc embedded mode working in org? I have never used it and it sounds interesting, but I don't understand what hte delimiters are. 
 


On Wed, May 5, 2021 at 2:35 AM Eric S Fraga  wrote:

On Wednesday,  5 May 2021 at 07:46, pie...@caramail.com wrote:
> Have been trying to execute multiple calc commands, but when I
> evaluate the calc expressions, I get just one result.

ob-calc returns the top element of the stack when finished and this will
be the result of the last operation in the src block.  I don't think
there's any way around this.

I use embedded Calc for this reason.  You could rewrite your equations
as simple lines (separated by empty lines from the surroundings) and
evaluate each in turn with "C-x * u":

fsolve(x 2 + x = 4, x) => x = 1.333

fsolve([x + y = a, x - y = b], [x, y]) => [x = a + (b - a) / 2, y = (a - b) / 2]

I added the "=>" at the end of each _expression_ so that the result is
shown to the right instead of replacing the _expression_ itself (default
embedded Calc behaviour).

--
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd
 

Re: Multiple calc commands with orgbabel

[pietru]

> Sent: Wednesday, May 05, 2021 at 7:59 PM
> From: "Eric S Fraga" 
> To: pie...@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Multiple calc commands with orgbabel
>
> On Wednesday,  5 May 2021 at 09:26, pie...@caramail.com wrote:
> > Does anybody has some experience using calc for factoring, matrix
> > computation and taking derivatives.  The manual overwhelmed me.
>
> You might be better off asking on the Emacs help list as this is rather
> off-topic for the org mailing list.

Fair enough.

> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-503-g501b2a
>

Re: Multiple calc commands with orgbabel

[pietru]

Does anybody has some experience using calc for factoring, matrix computation 
and
taking derivatives.  The manual overwhelmed me.


> Sent: Wednesday, May 05, 2021 at 7:23 PM
> From: "Eric S Fraga" 
> To: "Dr. Arne Babenhauserheide" 
> Cc: pie...@caramail.com, emacs-orgmode@gnu.org
> Subject: Re: Multiple calc commands with orgbabel
>
> On Wednesday,  5 May 2021 at 09:12, Dr. Arne Babenhauserheide wrote:
> > could you try the header :results output?
>
> Doesn't make any difference as Calc itself does not actually output
> anything.  All results are put on the stack.
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-503-g501b2a
>

Re: orgbabel with fortran code

[pietru]

> Sent: Wednesday, May 05, 2021 at 7:20 PM
> From: "Eric S Fraga" 
> To: pie...@caramail.com
> Cc: "help Emacs Orgmode" 
> Subject: Re: orgbabel with fortran code
>
> On Wednesday,  5 May 2021 at 09:14, pie...@caramail.com wrote:
> > The code is fantastic, but how may I run it exactly?  Using "C-c C-c"
> > tells me "'C-c C-c' can do nothing useful here".
>
> You may need to evaluate (require 'ob-fortran) in your init files.

Yes, have done that.

> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-503-g501b2a
>
>

Re: orgbabel with fortran code

[pietru]

Have you got exomples with fortran code yourself?  I would like to scrutinise 
them. 
 
> Sent: Wednesday, May 05, 2021 at 7:14 PM
> From: "Dr. Arne Babenhauserheide" 
> To: pie...@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: orgbabel with fortran code
>
> 
> pie...@caramail.com writes:
> 
> > Have been looking to find some examples on using orgbabel with fortran code
> > but have not found information.
> 
> Fortran is listed as supported on
> https://orgmode.org/worg/org-contrib/babel/languages/index.html
> so I would hope that the standard tipps there apply.
> 
> Best wishes,
> Arne
> -- 
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
>

Re: Multiple calc commands with orgbabel

[pietru]

I still get the lost result

#+begin_src calc :results output
  fsolve(x*2+x=4,x)
  fsolve([x + y = a, x - y = b],[x,y])
#+end_src

#+RESULTS:
: [x = a + (b - a) / 2, y = (a - b) / 2]




> Sent: Wednesday, May 05, 2021 at 7:12 PM
> From: "Dr. Arne Babenhauserheide" 
> To: pie...@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Multiple calc commands with orgbabel
>
> 
> pie...@caramail.com writes:
> 
> > Have been trying to execute multiple calc commands, but when I evaluate the 
> > calc
> > expressions, I get just one result.
> 
> could you try the header :results output?
> 
> Best wishes,
> Arne
> -- 
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
>

Re: orgbabel with fortran code

[pietru]

> Sent: Wednesday, May 05, 2021 at 6:52 PM
> From: "Eric S Fraga" 
> To: pie...@caramail.com
> Cc: "help Emacs Orgmode" 
> Subject: Re: orgbabel with fortran code
>
> On Wednesday,  5 May 2021 at 08:37, pie...@caramail.com wrote:
> > Make a function and then run it with different values.
>
> Have a look at the attachment.  Doesn't create a /function/ in the
> Fortran sense but shows how you can definitely call some code with
> different values.

Thank you so very much, I will check it out.

> That's about all I can help with as it's been years since I used Fortran
> (although I did cut my teeth on Fortran 66... ;-)).

Is there anyone in particular who would know some more things about fortran
in org-babel?

> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd
>

Re: orgbabel with fortran code

[pietru]

The code is fantastic, but how may I run it exactly?  Using "C-c C-c"
tells me "'C-c C-c' can do nothing useful here".

> Sent: Wednesday, May 05, 2021 at 6:52 PM
> From: "Eric S Fraga" 
> To: pie...@caramail.com
> Cc: "help Emacs Orgmode" 
> Subject: Re: orgbabel with fortran code
>
> On Wednesday,  5 May 2021 at 08:37, pie...@caramail.com wrote:
> > Make a function and then run it with different values.
>
> Have a look at the attachment.  Doesn't create a /function/ in the
> Fortran sense but shows how you can definitely call some code with
> different values.
>
> That's about all I can help with as it's been years since I used Fortran
> (although I did cut my teeth on Fortran 66... ;-)).
>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd
>

Re: Multiple calc commands with orgbabel

[pietru]

> Sent: Wednesday, May 05, 2021 at 6:41 PM
> From: "Eric S Fraga" 
> To: pie...@caramail.com
> Cc: "help Emacs Orgmode" 
> Subject: Re: Multiple calc commands with orgbabel
>
> On Wednesday,  5 May 2021 at 08:40, pie...@caramail.com wrote:
> >> ob-calc returns the top element of the stack when finished and this will
> >> be the result of the last operation in the src block.  I don't think
> >> there's any way around this.
> >
> > Is the top stack element just with ob-calc?
>
> I am not sure what you are asking here.  Other languages do not have the
> concept of a stack necessarily.  However, for other languages, there is
> often the option to have the results be "output" instead of "value".

I understand, thank you.

>
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd
>
>

Re: Multiple calc commands with orgbabel

[pietru]

> Sent: Wednesday, May 05, 2021 at 6:33 PM
> From: "Eric S Fraga" 
> To: pie...@caramail.com
> Cc: "help Emacs Orgmode" 
> Subject: Re: Multiple calc commands with orgbabel
>
> On Wednesday,  5 May 2021 at 07:46, pie...@caramail.com wrote:
> > Have been trying to execute multiple calc commands, but when I
> > evaluate the calc expressions, I get just one result.
>
> ob-calc returns the top element of the stack when finished and this will
> be the result of the last operation in the src block.  I don't think
> there's any way around this.

Is the top stack element just with ob-calc?

> I use embedded Calc for this reason.  You could rewrite your equations
> as simple lines (separated by empty lines from the surroundings) and
> evaluate each in turn with "C-x * u":
>
> fsolve(x 2 + x = 4, x) => x = 1.333
>
> fsolve([x + y = a, x - y = b], [x, y]) => [x = a + (b - a) / 2, y = (a - b) / 
> 2]
>
> I added the "=>" at the end of each expression so that the result is
> shown to the right instead of replacing the expression itself (default
> embedded Calc behaviour).

Will check it out, thanks.

> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd
>
>

Re: orgbabel with fortran code

[pietru]

Make a function and then run it with different values.

> Sent: Wednesday, May 05, 2021 at 6:24 PM
> From: "Eric S Fraga" 
> To: pie...@caramail.com
> Cc: "help Emacs Orgmode" 
> Subject: Re: orgbabel with fortran code
>
> On Wednesday,  5 May 2021 at 07:41, pie...@caramail.com wrote:
> > Have been looking to find some examples on using orgbabel with fortran code
> > but have not found information.
>
> What is it you wish to do?
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd
>
>

Multiple calc commands with orgbabel

[pietru]

Have been trying to execute multiple calc commands, but when I evaluate the calc
expressions, I get just one result.



This does not work

#+begin_src calc
fsolve(x*2+x=4,x)
fsolve([x + y = a, x - y = b],[x,y])
#+end_src



But this works

#+begin_src calc
fsolve(x*2+x=4,x)
#+end_src

#+begin_src calc
fsolve([x + y = a, x - y = b],[x,y])
#+end_src>

orgbabel with fortran code

[pietru]

Have been looking to find some examples on using orgbabel with fortran code
but have not found information.

Regards
P*

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" 
> To: pie...@caramail.com
> Cc: "Org-Mode mailing list" 
> 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
>

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" 
> To: pie...@caramail.com
> Cc: "Org-Mode mailing list" 
> 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-

Re: Org Capture Menu cannot be fully viewed

[pietru]

> Sent: Monday, December 14, 2020 at 1:41 PM
> From: "Marco Wahl" 
> To: pie...@caramail.com
> Cc: "Org-Mode mailing list" 
> 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

[pietru]

> Sent: Monday, December 14, 2020 at 12:08 AM
> From: "TRS-80" 
> To: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> On 2020-12-12 23:57, pie...@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.

Re: Org Capture Menu cannot be fully viewed

[pietru]

> Sent: Sunday, December 13, 2020 at 11:00 PM
> From: "TRS-80" 
> To: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> On 2020-12-13 16:02, pie...@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

[pietru]

> Sent: Sunday, December 13, 2020 at 10:57 PM
> From: "Bastien" 
> To: "Tim Cross" 
> Cc: emacs-orgmode@gnu.org, "Jean Louis" 
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> Hi Tim and Jean,
>
> Tim Cross  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

[pietru]

> Sent: Sunday, December 13, 2020 at 10:48 PM
> From: "Jean Louis" 
> To: pie...@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> * pie...@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

[pietru]

> Sent: Sunday, December 13, 2020 at 10:48 PM
> From: "Jean Louis" 
> To: pie...@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> * pie...@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: Adding Org Files to org-agenda-files

[pietru]

> Sent: Sunday, December 13, 2020 at 9:59 PM
> From: "Tim Cross" 
> To: "Ihor Radchenko" 
> Cc: "Jean Louis" , daniela-s...@gmx.it, 
> emacs-orgmode@gnu.org
> Subject: Re: Adding Org Files to org-agenda-files
>
>
> Ihor Radchenko  writes:
>
> > Dear Jean Louis,
> >
> > Thank you for the detailed insight into your extensive experience of
> > project management and practical planning. I do not have that much
> > experience, but can provide a significantly different point of view
> > related to my research work.
> >
>
> Some good observations. I have cut most of it out to stop the thread
> from becoming too long.
>
> I think it is very important to recognise there is no one way to do
> project management or organise a project. Different industries have
> different requirements. For example, project management requirements to
> build a bridge are very different from those to build the software that
> will be the next evolution of social networking sites.
>
> The way Jean Louis describes project management sounds very similar to
> the waterfall methodology which was popular in software development up
> until the late 90s. It is a methodology that can work well when you have
> a well defined and understood project, like building a bridge where we
> have a couple of thousand years of experience and engineering knowledge.
> It doesn't work particularly well with software projects and has been
> largely replaced by various 'Agile' methodologies which are similar to
> what you outline as your experiences and approach with research. Even
> within the software development space, you find considerable variation
> because different stages within the software life-cycle have different
> requirements. For example, during the R&D stage, there are far more
> 'unknowns' than 'knowns'. Often, many things will need to be tried and
> then accepted or rejected (suck and see). At this stage, you need to be
> fast and flexible with maybe 80% of ideas ending up on the scrap heap.
> You have limited ability to identify all the stages, all the tasks or
> make terribly accurate estimates on completion time. Later, the software
> will move into production status. Things change considerably at this
> point. Here you need stability, reliability and performance. Changes
> often need to be justified from a return on investment perspective.
> There are fewer unknowns, more accurate estimates and better defined
> tasks.
>
> Is org mode suitable in all these scenarios? Possibly not or perhaps
> there are dedicated project management tools which are better suited.
> Org is not a project management tool, but it is a tool that is flexible
> enough for many people to use it for either project management or for
> part of the project management process.
>
> To argue for a specific workflow using org mode in a specific manner
> with only the task types you believe are relevant fails to recognise the
> vast differences in requirements everyone has or personal preferences in
> how individuals like to manage their projects or information. The great
> power of org mode is in the ease to which it can be bent to fit with the
> individual's preferred workflow. This is significantly different from
> many other solutions which require you to adjust your workflow to fit
> with the tool. The great weakness with org mode is that this tends to
> make everyone think they have found and defined the ultimate approach,
> which can easily reach religious heights and inspire a missionary zeal
> to evangelise their perception of the world.

I know people are trying to help.  Still, I fully agree with Tim here.
I want to give more flexibility to people in the ditches.  They should
decide  their approach and be able to adjust their workflow as they see
fit.  Currently capture works ok for some, but if we get the buffer to have
flexibility as emacs, it would make a big difference, and they will use it.

Particularly for extensive excavations where different regions are under
separate direction.

> --
> Tim Cross
>

Re: Org Capture Menu cannot be fully viewed

[pietru]

> Sent: Sunday, December 13, 2020 at 9:06 PM
> From: "Tim Cross" 
> To: "Jean Louis" 
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
>
> Jean Louis  writes:
>
> > * Tim Cross  [2020-12-13 03:54]:
> >>
> >> pie...@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
> el

Re: Org Capture Menu cannot be fully viewed

[pietru]

> Sent: Sunday, December 13, 2020 at 9:37 PM
> From: "Jean Louis" 
> To: pie...@caramail.com
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> * pie...@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

[pietru]

> Sent: Sunday, December 13, 2020 at 11:24 AM
> From: "Jean Louis" 
> To: pie...@caramail.com
> Cc: "TRS-80" , emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> * pie...@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 el

Re: Org Capture Menu cannot be fully viewed

[pietru]

> Sent: Sunday, December 13, 2020 at 12:06 PM
> From: "Jean Louis" 
> To: "TRS-80" 
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> * TRS-80  [2020-12-13 01:11]:
> > On 2020-12-12 13:02, pie...@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

[pietru]

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

[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" 
> To: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> On 2020-12-12 22:49, pie...@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]

> 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" 
> To: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> On 2020-12-12 21:08, pie...@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" 
> To: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> On 2020-12-12 21:08, pie...@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
>
>

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: pie...@caramail.com
> To: "Tim Cross" 
> 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" 
> > To: emacs-orgmode@gnu.org
> > Subject: Re: Org Capture Menu cannot be fully viewed
> >
> >
> > pie...@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

[pietru]

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

[pietru]

> Sent: Sunday, December 13, 2020 at 1:00 AM
> From: "TRS-80" 
> To: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> On 2020-12-12 18:30, pie...@caramail.com wrote:
> >> From: "TRS-80" 
> >>
> >> 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

[pietru]

> Sent: Sunday, December 13, 2020 at 12:13 AM
> From: "TRS-80" 
> To: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> On 2020-12-12 17:46, pie...@caramail.com wrote:
> >> From: "TRS-80" 
> >
> > 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

[pietru]

> Sent: Saturday, December 12, 2020 at 11:09 PM
> From: "TRS-80" 
> To: emacs-orgmode@gnu.org
> Subject: Re: Org Capture Menu cannot be fully viewed
>
> On 2020-12-12 13:02, pie...@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
>
>

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

Time Slots in Org-Agenda

[pietru]

Dear Christopher

Appointment slots are very useful when you don't know who needs to
meet with you, but you want to make yourself available. You can
offer people a block of time on your agenda that they can book
time slots within. For example, you can set aside 20 minutes that
you're available to meet with people.

It would also be useful to show the percentage of appointments for
the day, week, month.  With possible indication of empty slots.

Regards
Pietru



Pietru Caxaro
Director of Underground Sensing Techniques
Special Superintendence for the Archaeological Heritage of Rome

> Sent: Wednesday, December 09, 2020 at 8:50 PM
> From: "Christopher Dimech" 
> To: "Org-Mode mailing list" 
> Subject: Time Slots in Org-Agenda
>
> It would be good if the following org-agenda problem could be addressed.
>
> Here is a section of a diary
>
> Dec 05, 2020
> 06:13-08:34 Gnu Hackers Meeting
> 10:21-12:00 Richard Stallman Talk
> 12:00-12:34 Lunch
> 14:21-17:34 Hacking Session
>
> This gives the following in Org-Agenda.
>
>
> Saturday 5 December 2020
> 5:06.. now - - - - - - - - - - - - - - - - - - - - - - - - -
> Diary: 7:55- 9:34 Gnu Hackers Meeting *
> 8:00.. 
> 10:00.. 
> Diary: 10:21-12:00 Richard Stallman Talk
> 12:00.. 
> Diary: 12:00-12:34 Lunch
> 14:00.. 
> Diary: 14:21-17:34 Hacking Session *
> 16:00.. 
> 18:00.. 
> 20:00.. 
>
>
> Loking at the entries with a star, end later than the
> next time thresholds of 08:00 and 16:00, yet the entries
> are not being populated for the later times.
>
> I would be grateful if the slots at the later times would
> also be filled. For instance, according to the setup below
> (see the ** entries)
>
> Saturday 5 December 2020
> 5:06.. now - - - - - - - - - - - - - - - - - - - - - - - - -
> Diary: 7:55- 8:00 Gnu Hackers Meeting **
> 8:00.. 
> Diary: 8:00- 9:34 Gnu Hackers Meeting **
> 10:00.. 
> Diary: 10:21-12:00 Richard Stallman Talk
> 12:00.. 
> Diary: 12:00-12:34 Lunch
> 14:00.. 
> Diary: 14:21-16:00 Hacking Session **
> 16:00.. 
> Diary: 17:00-17:34 Hacking Session **
> 18:00.. 
> 20:00.. 
>
>
>
>