Re: [PATCH] Enhance org-html--build-meta-info

[TEC]

Bastien  writes:

> Can we approach this with two patches, one with the refactoring and
> one with the added functionality?

Sure :) I'll take care of this when I get home in a few hours.

> This sounds useful.

Glad to hear!

> I think "Org Export" as the default is counter-intuitive, let's stick
> to the empty string.  (Also, this kind of "small" changes should be
> made with consideration of all exporters.)

In case of confusion, this isn't replacing the #+title in the document,
just the ... which is used as the tab content.
I just find blank tabs to be quite unhelpful, particularly when nestled
among others.

I'm not really aware of anything analogous in other exporters. Maybe the
metadata in exported PDFs ... but that doesn't exactly show up in
browser tabs :P

> Nope, the first line of a docstring should be a sentence.  You'll have
> to reformulate the beginning of the docstring...

I'll take care of this with the patch separation.

Thanks for the feedback!

Timothy.

Re: [PATCH] Enhance org-html--build-meta-info

[Bastien]

Hi Timothy,

TEC  writes:

>> In a nutshell, can you restate what problem is this patch fixing?
>
> There are two things I intend to achieve with this patch:
> 1. DRY* out the existing code. The existing code is quite repetitive in
>structure, and easily lends itself to being extracted to a function.
>This is easier to read, and work with IMO.
> 2. Make use of the DRYer code in (1) to provide a make the meta building
> function more versatile, and then add in the ability for user
> customisation at low-cost (again, thanks to (1)).

Can we approach this with two patches, one with the refactoring and
one with the added functionality?

> Necessary? Not really, I mean the export /works/ without it. I'd argue
> that it's desirable though, as it provides an easy way for a user (such
> as myself) to add useful meta tags not included by default.

This sounds useful.

>> Are there backward compatibility considerations we should take care of?
>
> None AFAIK. Barring this errors that Jens raised, and now have hopefully
> been addressed, this should function /exactly/ as the current
> implementation does, with a minor (beneficial) caveat, mentioned below.
> Just with nicer-to-work-with code and a bit more versatility (IMO, of
> course).
>
> These are the two changes to be mentioned:
> 1. The (or {title} "Org Export") bit I added.
>I believe the current behaviour when no #+title is given is to have a
>blank one (""). I think "Org Export" is preferable, as it's more
>informative than ... nothing.

I think "Org Export" as the default is counter-intuitive, let's stick
to the empty string.  (Also, this kind of "small" changes should be
made with consideration of all exporters.)

> 2. Using org-html-encode-plain-text for formatting the content of the
>meta tags. From Jens, I take it that the current org-export-data can
>cause nested HTML tags, which are invalid in this context. Plain text
>should be safer.

Yes, this is better.

>>> +(defun org-html--build-meta-entry (label identity  content-format 
>>>  content-formatters)
>>> +  "Construct  tag with LABEL=\"IDENTITY\" and content from 
>>> CONTENT-FORMAT and CONTENT-FORMATTER."
>>
>> The first line of this defun is too long.  You can try M-x checkdoc
>> RET on your elisp files to catch those issues.
>>
>> Thanks,
>
> I see, I'm guessing I'll just need to add a line break.

Nope, the first line of a docstring should be a sentence.  You'll have
to reformulate the beginning of the docstring...

Thanks!

-- 
 Bastien

Re: Ignored bugs

[Bastien]

Hi Boruch,

Boruch Baum  writes:

> BUG REPORT: 42484
>
> + This is of particular concern to me because when it was submitted it
>   was summarily closed AND ANRCHIVED. When I complained, it was unarchived so
>   that I could provide a solution and patch of my own, but it has since
>   been archived AGAIN, so I can't submit an updated patch. Further, it
>   was never removed from the closed state, so it could easily be
>   overlooked. (Do I need to explicitly complain that this is awful
>   management behavior?) So, I have an updated patch that I tried to
>   submit a few minutes ago that was bounced because the thread is in
>   read-only archived state.

I'm not convinced this should be in Org's core.

I think it could be in https://orgmode.org/worg/org-hacks.html

You can send a patch against https://code.orgmode.org/bzg/worg/ or
ask for an account on https://code.orgmode.org to be able to write
directly to Worg.

> BUG REPORT: 43954

Please use report-emacs-bug for bugs only.

For such suggestions, please discuss them on this list.

> BUG REPORT: 43955
>
> + code included

It looks like 43955 is a better version of 43954.

> BUG REPORT: 44133
>
> + code included

The patch seems interesting.  Can you resend it on this list in a
dedicated thread?  Also, you need to format it as described here:
https://orgmode.org/worg/org-contribute.html

Thanks,

-- 
 Bastien

Release Org 9.4.2

[Bastien]

Hi all,

I've released Org 9.4.2, a bugfix release.

This version was merged with the emacs-27 branch:
https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-27

Enjoy!

-- 
 Bastien

Re: [PATCH] Enhance org-html--build-meta-info

[TEC]

Bastien  writes:

> Let's wait for Jens feedback on this patch, since he took care of
> testing it so far.

Assuming Jens responds as he usually has (relatively promptly), this
sounds good to me :)

> In a nutshell, can you restate what problem is this patch fixing?

There are two things I intend to achieve with this patch:
1. DRY* out the existing code. The existing code is quite repetitive in
   structure, and easily lends itself to being extracted to a function.
   This is easier to read, and work with IMO.
2. Make use of the DRYer code in (1) to provide a make the meta building
function more versatile, and then add in the ability for user
customisation at low-cost (again, thanks to (1)).

*DRY is an acronym for "Don't Repeat Yourself", in case there's a french
 equivalent you're more familiar with.

> Is a new option really necessary here?

Necessary? Not really, I mean the export /works/ without it. I'd argue
that it's desirable though, as it provides an easy way for a user (such
as myself) to add useful meta tags not included by default. For example
I currently make use of this to add information that parsed by a large
number of services/apps to create rich embeds for exported Org files I
link to (see
https://tecosaur.github.io/emacs-config/config.html#extra-header-content,code--2
).

Furthermore, I consider it to be very low cost, since it's basically
just taking advantage of the restructuring already performed for code
QOL reasons.

I expect most users not to have any reason to touch this, but for some
to find it handy.

> Are there backward compatibility considerations we should take care of?

None AFAIK. Barring this errors that Jens raised, and now have hopefully
been addressed, this should function /exactly/ as the current
implementation does, with a minor (beneficial) caveat, mentioned below.
Just with nicer-to-work-with code and a bit more versatility (IMO, of
course).

These are the two changes to be mentioned:
1. The (or {title} "Org Export") bit I added.
   I believe the current behaviour when no #+title is given is to have a
   blank one (""). I think "Org Export" is preferable, as it's more
   informative than ... nothing.
2. Using org-html-encode-plain-text for formatting the content of the
   meta tags. From Jens, I take it that the current org-export-data can
   cause nested HTML tags, which are invalid in this context. Plain text
   should be safer.

>> +(defun org-html--build-meta-entry (label identity  content-format 
>>  content-formatters)
>> +  "Construct  tag with LABEL=\"IDENTITY\" and content from 
>> CONTENT-FORMAT and CONTENT-FORMATTER."
>
> The first line of this defun is too long.  You can try M-x checkdoc
> RET on your elisp files to catch those issues.
>
> Thanks,

I see, I'm guessing I'll just need to add a line break.

I hope that clarifies things!

Timothy

Re: [PATCH] org-plot abstractions and extension

[Bastien]

TEC  writes:

> Thanks for the feedback on the patches! I tried to get it right after my
> previous (and first) attempt, but it looks like there are a few things I
> still need to take note of. Big improvement though, nonetheless,
> hopefully next time they'll be nothing to change :)

Well, It's perfectly fine not to send a perfect patch.  Thanks!

-- 
 Bastien

Re: Ignored bugs

[Bastien]

Hi Boruch,

Boruch Baum  writes:

>> Would you like to elaborate on why making it easy for you to contribute
>> something to org-mode that solves your problems should be of concerns to
>> the people of this list, especialy if this comes at extra cost to them?
>
> That is such a classic and revealing paragraph you wrote about yourself!
> Maybe paste it on your bathroom mirror and read over every once in a while.
> Maybe publicize that paragraph as a policy document for the project?
>
>> Cheers,
>
> Not.

The tone of your answer sounded harsh.  You may have your reasons to
be upset, but please let's try our best to avoid such tone.

You may want to read the GNU Kind Communication Guidelines:
https://www.gnu.org/philosophy/kind-communication.html

I re-read them from time to time, they convey useful hints on how to
have constructive conversations.

Best,

-- 
 Bastien

Re: [PATCH] Remove redundant 'function's around lambda

[Bastien]

Hi Kyle,

Kyle Meyer  writes:

> Org files don't use a consistent style, despite Org's .dir-locals.el
> setting indent-tabs-mode to t, which should probably be changed to match
> Emacs's nil value.

FWIW, I'm all for setting `indent-tabs-mode' to nil in Org's .dir-locals.el.

Your call, of course.

-- 
 Bastien

Re: TEC: update the new website ML page?

[Bastien]

Hi Russell,

Russell Adams  writes:

> This really needs to state that the Org-mode mailing list is
> subscriber only. Membership is open, but that users should subscribe
> prior to posting. The Worg page for the ML says that.

FWIW, I just slightly updated this page with this paragraph:

If you are not a subscriber to the list, you can still send an email
to emacs-orgmode@gnu.org, we will add you to the whitelist of people
who can reach the list.

> As a second request, can we get a link to Worg on the top level bar?

I'd rather let Timothy decide on this, as he has the whole picture.

Thanks,

-- 
 Bastien

Re: [PATCH] org-plot abstractions and extension

[TEC]

Bastien  writes:

> Applied, with minor modifications of the changelog entries:
>
> - You need to add an entry when creating a new custom variable.
>
> - I suggest saying "option" instead of "custom variable".
>
> - Sentences should be separated by two spaces and start with an
>   uppercase letter.
>
> Also, the convention in Emacs is to avoid whitespaces-only commits,
> you need to fix whitespaces within other non-whitespaces changes in
> a commit.

Thanks for the feedback on the patches! I tried to get it right after my
previous (and first) attempt, but it looks like there are a few things I
still need to take note of. Big improvement though, nonetheless,
hopefully next time they'll be nothing to change :)

All the best,

Timothy

Re: Bug: LaTeX: inline maths expression in \textrm is not fully supported

[Firmin Martin]

> I think you may be expecting too much of org's simple inline LaTeX
> parser.  As soon as you have complex LaTeX, it's best to be explicit
> about it being LaTeX, e.g.:
>
> 1. @@latex:$A = \{n : \textrm{$n$ odd in $X$}\}$@@

Thank you for the advice! This does work for LaTeX export, but if one
would also want to export in HTML, the LaTeX expression is lost. I will
stay with the "multiple \textrm" solution for now. 

Best,

Firmin

Eric S Fraga  writes:

> On Sunday, 13 Dec 2020 at 02:30, Firmin Martin wrote:
>> Sometimes, we want to nest inline maths expression in \textrm to
>> handle spaces easily and avoid repetition.
>>
>> Examples:
>>
>> 1. $A = \{n : \textrm{$n$ odd in $X$}\}$
>
> I think you may be expecting too much of org's simple inline LaTeX
> parser.  As soon as you have complex LaTeX, it's best to be explicit
> about it being LaTeX, e.g.:
>
> 1. @@latex:$A = \{n : \textrm{$n$ odd in $X$}\}$@@
>
> HTH,
> eric
>
> -- 
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4-160-g7c8dce

Re: [PATCH] (org-remove-occur-highlights) Implements option to remove highlights between points

[Bastien]

Kyle Meyer  writes:

> It might be worth stepping back and describing what your use case for
> this change is, and considering other ways to address it (not
> necessarily as a change to Org itself).

Since the problem needs to be revisited, I've closed this patch.

Nicholas, feel free to tackle the initial issue differently and
to provide another patch in another dedicated thread.  Thanks!

-- 
 Bastien

Re: [PATCH] org-preview-latex-fragment dvipng fix for packages in org-latex-packages-alist breaking 'latex' command

[Bastien]

Hi,

Sébastien Miquel  writes:

> If I've understood your problem correctly, simply using (""
> "fontspec" nil) in org-latex-packages-alist should fix your issue.

Since this conversation died, I'm closing this patch.

Feel free to resubmit it if needed.

-- 
 Bastien

Re: [PATCH] ob-java.el: Allow for more whitespace

[Bastien]

ian martins  writes:

> Two patches are attached. One allows for more whitespace in java code
> blocks. The other fixes a bug that would result in a main method being
> wrapped in another main method.

Closing this now, thanks!

-- 
 Bastien

Re: [PATCH] org-manual.org: Remove languages list and update worg link

[Bastien]

Bastien  writes:

> Kyle Meyer  writes:
>
>> ian martins writes:
>>
>>> I pushed two days ago, but the manual hasn't updated yet. I guess it
>>> doesn't update on git hooks like worg. is there a scheduled process or is
>>> there something that must be done?
>>
>> The online manual corresponds to the latest release and updated with
>> each release (as far as I know, though hopefully Bastien or others will
>> correct me if I'm wrong).
>
> Yes, that's correct.

Closing this patch now.

-- 
 Bastien

Re: More on design of org-contacts.el - Re: [UPDATED PATCH] Re: add new link type "contact:" for org-contacts.el

[Bastien]

Hi stardiviner,

what is the last state of your patch?  Feel free to resend it,
I will apply it.

Also, do you want to become the maintainer for org-contacts.el?

Remember, elisp files in contrib/ will soon be extracted from
the repository: https://orgmode.org/list/87wnzfy60h@bzg.fr

Still, it's useful to already know who will be in charge.

Thanks,

-- 
 Bastien

Re: [PATCH] Enhance org-html--build-meta-info

[Bastien]

Hi Timothy,

TEC  writes:

> Thanks for testing this :) I haven't forgotten about this.

Let's wait for Jens feedback on this patch, since he took care of
testing it so far.

In a nutshell, can you restate what problem is this patch fixing?

Is a new option really necessary here?

Are there backward compatibility considerations we should take care of?

> From 1289e381aff7562df96945aa58838ad966aa9211 Mon Sep 17 00:00:00 2001
> From: TEC 
> Date: Thu, 17 Sep 2020 21:27:18 +0800
> Subject: [PATCH] lisp/ox-html.el: make html meta func nicer
>
> * lisp/ox-html.el (org-html--build-meta-info): Multi-line repeated
> structure extracted to new function `org-html--build-meta-entry'.

You need to have a separate changelog entry for any new function or
variable.

> The opportunity was taken to extract most metadata info to custom
> variable `org-html-meta-tags', allowing for easy end-user modification.
> ---
>  lisp/ox-html.el | 131 +++-
>  1 file changed, 73 insertions(+), 58 deletions(-)
>
> diff --git a/lisp/ox-html.el b/lisp/ox-html.el
> index d2f24f5c6..93014e9c7 100644
> --- a/lisp/ox-html.el
> +++ b/lisp/ox-html.el
> @@ -1425,6 +1425,31 @@ not be modified."
>  
>   Template :: Styles
>  
> +(defcustom org-html-meta-tags
> +  '((lambda (_title author _info)
> +  (when (org-string-nw-p author)
> + (list "name" "author" author)))
> +(lambda (_title _author info)
> +  (when (org-string-nw-p (plist-get info :description))
> + (list "name" "description"
> +   (plist-get info :description
> +(lambda (_title _author info)
> +  (when (org-string-nw-p (plist-get info :keywords))
> + (list "keywords" (plist-get info :keywords
> +("name" "generator" "Org Mode"))
> +  "A list of arguments to be passed to `org-html--build-meta-entry'.
> +Each argument can either be an list which is applied, or a function which
> +generates such a list with signature (TITLE AUTHOR INFO) where TITLE and 
> AUTHOR
> +are strings, and INFO a communication plist."
> +  :group 'org-export-html
> +  :package-version '(Org . "9.5")
> +  :type '(repeat
> +   (choice
> +(list (string :tag "Meta label")
> +  (string :tag "label value")
> +  (string :tag "Content value"))
> +function)))
> +
>  (defcustom org-html-head-include-default-style t
>"Non-nil means include the default style in exported HTML files.
>  The actual style is defined in `org-html-style-default' and
> @@ -1835,78 +1860,68 @@ INFO is a plist used as a communication channel."
>  
>  ;;; Template
>  
> +(defun org-html--build-meta-entry (label identity  content-format 
>  content-formatters)
> +  "Construct  tag with LABEL=\"IDENTITY\" and content from 
> CONTENT-FORMAT and CONTENT-FORMATTER."

The first line of this defun is too long.  You can try M-x checkdoc
RET on your elisp files to catch those issues.

Thanks,

-- 
 Bastien

Re: [PATCH] ob-java

[Bastien]

ian martins  writes:

> On Sat, Nov 14, 2020 at 6:48 AM Jarmo Hurri  wrote:
>>
>> >> > It seems that you have changed some classloader settings in the new
>> >> > code. I have examples which used to work perfectly; now they still
>> >> > compile, but fail to run, throwing exception
>> >> >
>> >> > java.lang.NoClassDefFoundError
>> >>
>
> This should be fixed with 93087e0b3a. Thanks for reporting, and sorry
> I missed your first email. I found it. It went to spam for some
> reason.

FWIW I'm closing this so that the ob-java thread does not appear on
updates.orgmode.org anymore.

Thanks,

-- 
 Bastien

ox-slimhtml

[Laszlo Elo]

Hello,

Amin was kind enough to poke me to submit and post about my package, 
ox-slimhtml.
In a nutshell, it is an org-export backend - transcodes Org elements to 
HTML/text output.

My primary use for it, is to create derived export backends. (picture a/b 
testing, for example) 
By default, it outputs HTML5, essentially (as it tries to not ignore current 
output preferences).

Within each transcoder, I tried to pick out the relevant core elements being 
passed through - what I skipped from the original ox-html exporter is the 
domain logic surrounding templating and navigation.

A sample of the output can be seen here http://bald.cat/ox-slimhtml/

From a more detailed perspective, I use it to template the output of some Org 
documents (common sources of truth); these include some minimal Org markup, and 
as such, they provide convenient element-by-element programmatic access. This 
all depends on where you’d like to organize the logic behind each elements’ 
transcoding process, of course - so, for now, I’ll say that it works really 
nice for me. YMMV

:) Laszlo

Re: Please help by becoming a maintainer for an Org Babel file

[Bastien]

Corwin Brust  writes:

> I did exchange emails with the assignment clerk this past week and we
> are not at any roadblocks afaict.  I'll update again in not more than
> (a fhanish/volunteers') three weeks, even if I have nothing
> interesting to report.  Does that sound right?  

Yes, please go ahead and don't hesitate to CC me in your conversation
so that I know where you are in the process.

> I appreciate your checking in on me!

You're welcome, thanks for volunteering!

-- 
 Bastien

Re: [PATCH] org-plot abstractions and extension

[Bastien]

Hi Timothy,

TEC  writes:

> I'll attach all the patches to this email, so there's no ambiguity.
> (crosses fingers for attachments working as expected)

Applied, with minor modifications of the changelog entries:

- You need to add an entry when creating a new custom variable.

- I suggest saying "option" instead of "custom variable".

- Sentences should be separated by two spaces and start with an
  uppercase letter.

Also, the convention in Emacs is to avoid whitespaces-only commits,
you need to fix whitespaces within other non-whitespaces changes in
a commit.

Thanks a lot!

-- 
 Bastien

Re: Please help by becoming a maintainer for an Org Babel file

[Corwin Brust]

In fact the process isn't overr quite yet; thanks for reaching out.

I did exchange emails with the assignment clerk this past week and we are
not at any roadblocks afaict.  I'll update again in not more than (a
fhanish/volunteers') three weeks, even if I have nothing interesting to
report.  Does that sound right?

I appreciate your checking in on me!

On Sun, Dec 13, 2020 at 11:26 PM Bastien  wrote:

> Hi Corwin,
>
> Bastien  writes:
>
> > thanks for volunteering!  Let us know when the paperwork is done, I'll
> > add you as ob-perl.el maintainer then.
>
> FWIW, I added you as a maintainer for ob-perl.el on the master branch.
>
> Can you confirm the copyright process is over?
>
> Sorry if I missed an email saying so already.
>
> Best,
>
> --
>  Bastien
>


-- 
*Corwin*
612-217-1742
612-695-4276 (signal)
*cor...@bru.st *

Re: Please help by becoming a maintainer for an Org Babel file

[Bastien]

Hi Corwin,

Bastien  writes:

> thanks for volunteering!  Let us know when the paperwork is done, I'll
> add you as ob-perl.el maintainer then.

FWIW, I added you as a maintainer for ob-perl.el on the master branch.

Can you confirm the copyright process is over?

Sorry if I missed an email saying so already.

Best,

-- 
 Bastien

Re: org-table change time from UTC to other timezones

[Alan E. Davis]

Maxim:

Both of these links, like your comments, are incredibly useful.

Happy New Year (however you may measure that thing)

On Sun, Dec 13, 2020 at 9:05 AM Maxim Nikulin  wrote:

> 2020-12-13 Alan E. Davis wrote:
> >
> > I think R would not be too unwieldy as a hammer here.  My use case  is a
> > humble one: just take a several clock times in HH:MM format (utc) and
> > adjust to  another timezone by adding or subtracting the relevant number
> > of hours.  The day of week is not important; i will have to deal with
> > it.  I did imagine a conditional subtraction by adding of subtracting
> > 24:00 as needed.
>
> Likely your approach is suitable for you and you could ignore my
> comments. I just live in a city having longitude that should be (and it
> was) the border between time zones, so majority do not like any
> decision. Since cancellation of DST 10 years ago, local time has been
> shifted 2 times...
>
> To get time offset for some timezone, it is necessary to specify
> timestamp, so a date is required in addition to time. Namely day of week
> is mostly irrelevant.
>
> Time transitions are usually arranged at night when most of people are
> not active. Astronomers is a different case, that is why their chance to
> face a timezone bug is higher.
>
> When operations with arbitrary time zones are not required and a process
> could be run with TZ variable set to desired time zone, libc functions
> should work correctly. I have not tried elisp functions
>
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Time-Zone-Rules.html
>
> A bookmark for those who still hopes to avoid complications with
> time-related operations
>
> Falsehoods programmers believe about time
>
> https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
>
>
>

-- 
  "This ignorance about the limits of the earth's ability to absorb
   pollutants should be reason enough for caution in the release
   of polluting substances."
   ---Meadows et al.   1972.  Limits to Growth
.
(p. 81)

Re: Emacs as an Org LSP server

[Tim Cross]

Gerry Agbobada  writes:

> On Sun, Dec 13, 2020, at 21:23, Jean Louis wrote:
>> * TEC  [2020-12-13 20:35]:
>> > > From a perspective that some server has to know what user is writing
>> > > it is advisable to use one own's servers. But if idea gets popular
>> > > some company will commercialize it and centralize user's data and
>> > > privacy is gone.
>> >
>> > FYI the nature of LSP (as I understand it) is that the "server" is a
>> > locally running service that responds to signals from a "client" (code
>> > editor / IDE).
>>
>> That is how it starts until corporation like Github or somebody else
>> takes it over. Just look at Github pattern. Git was decentralized
>> system that they centralized for 50 million developers and included
>> eye candies that one cannot self-host as one wants.
>>
>
> Hello,
>
> The "server" in Language Server Protocol is a program that answers to LSP 
> requests that's all. It could just be a program written in a FOSS licence 
> (like Palantir pyls
> https://github.com/palantir/python-language-server ) that needs to read the 
> files on your computer in order to answer requests. Data (i.e your org files 
> on your filesystem) does not need to be centralized for it to work.
>
> Git was eventually ""centralized"" by github because version control systems 
> and software forges are based on sharing the data between multiple users, so 
> someone can (and will) offer the tradeoff to make the sharing easier at the 
> cost of privacy/freedom etc.
>
> LSP servers are just file indexers that implement a common protocol to make 
> writing integrations easier. They are called servers because they are long 
> running process listening to messages, but really everything could (and most 
> of the time do) run offline, with file watches over your "project" and 
> sockets for I/O with clients that run locally
>
>

Good clarification and content. It is important to separate
implementations from protocol. LSP is just a protocol to allow an
interface between an editor and a service which can provide additional
functionality in an editor independent manner.

--
Tim Cross

Re: Emacs as an Org LSP server

[George Mauer]

I think maybe you might be thrown off by the word "server"? Lsp is just a
standardization of how an editor can do language-specific things. The fact
that standardization exists makes the whole thing pluggable by various
services. These typically run in a separate process - which is a good idea
anyways - on the same machine and the plugin just starts that prices and
communicated to it.

Typescript, c#, I think python, and JavaScript (and maybe Java?) plugins
already do this

On Sun, Dec 13, 2020, 14:34 Jean Louis  wrote:

> * TEC  [2020-12-13 20:35]:
> > > From a perspective that some server has to know what user is writing
> > > it is advisable to use one own's servers. But if idea gets popular
> > > some company will commercialize it and centralize user's data and
> > > privacy is gone.
> >
> > FYI the nature of LSP (as I understand it) is that the "server" is a
> > locally running service that responds to signals from a "client" (code
> > editor / IDE).
>
> That is how it starts until corporation like Github or somebody else
> takes it over. Just look at Github pattern. Git was decentralized
> system that they centralized for 50 million developers and included
> eye candies that one cannot self-host as one wants.
>
> Jean
>
>

Re: Emacs as an Org LSP server

[Gerry Agbobada]

On Sun, Dec 13, 2020, at 21:23, Jean Louis wrote:
> * TEC  [2020-12-13 20:35]:
> > > From a perspective that some server has to know what user is writing
> > > it is advisable to use one own's servers. But if idea gets popular
> > > some company will commercialize it and centralize user's data and
> > > privacy is gone.
> > 
> > FYI the nature of LSP (as I understand it) is that the "server" is a
> > locally running service that responds to signals from a "client" (code
> > editor / IDE).
> 
> That is how it starts until corporation like Github or somebody else
> takes it over. Just look at Github pattern. Git was decentralized
> system that they centralized for 50 million developers and included
> eye candies that one cannot self-host as one wants.
> 

Hello,

The "server" in Language Server Protocol is a program that answers to LSP 
requests that's all. It could just be a program written in a FOSS licence (like 
Palantir pyls 
https://github.com/palantir/python-language-server ) that needs to read the 
files on your computer in order to answer requests. Data (i.e your org files on 
your filesystem) does not need to be centralized for it to work.

Git was eventually ""centralized"" by github because version control systems 
and software forges are based on sharing the data between multiple users, so 
someone can (and will) offer the tradeoff to make the sharing easier at the 
cost of privacy/freedom etc.

LSP servers are just file indexers that implement a common protocol to make 
writing integrations easier. They are called servers because they are long 
running process listening to messages, but really everything could (and most of 
the time do) run offline, with file watches over your "project" and sockets for 
I/O with clients that run locally


Gerry Agbobada

Re: [PATCH] ob-ruby.el: Don't reuse the same buffer among different named

[Aaron Madlon-Kay]

On Mon, Dec 14, 2020 at 5:00 AM Kyle Meyer  wrote:
> Thanks.  Pushed (57a70d505), tacking on a Reported-by trailer to the
> commit message.

Thanks very much! The fix is working for me.

-Aaron

Re: Bring up a screen giving option to open a series of orgmode files

[Jean Louis]

* Ihor Radchenko  [2020-12-14 03:32]:
> In another email you mentioned:
> 
> > Easier is to click and click n for next and p for previous. Once you
> > find reference click F5 and describe the item.
> > 
> > That is easier than teaching people Emacs. Then group of people can
> > capture PDF references quite efficiently.
> 
> One can make a custom Emacs configuration binding "n" for next, "p" for
> previous, and "F5" to describe item. What should be taught?

It was related to using xpdf to capture annotations and references.

Re: Bring up a screen giving option to open a series of orgmode files

[Ihor Radchenko]

Jean Louis  writes:

>> I guess one would not need to teach people about everything in Emacs. If
>> the aim is just editing and viewing PDF, one can provide custom Emacs
>> configuration with added toolbars and menu items for common operations
>> with pdf. I do not see why it would be any different from specialised
>> pdf viewers. 
>
> To see that assign Emacs tutorial to several people and observe
> results. I do.

I think you misunderstood what I meant.

In another email you mentioned:

> Easier is to click and click n for next and p for previous. Once you
> find reference click F5 and describe the item.
> 
> That is easier than teaching people Emacs. Then group of people can
> capture PDF references quite efficiently.

One can make a custom Emacs configuration binding "n" for next, "p" for
previous, and "F5" to describe item. What should be taught?

Re: Bring up a screen giving option to open a series of orgmode files

[Ihor Radchenko]

Jean Louis  writes:

>> I guess one would not need to teach people about everything in Emacs. If
>> the aim is just editing and viewing PDF, one can provide custom Emacs
>> configuration with added toolbars and menu items for common operations
>> with pdf. I do not see why it would be any different from specialised
>> pdf viewers. 
>
> To see that assign Emacs tutorial to several people and observe
> results. I do.

I think you misunderstood what I meant.

In another email you mentioned:

> Easier is to click and click n for next and p for previous. Once you
> find reference click F5 and describe the item.
> 
> That is easier than teaching people Emacs. Then group of people can
> capture PDF references quite efficiently.

One can make a custom Emacs configuration binding "n" for next, "p" for
previous, and "F5" to describe item. What should be taught?

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 

Re: Org Capture Menu cannot be fully viewed

[Bastien]

Jean Louis  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]

* Bastien  [2020-12-14 01:00]:
> 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 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: Adding Org Files to org-agenda-files

[Jean Louis]

* Tim Cross  [2020-12-14 00:42]:
> 
> 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.

I do recognize, but the Org manual does not:

(info "(org) TODO Items")

> 5 TODO Items
> 

> Org mode does not maintain TODO lists as separate documents(1).
> Instead, TODO items are an integral part of the notes file, because TODO
> items usually come up while taking notes!  With Org mode, simply mark
> any entry in a tree as being a TODO item.  In this way, information is
> not duplicated, and the entire context from which the TODO item emerged
> is always present.

> Of course, this technique for managing TODO items scatters them
> throughout your notes file.  Org mode compensates for this by providing
> methods to give you an overview of all the things that you have to do.

Thus the Org manual is already giving a technique for managing TODO
items and admitting it is scattering things. Why not then straight
give to users one page with at least 3-5 other paradigms that users
can follow. This way users follow only the scattering paradigm.

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

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

You may be right, I never used Org mode to plan software. I know those
workflows and it should be planned and so on, but I don't. Instead of
planning I just make what I personally need.

> For example, during the R 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.

I like to see some concept. All our projects also have R
stage. Preliminary Site Assessment and Inspection project is
such. That is why it is part of the project. After that project has
been done the next project is devised. But there is overall plan that
says:

- do the R
- devise project for result from R

> You have limited ability to identify all the stages, all the tasks
> or make terribly accurate estimates on completion time.

That stage is defined on my side as part of the plan. We know that we
will have limited ability, but that is why projects can branch, expand
dynamically. 

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

Even this is qualification stage where it is obviously and your
description shows it, part of the overall plan.

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

As a document preparation system it is possibly suitable, more than
suitable for planning of what you described. And nothing you described
does not seem to fall out of planning capability.

Any scenario may be described by documents. General text is enough. So
Org mode is more than enough to describe such planning. Unless you
refer to something else than what I think.

As a planning system with TODO stuff, or actionable items, I am
arguing how useful it is in that scenario or any scenario. What you
described has its logic, chronology, it has its plan. You described
overall plan. Nothing different than my scenario. Paradigm is same,
maybe you 

Re: Org Capture Menu cannot be fully viewed

[TRS-80]

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.

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

[Jean Louis]

* Tim Cross  [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))

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: Org Capture Menu cannot be fully viewed

[TRS-80]

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

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

[Bastien]

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.

-- 
 Bastien

Re: Org Capture Menu cannot be fully viewed

[Jean Louis]

* 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

Jean

Re: Someone to oversee Org bugs as reported with M-x report-emacs-bugs?

[Tim Cross]

Bastien  writes:

> Jean Louis  writes:
>
>> * Bastien  [2020-12-11 09:28]:
>>> Thanks Jean, I agree with most of your points.
>>>
>>> Are you volunteering for this task?
>>
>> I am anyway answering to people. So I am already doing it.
>
> Thanks but we need someone that is willing to personnally take
> charge of this.
>
>> But I did not copy to Org mailing list as I heard it is subscriber
>> based.
>
> Maybe copying the emacs-orgmode@ list won't be necessary when debbugs
> can forward the email there.
>
>> Normally GNU mailing lists are not subscriber based.
>
> I don't know about other GNU mailing lists but I'm not under the
> impression that GNU mailing lists are "normally" not subscriber based.

Hi Bastien,

I'm not in a position right now to help with this, but there are a few
things happening which may allow me the time to help after Feb next
year. If you have not got someone by then, please come back to me and
I'll try and help with this.

Tim

--
Tim Cross

Re: Org Capture Menu cannot be fully viewed

[Jean Louis]

* TEC  [2020-12-13 23:38]:
> 
> Hi Jean, a few thoughts.
> 
> Jean Louis  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

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

Re: Adding Org Files to org-agenda-files

[Tim Cross]

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


--
Tim Cross

Re: #+include and org-export-before-processing-hook

[Eric S Fraga]

On Sunday, 13 Dec 2020 at 21:05, Nicolas Goaziou wrote:
> There is also `org-export-before-parsing-hook'.

 missed this.  Thank you both.  Using the right hook allows me to
do what I wanted perfectly!

As always, if there's something I want to do in org, the feature is
already there.  It is simply that I am not so good at finding it...  :-)

Thanks again,
eric

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-160-g7c8dce

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

[TRS-80]

On 2020-12-13 15:37, Jean Louis wrote:

* pie...@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

[TRS-80]

On 2020-12-13 13:41, pie...@caramail.com wrote:

From: "Jean Louis" 

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

[Tim Cross]

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.

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

[Jean Louis]

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

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: Emacs inserts hardwired org-agenda-files variable, overwriting user options

[Jean Louis]

* Christopher Dimech  [2020-12-13 20:49]:
> > Reference to manual:
> > (info "(org) TODO Items")
> >
> > And it is definitely not a "plain text". It is probably largest mode
> > for Emacs, a true and full application handling much more than plain
> > text. It has more than 129 Emacs Lisp files. Maybe in beginning it was
> > plain text, not any more now. Now it is a wannabe database.
> 
> In a way it is becoming the opposite of what Carsten was trying to do
> in the beginning.  And plain text is always portable.
> 
> We should not exclude the original intention and use, making it fully
> database.

It is already text type of a database with structured data built into
properties and tags, headings, body of headings, etc. Just that it is
scattered database of things that do not have well defined its own
place.

As I see it, one could keep Org file in the database and edit it on
the file system and that it all gets updated to the database. That way
it would become collaborative Org mode. It is easier than one can
imagine.

I was using simple function to update Org TODO tasks to database.

(defun hyperscope-capture-org-heading ()
  "Captures Org heading and stores it in the Hyperscope dynamic
  knowledge repository"
  (interactive)
  (let* ((body (org-copy-subtree nil nil nil t))
 (body (pop kill-ring))
 (body (org-no-properties body))
 (heading (org-get-heading))
 (created (org-property-values "CREATED"))
 (date (if created (substring (car created) 1 11) nil))
 (body (with-temp-buffer
 (insert body)
 (org-mode)
 (org-back-to-heading)
 (kill-line)
 (delete-matching-lines ":PROPERTIES:")
 (delete-matching-lines ":CREATED:")
 (delete-matching-lines ":ID:")
 (delete-matching-lines ":END:")
 (buffer-string
(hyperscope-add-note-to-set-1 heading body date)))

(defun hyperscope-capture-org-heading-as-note-for-person ()
  "Captures Org heading for a person and stores it in the
  Hyperscope dynamic knowledge repository"
  (interactive)
  (let* ((body (org-copy-subtree nil nil nil t))
 (body (pop kill-ring))
 (body (org-no-properties body))
 (heading (org-get-heading))
 (created (org-property-values "CREATED"))
 (date (if created (substring (car created) 1 11) nil))
 (body (with-temp-buffer
 (insert body)
 (org-mode)
 (org-back-to-heading)
 (kill-line)
 (delete-matching-lines ":PROPERTIES:")
 (delete-matching-lines ":CREATED:")
 (delete-matching-lines ":ID:")
 (delete-matching-lines ":END:")
 (buffer-string)))
 (contact (cf-search-id (read-from-minibuffer "Contact: " nil nil nil 
'cf-search-history
(hyperscope-add-note-to-set-1 heading body date)))

Similar functions could be used to to simply update the record in the
database. And all meta data of Org properties, tags, etc, all that
could be inserted into database.

Jean

Re: Org Capture Menu cannot be fully viewed

[TEC]

Hi Jean, a few thoughts.

Jean Louis  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: Adding Org Files to org-agenda-files

[Jean Louis]

* Ihor Radchenko  [2020-12-13 18:33]:
> 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.

I like to know it all to collect or steal what is good. ;-)

I am researching other software too and collecting what is good.

> My personal experience is doing a lot of research work. That's probably
> on the other side of the spectrum from the environment you are working
> in. I cannot define very concrete steps to execute a research project.
> Not because it is impossible, but rather because failures are pretty
> much guaranteed far before all the steps are executed. Moreover, most of
> time, it is not possible to consult someone else on resolution of the
> problem causing blockage, simply because the problem is something that
> never ever appeared in the past (that's the whole point of doing
> research). Instead, I need to spend a significant time trying to find
> *similar* problems digging through literature, talking to people working
> on related problems, or even just thinking. Then, waiting until the
> solution appears becomes a waste of time (there is even no guarantee
> that solution exists) - if there are other alternative approaches to
> achieve the global project objective, they would better be tried before
> the blockage in one particular direction in solved. In fact, switching
> to alternative approaches (or even projects) sometimes help to look at
> the problem from different angle and solve it. The described difficulty
> is *underestimation* of what can happen - even the initial project
> objectives can be changed according to the current research results.
> Trying to stick to a strict project structure in such a situation is a
> waste of time - project must be re-created from scratch very too often,
> unless it is more flexible from the very beginning.

When researching is not conducting clear plan. It is different stage
or can be independent activity of some planning with firm
objectives. I do research too. Plans are based on research
information. I do not mix research information and planning based on
research and that way plans remains without disturbance. They can be
read on screen what people do, executed from mobile phone or from
printed papers.

More interesting hyperlinks:

Planning For People Who Suck At Planning
https://debbieinshape.com/suck-planning/

How to STOP Over-Planning (And Start Doing!)
https://eringobler.com/overplanning/

Planning fallacy: why people suck at planning
https://blog.sandglaz.com/people-suck-at-planning/

The last above also speaks of our human over or under estimations. To
make things go right one has to have good sense of reality. Otherwise
schedules and deadline never become what they are intended to become.

> The described situation is where NEXT tasks/projects can become
> extremely helpful. Multiple NEXT tasks do not mean that I need to look
> at them every day and switch from one to another. There are NEXT tasks
> and there are NEXT tasks that are actually scheduled on specific day.
> One day cannot have more than several (ideally one) NEXT task (possibly
> containing a checklist). That's where agenda comes handy. It is not used
> to decide what to do during that day. It merely shows earlier decision
> when planning which project (and corresponding doable NEXT task) to do
> on specific day. Other items in agenda are things that must be done on
> that day anyway (meetings, mandatory habits, etc). Polluting agenda with
> unnecessary staff is no better than mindless browsing of youtube.

I do agree that thinking may be helped, just that as "next" I can have
only one next by its meaning of immediately following by its time or
order. I do not mind you having that type of thinking as you relate
your meaning to the text, tags or anything you have in front of
you. My point is that NEXT will not mean to onlooker the same what it
means to you. It would require explanations and learning the habit as
I always look on it how a group of people would look on it.

The nodes in my meta level dynamic knowledge repository have "Set ➜"
and by using that arrow I know I can enter into the node, it is not
just a note, I can go into the subtree. Such marking with the arrow
would be more logical but NEXT to me.

What is next probably means it is doable something and there may be
multiple doable items.

The items we put in planning are all doable. We do not put those not
doable as such are chunked into steps until each step becomes
doable. There is no block or obstacle for staff on ground in reading,
passing over, executing those steps as each step is doable for 
them. They know what is next by simple looking what was done
previously. The true meaning of "next" is used there.

Some small purchasing projects may give direction naturally which shop
is next to be visited for 

Re: Bring up a screen giving option to open a series of orgmode files

[Jean Louis]

* Christopher Dimech  [2020-12-13 21:02]:
> > Sent: Sunday, December 13, 2020 at 4:13 PM
> > From: "Jean Louis" 
> > To: "Ihor Radchenko" 
> > Cc: "Maxim Nikulin" , emacs-orgmode@gnu.org
> > Subject: Re: Bring up a screen giving option to open a series of orgmode 
> > files
> >
> > * Ihor Radchenko  [2020-12-13 03:45]:
> > > Jean Louis  writes:
> > >
> > > > While it is easy to teach people to open single program, press a key,
> > > > and insert title, it is harder and time consuming to teach random
> > > > people how to use Emacs. This may not be true, it is just my current
> > > > impression.
> > >
> > > I guess one would not need to teach people about everything in Emacs. If
> > > the aim is just editing and viewing PDF, one can provide custom Emacs
> > > configuration with added toolbars and menu items for common operations
> > > with pdf. I do not see why it would be any different from specialised
> > > pdf viewers.
> >
> > To see that assign Emacs tutorial to several people and observe
> > results. I do.
> 
> It gets hard and you can see them sweating.

Quite contrary, they go through tutorial and learn whati is in
tutorial. But it will take few hours, one day. Then it needs habit.

Easier is to click and click n for next and p for previous. Once you
find reference click F5 and describe the item.

That is easier than teaching people Emacs. Then group of people can
capture PDF references quite efficiently.

Jean

Re: Emacs as an Org LSP server

[Jean Louis]

* TEC  [2020-12-13 20:35]:
> > From a perspective that some server has to know what user is writing
> > it is advisable to use one own's servers. But if idea gets popular
> > some company will commercialize it and centralize user's data and
> > privacy is gone.
> 
> FYI the nature of LSP (as I understand it) is that the "server" is a
> locally running service that responds to signals from a "client" (code
> editor / IDE).

That is how it starts until corporation like Github or somebody else
takes it over. Just look at Github pattern. Git was decentralized
system that they centralized for 50 million developers and included
eye candies that one cannot self-host as one wants.

Jean

Re: #+include and org-export-before-processing-hook

[Nicolas Goaziou]

Hello,

Juan Manuel Macías  writes:

> I have the same problem with a function that I wrote to not export
> certain footnotes, and to date I have not been able to fix it. According
> to the `org-export-before-processing-hook' docstring:
>
> " *This is run before include keywords and macros are expanded*
> and Babel code blocks executed, on a copy of the original buffer
> being exported.  Visibility and narrowing are preserved.  Point
> is at the beginning of the buffer.

There is also `org-export-before-parsing-hook'.

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] ob-ruby.el: Don't reuse the same buffer among different named

[Kyle Meyer]

Juri Linkov writes:

> Thanks for notifying me.  I completely agree that the most suitable
> place to fix would be in org-babel-ruby-initiate-session.  So here
> is a patch that I tested with different org header args:
[...]
> Subject: [PATCH] ob-ruby.el: Funcall command if it's a function from
>  inf-ruby-implementations
>
> * lisp/ob-ruby.el (org-babel-ruby-initiate-session): When 'command'
> is a function from 'inf-ruby-implementations', use 'funcall' to get
> a command string for the first arg of 'run-ruby-or-pop-to-buffer'.
> This is like what 'run-ruby' does.

Thanks.  Pushed (57a70d505), tacking on a Reported-by trailer to the
commit message.

Re: [PATCH] ob-ruby.el: Don't reuse the same buffer among different named

[Juri Linkov]

>> I'm not sure if it should be org-mode's responsibility to resolve the
>> actual command string, or if it should be done by
>> `run-ruby-or-pop-to-buffer'. (It kind of seems like the latter?)
>>
>> Any thoughts?
>
> Given the current situation, I don't see a good option aside from doing
> the functionp dance in org-babel-ruby-initiate-session as well.  Even if
> inf-ruby's check was moved downstream of run-ruby-or-pop-to-buffer, I
> think it'd be good to fix on ob-ruby's end to work with the current
> inf-ruby.
>
> Juri, what do you think?

Thanks for notifying me.  I completely agree that the most suitable
place to fix would be in org-babel-ruby-initiate-session.  So here
is a patch that I tested with different org header args:

>From 41218eafa9285844ea4e84c52e265b2c0232c1ba Mon Sep 17 00:00:00 2001
From: Juri Linkov 
Date: Sun, 13 Dec 2020 21:21:37 +0200
Subject: [PATCH] ob-ruby.el: Funcall command if it's a function from
 inf-ruby-implementations

* lisp/ob-ruby.el (org-babel-ruby-initiate-session): When 'command'
is a function from 'inf-ruby-implementations', use 'funcall' to get
a command string for the first arg of 'run-ruby-or-pop-to-buffer'.
This is like what 'run-ruby' does.
---
 lisp/ob-ruby.el | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/lisp/ob-ruby.el b/lisp/ob-ruby.el
index 5ed29f889..2e33bfa29 100644
--- a/lisp/ob-ruby.el
+++ b/lisp/ob-ruby.el
@@ -159,13 +159,16 @@ org-babel-ruby-initiate-session
 then create one.  Return the initialized session."
   (unless (string= session "none")
 (require 'inf-ruby)
-(let* ((cmd (cdr (or (assq :ruby params)
-			 (assoc inf-ruby-default-implementation
-inf-ruby-implementations
+(let* ((command (cdr (or (assq :ruby params)
+			 (assoc inf-ruby-default-implementation
+inf-ruby-implementations
 	   (buffer (get-buffer (format "*%s*" session)))
 	   (session-buffer (or buffer (save-window-excursion
 	(run-ruby-or-pop-to-buffer
-	 cmd (or session "ruby")
+	 (if (functionp command)
+	 (funcall command)
+	   command)
+	 (or session "ruby")
 	 (unless session
 	   (inf-ruby-buffer)))
 	(current-buffer)
-- 
2.25.1

Re: Org Capture Menu cannot be fully viewed

[Christopher Dimech]

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

[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 

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 user-error: Abort

[daniela-spit]

 

 
 

Sent: Sunday, December 13, 2020 at 7:07 PM
From: "Diego Zamboni" 
To: "Ihor Radchenko" 
Cc: daniela-s...@gmx.it, bug-gnu-em...@gnu.org, "Org-Mode mailing list" 
Subject: Re: org-capture user-error: Abort





> Emacs fires "user-error: Abort" after pressing "q" to abort org-capture.

This is intended. Normally, it just shows up as a message in the
minibuffer. Or do you have debug-on-error enabled?

 

Same as Ihor, when I press `q` in the org-capture screen I only see "Abort" in the minibuffer. Where do you see the `user-error`?  As long as the effect is what you need (getting out of the capture screen), what is the problem with the code using the `user-error` function to achieve this effect?

 

I use it to build my templates (incl. switching between templates) and could get many errors.

To test functionality, I custamarily abort the capture.

 

 

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 user-error: Abort

[Diego Zamboni]

>
>
> > Emacs fires "user-error: Abort" after pressing "q" to abort org-capture.
>
> This is intended. Normally, it just shows up as a message in the
> minibuffer. Or do you have debug-on-error enabled?
>

Same as Ihor, when I press `q` in the org-capture screen I only see "Abort"
in the minibuffer. Where do you see the `user-error`?  As long as the
effect is what you need (getting out of the capture screen), what is the
problem with the code using the `user-error` function to achieve this
effect?

Re: Bring up a screen giving option to open a series of orgmode files

[Christopher Dimech]

> Sent: Sunday, December 13, 2020 at 4:13 PM
> From: "Jean Louis" 
> To: "Ihor Radchenko" 
> Cc: "Maxim Nikulin" , emacs-orgmode@gnu.org
> Subject: Re: Bring up a screen giving option to open a series of orgmode files
>
> * Ihor Radchenko  [2020-12-13 03:45]:
> > Jean Louis  writes:
> >
> > > While it is easy to teach people to open single program, press a key,
> > > and insert title, it is harder and time consuming to teach random
> > > people how to use Emacs. This may not be true, it is just my current
> > > impression.
> >
> > I guess one would not need to teach people about everything in Emacs. If
> > the aim is just editing and viewing PDF, one can provide custom Emacs
> > configuration with added toolbars and menu items for common operations
> > with pdf. I do not see why it would be any different from specialised
> > pdf viewers.
>
> To see that assign Emacs tutorial to several people and observe
> results. I do.

It gets hard and you can see them sweating.

Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options

[Christopher Dimech]

> Sent: Sunday, December 13, 2020 at 6:31 PM
> From: "Jean Louis" 
> To: "Ihor Radchenko" 
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting 
> user options
>
> * Ihor Radchenko  [2020-12-13 12:25]:
> > Jean Louis  writes:
> >
> > > Org files I have always found useful for project and plan documents
> > > preparation, in particular LaTeX and PDF export. As that way I get
> > > better readability on screen and good printed document.
> > >
> > > None of such projects and plans need be marked with TODO as its nature
> > > is that it is action plan, all items are actionable items. We print a
> > > project and execute it. People report on project steps by email.
> >
> > I disagree. Or rather it depends on workflow:
> > In the process of writing a plan or document there is sometimes an urge
> > to fix small details instead of finishing the first draft and moving to
> > more fine-grained edits afterwards. One way around this urge is quickly
> > inserting an inline todo item and continuing to write (another way is
> > writing on paper, but one would need to spend extra time re-typing the
> > hand writing later).
>
> Aha yes, in the context of finishing documents some items cannot be
> completed and that is where TODO comes handy to know where to come
> back to finish the document, while other items get completed in the
> same time. But then again I never need an Org mode for that. I write
> in LaTeX and plain TeX too, there are programs, so I always leave
> there some tags in comments, usually also TODO. But is not Org mode
> dependent.

It becomes important for professional writers in the context of finishing
articles and books.

> Practically, if I write "TODO" on the heading then something is very
> wrong with all heading. I write a tag ;; TODO in Lisp code when I need
> to improve specific line of code to something else in future. Anybody
> can invent any kind of tags or even just note line numbers at begin or
> end of file. Should not be Org related in general.
>
> If my text under heading is large I rather like to bookmark where to
> come then to rely on TODO tag on the heading as it will not pinpoint
> where exactly I have to continue.
>
> > If the document text has inline todo items, it could be useful to mark
> > the top-level headline todo as well, simply to remind about any ideas
> > postponed during the writing. Such headline cannot be switched to done
> > if org enforced todo dependencies.
>
> Do you mean this:
>
> ** DONE Objective
>CLOSED: [2020-12-13 Sun 20:00]
> *** TODO [#B] Step to do 1
> *** TODO Step to do 2
>
> when org-enforce-todo-dependencies is true I can still say DONE for
> Objective above. I have mentioned it today already. Maybe it works on
> your side, it does not work here. Do I do something wrong? I am on
> development Emacs version and it does not enforce under emacs -Q
>
> Project planning shall always start backwards from known objective to
> be achieved. Subordinate tasks should become superfluous or redundant
> as soon as objective have been achieved.
>
> Scattered tasks without objective also have its objectives, they are
> just not sorted well. Good organizing means to put it under right
> objective and work by achieving objectives. City administrations do
> like that. Military does like that. Boy scouts do like
> that. Humanitarian organization.
>
> > Todo keywords don't have to be included into exported version of the
> > document.
>
> Sure. Sometimes is necessary, sometimes not.
>
> > >> Unless I am badly mistaken, I think this is only true when
> > >> org-enforce-todo-dependencies is non-nil?
> > >
> > > Variable is nil on my side.
> > >
> > > - [-] Something
> > >   - [ ] one
> > >   - [ ] two
> > >   - [X] three
> > >
> > > I cannot mark Something to be done without marking those subordinate
> > > items. Changing org-enforce-todo-dependencies does not change
> > > anything. User will need to lie to oneself to close those items to
> > > become able to close senior item.
> >
> > I believe it is hard-coded. One may send a feature request to have more
> > control over this behaviour.
>
> It looks like I am only one observing that. And especially me I do not
> like depending on Org mode to dictate how to close items. So when
> there is somebody else to join in the notion that is where feature is
> appropriate. Otherwise I consider Org rather made and designed for
> other way thinkers and doers, not for us who think from senior
> objectives as priorities where subordinate items should become
> redundant and not marked as "done".
>
> My personal list of for a day has 7 items currently. Not 250. Those
> are rather objectives, goals and purposes. Single items under
> objectives are well known actions to be done and need not be marked as
> TODO, but I can. My focus is on the meaning of what has to be done and
> I do not need to look into tags or properties. Your informational
> emails gave me to thinking so I have 

Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options

[Christopher Dimech]

> Sent: Sunday, December 13, 2020 at 6:31 PM
> From: "Jean Louis" 
> To: "Ihor Radchenko" 
> Cc: emacs-orgmode@gnu.org
> Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting 
> user options
>
> * Ihor Radchenko  [2020-12-13 12:25]:
> > Jean Louis  writes:
> >
> > > Org files I have always found useful for project and plan documents
> > > preparation, in particular LaTeX and PDF export. As that way I get
> > > better readability on screen and good printed document.
> > >
> > > None of such projects and plans need be marked with TODO as its nature
> > > is that it is action plan, all items are actionable items. We print a
> > > project and execute it. People report on project steps by email.
> >
> > I disagree. Or rather it depends on workflow:
> > In the process of writing a plan or document there is sometimes an urge
> > to fix small details instead of finishing the first draft and moving to
> > more fine-grained edits afterwards. One way around this urge is quickly
> > inserting an inline todo item and continuing to write (another way is
> > writing on paper, but one would need to spend extra time re-typing the
> > hand writing later).
>
> Aha yes, in the context of finishing documents some items cannot be
> completed and that is where TODO comes handy to know where to come
> back to finish the document, while other items get completed in the
> same time. But then again I never need an Org mode for that. I write
> in LaTeX and plain TeX too, there are programs, so I always leave
> there some tags in comments, usually also TODO. But is not Org mode
> dependent.
>
> Practically, if I write "TODO" on the heading then something is very
> wrong with all heading. I write a tag ;; TODO in Lisp code when I need
> to improve specific line of code to something else in future. Anybody
> can invent any kind of tags or even just note line numbers at begin or
> end of file. Should not be Org related in general.
>
> If my text under heading is large I rather like to bookmark where to
> come then to rely on TODO tag on the heading as it will not pinpoint
> where exactly I have to continue.
>
> > If the document text has inline todo items, it could be useful to mark
> > the top-level headline todo as well, simply to remind about any ideas
> > postponed during the writing. Such headline cannot be switched to done
> > if org enforced todo dependencies.
>
> Do you mean this:
>
> ** DONE Objective
>CLOSED: [2020-12-13 Sun 20:00]
> *** TODO [#B] Step to do 1
> *** TODO Step to do 2
>
> when org-enforce-todo-dependencies is true I can still say DONE for
> Objective above. I have mentioned it today already. Maybe it works on
> your side, it does not work here. Do I do something wrong? I am on
> development Emacs version and it does not enforce under emacs -Q
>
> Project planning shall always start backwards from known objective to
> be achieved. Subordinate tasks should become superfluous or redundant
> as soon as objective have been achieved.
>
> Scattered tasks without objective also have its objectives, they are
> just not sorted well. Good organizing means to put it under right
> objective and work by achieving objectives. City administrations do
> like that. Military does like that. Boy scouts do like
> that. Humanitarian organization.
>
> > Todo keywords don't have to be included into exported version of the
> > document.
>
> Sure. Sometimes is necessary, sometimes not.
>
> > >> Unless I am badly mistaken, I think this is only true when
> > >> org-enforce-todo-dependencies is non-nil?
> > >
> > > Variable is nil on my side.
> > >
> > > - [-] Something
> > >   - [ ] one
> > >   - [ ] two
> > >   - [X] three
> > >
> > > I cannot mark Something to be done without marking those subordinate
> > > items. Changing org-enforce-todo-dependencies does not change
> > > anything. User will need to lie to oneself to close those items to
> > > become able to close senior item.
> >
> > I believe it is hard-coded. One may send a feature request to have more
> > control over this behaviour.
>
> It looks like I am only one observing that. And especially me I do not
> like depending on Org mode to dictate how to close items. So when
> there is somebody else to join in the notion that is where feature is
> appropriate. Otherwise I consider Org rather made and designed for
> other way thinkers and doers, not for us who think from senior
> objectives as priorities where subordinate items should become
> redundant and not marked as "done".
>
> My personal list of for a day has 7 items currently. Not 250. Those
> are rather objectives, goals and purposes. Single items under
> objectives are well known actions to be done and need not be marked as
> TODO, but I can. My focus is on the meaning of what has to be done and
> I do not need to look into tags or properties. Your informational
> emails gave me to thinking so I have implemented it all.
>
> > > If I do turn on the mentioned variable `org-enforce-todo-dependencies'

Re: Emacs inserts hardwired org-agenda-files variable, overwriting user options

[Christopher Dimech]

> Sent: Sunday, December 13, 2020 at 2:19 PM
> From: "Jean Louis" 
> To: daniela-s...@gmx.it
> Cc: to...@tuxteam.de, emacs-orgmode@gnu.org, "Ihor Radchenko" 
> 
> Subject: Re: Emacs inserts hardwired org-agenda-files variable, overwriting 
> user options
>
> * daniela-s...@gmx.it  [2020-12-13 08:52]:
> > > In general Org mode is excellent for personal TODO lists. That is what
> > > is offered in the menu, that is what is advertised. Problem is that
> > > there is no warning for users that personal TODO lists are not meant
> > > for anything but that. There is no collaboration, putting TODO items
> > > eveywhere IS procrastination. Using org-agenda to find procrastination
> > > is another procrastination. Trying to glue everything together is
> > > absence of good planning and not planning.
> >
> > Carsten would disagree with that evaluation.  It is also for organising
> > professional life - with plain text.  Still, if you are disorganized,
> > you can use it.  Or perhaps if one is lazy - like myself, many things
> > I do nat have an interest in but have to oversee at least some parts of
> > them.
>
> Agree or not, it is written in the manual. The paradigm of organizing
> life does not inherit from Org. What inherits from Org is the paradigm
> to put any actionable items anywhere and compensate for scattered
> things by using org-agenda.
>
> Reference to manual:
> (info "(org) TODO Items")
>
> And it is definitely not a "plain text". It is probably largest mode
> for Emacs, a true and full application handling much more than plain
> text. It has more than 129 Emacs Lisp files. Maybe in beginning it was
> plain text, not any more now. Now it is a wannabe database.

In a way it is becoming the opposite of what Carsten was trying to do
in the beginning.  And plain text is always portable.

We should not exclude the original intention and use, making it fully
database.

> As I did notice the pattern of compensation for procrastination, and
> that I need more and more Emacs Lisp to fullfil basic human real world
> needs, then I rather made my own system that is meta level to Org
> files. Collaboration becomes possible due to the database being
> designed for multiple users. Privileges become possible for same
> reason. Automatic version control becomes possible database
> backed. Changes can be tracked back to know which user changed
> SCHEDULED to DEADLINE or DEADLINE to SCHEDULED or moved SCHEDULED
> forward in time or changed DEADLINE not to be DEADLINE any more. Who
> assigned which task to which person is easily viewable. People
> assigned need to be contacted, list of those people is there with
> hyperlinks and functions to send them email, SMS or call them. Org
> agenda need not compensate for anything. I can also put scattered
> tasks and note as I wish but I don't. My capture templates are over
> 1100+ subjects among which I probably use actively only 20-50, did not
> count it. Emacs Lisp handling that is currently 137 kilobytes. It did
> not yet reach 4.7 megabytes as Org distribution. I can convert
> everything to Org file when necessary.
>
> Even editing Org file by updating database is possible, but I do not
> wish to go back to complexities. My "headings" I call hyperdocuments
> which can be just anything. They can be packaged together or released
> together with the Org file summarizing them all. They can become Org
> file all together. It can be markdown, really plain text, video files,
> references of all kinds, also Org files, or just headings of
> it. Everything becomes elementary object of one bigger picture
> according to Engelbart:
>
> Doug Engelbart Institute - Boosting mankind's capability for coping with 
> complex, urgent problems
> https://www.dougengelbart.org/
>
> Draft OHS-Project Plan
> https://web.archive.org/web/20070704185333/http://www.bootstrap.org/augdocs/bi-2120.html
>
> TECHNOLOGY TEMPLATE PROJECT OHS Framework
> https://www.dougengelbart.org/content/view/110/460/
>
> Design of any software would be better by following the Open
> Hyperdocument System project plan.
>
> > I often include org commands in source code which I can then parse.
> > For instance, I can use it to determine the cyclomatic complexity of
> > code, and help in admin tasks.
>
> I have no idea what is cyclomatic. Code definitely get complex. Give
> some example how are you putting org commands in source code.
>
> On my side I also use GNU Hyperbole package. In Emacs lisp M-RET on a
> function brings me to function definition which is very handy. I can
> invoke email on region or buffer text. I can define buttons in any
> source code to jump anywhere else. It works in Org as well.
>
> Org hyperlinks can also work in any buffer including in source
> codes. I am not sure if that is wanted. Text is definitely not any
> more "plain text" as soon as it has Org hyperlink.
>
> GNU Hyperbole type of hyperlinks:
>
>  <(Look up word)>
>  <(Find people without assigned groups)>
>
> This is because these 

bug#45212: org-capture user-error: Abort

[daniela-spit]

> Sent: Sunday, December 13, 2020 at 11:48 AM
> From: "Jean Louis" 
> To: "Michael Albinus" 
> Cc: daniela-s...@gmx.it, bug-gnu-em...@gnu.org, "Org-Mode mailing list" 
> 
> Subject: Re: org-capture user-error: Abort
>
> * Michael Albinus  [2020-12-13 11:25]:
> > Jean Louis  writes:
> >
> > Hi Jean,
> >
> > > Even if it is error, why it should be written with the dash as
> > > "user-error"?!
> >
> > `user-error' is a standard error symbol in Emacs, which is fired by the
> > function `user-error'. See (info "(elisp) Signaling Errors")
>
> And error is by definition a wrong action attributable to bad judgment
> or ignorance or inattention.
>
> When user is offered choice:
>
> [q] Abort
>
> then such is not a wrong action or bad judgment or ignorance or
> inattention. Even the function description says it should be used in
> different set of circumstances.
>
> Org capture screen does not provide that circumstance that function
> should be used there as user's choice is not an error.

When I abort, it is completely intentional.  I use frequently for testing
new org-capture templates.

> Jean
>
>

bug#45212: org-capture user-error: Abort

[Christopher Dimech]

> Sent: Sunday, December 13, 2020 at 11:46 AM
> From: "Jean Louis" 
> To: "Ihor Radchenko" 
> Cc: daniela-s...@gmx.it, bug-gnu-em...@gnu.org, "Org-Mode mailing list" 
> 
> Subject: Re: org-capture user-error: Abort
>
> * Ihor Radchenko  [2020-12-13 11:21]:
> > Jean Louis  writes:
> > 
> > > * daniela-s...@gmx.it  [2020-12-12 23:19]:
> > >> Emacs fires "user-error: Abort" after pressing "q" to abort org-capture.
> > >
> > > Those are error messages invented by programmers who never had any
> > > project supervisor who thinks of users.
> > 
> > (user-error "Action aborted") only prints "Action aborted".
> 
> Function is used wrongly. People do read source code.
> 
> (user-error FORMAT  ARGS)
> 
>   Probably introduced at or before Emacs version 24.
> 
> Signal a user error, making a message by passing ARGS to ‘format-message’.
> This is like ‘error’ except that a user error (or "pilot error") comes
> from an incorrect manipulation by the user, not from an actual problem.
> In contrast with other errors, user errors normally do not cause
> entry to the debugger, even when ‘debug-on-error’ is non-nil.
> This can be overridden by ‘debug-ignored-errors’.
> 
> Did user incorrectly manipulated anything? I don't think so. 
> 
> There was definitely good intention to glue the things together and
> make things function. But it was not made from viewpoint that software
> will be used by people, maybe people read source code which is what we
> want. Under certain condition that will come up as actual error, see
> debug-ignored-errors.
> 
> Why tell to user that it was user error when it was not? It was one of
> options.

I agree absolutely.
 
> Focus on technicality that causes the problem which does not fit
> reasonably into human meanings. We like meanings, that is why we want
> to fit meanings where they belong. Systems are not enough meaningful.
> 
> I can love my bicycle as I want, but it may not be usable by other
> people due to all idiosyncratic enhancements I have made to it.
> 
> 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: Emacs inserts hardwired org-agenda-files variable, overwriting user options

[Jean Louis]

* Ihor Radchenko  [2020-12-13 12:25]:
> Jean Louis  writes:
> 
> > Org files I have always found useful for project and plan documents
> > preparation, in particular LaTeX and PDF export. As that way I get
> > better readability on screen and good printed document.
> >
> > None of such projects and plans need be marked with TODO as its nature
> > is that it is action plan, all items are actionable items. We print a
> > project and execute it. People report on project steps by email. 
> 
> I disagree. Or rather it depends on workflow:
> In the process of writing a plan or document there is sometimes an urge
> to fix small details instead of finishing the first draft and moving to
> more fine-grained edits afterwards. One way around this urge is quickly
> inserting an inline todo item and continuing to write (another way is
> writing on paper, but one would need to spend extra time re-typing the
> hand writing later).

Aha yes, in the context of finishing documents some items cannot be
completed and that is where TODO comes handy to know where to come
back to finish the document, while other items get completed in the
same time. But then again I never need an Org mode for that. I write
in LaTeX and plain TeX too, there are programs, so I always leave
there some tags in comments, usually also TODO. But is not Org mode
dependent.

Practically, if I write "TODO" on the heading then something is very
wrong with all heading. I write a tag ;; TODO in Lisp code when I need
to improve specific line of code to something else in future. Anybody
can invent any kind of tags or even just note line numbers at begin or
end of file. Should not be Org related in general.

If my text under heading is large I rather like to bookmark where to
come then to rely on TODO tag on the heading as it will not pinpoint
where exactly I have to continue.

> If the document text has inline todo items, it could be useful to mark
> the top-level headline todo as well, simply to remind about any ideas
> postponed during the writing. Such headline cannot be switched to done
> if org enforced todo dependencies.

Do you mean this:

** DONE Objective
   CLOSED: [2020-12-13 Sun 20:00]
*** TODO [#B] Step to do 1
*** TODO Step to do 2

when org-enforce-todo-dependencies is true I can still say DONE for
Objective above. I have mentioned it today already. Maybe it works on
your side, it does not work here. Do I do something wrong? I am on
development Emacs version and it does not enforce under emacs -Q

Project planning shall always start backwards from known objective to
be achieved. Subordinate tasks should become superfluous or redundant
as soon as objective have been achieved.

Scattered tasks without objective also have its objectives, they are
just not sorted well. Good organizing means to put it under right
objective and work by achieving objectives. City administrations do
like that. Military does like that. Boy scouts do like
that. Humanitarian organization.

> Todo keywords don't have to be included into exported version of the
> document.

Sure. Sometimes is necessary, sometimes not.

> >> Unless I am badly mistaken, I think this is only true when
> >> org-enforce-todo-dependencies is non-nil?
> >
> > Variable is nil on my side.
> >
> > - [-] Something
> >   - [ ] one
> >   - [ ] two
> >   - [X] three
> >
> > I cannot mark Something to be done without marking those subordinate
> > items. Changing org-enforce-todo-dependencies does not change
> > anything. User will need to lie to oneself to close those items to
> > become able to close senior item.
> 
> I believe it is hard-coded. One may send a feature request to have more
> control over this behaviour.

It looks like I am only one observing that. And especially me I do not
like depending on Org mode to dictate how to close items. So when
there is somebody else to join in the notion that is where feature is
appropriate. Otherwise I consider Org rather made and designed for
other way thinkers and doers, not for us who think from senior
objectives as priorities where subordinate items should become
redundant and not marked as "done".

My personal list of for a day has 7 items currently. Not 250. Those
are rather objectives, goals and purposes. Single items under
objectives are well known actions to be done and need not be marked as
TODO, but I can. My focus is on the meaning of what has to be done and
I do not need to look into tags or properties. Your informational
emails gave me to thinking so I have implemented it all.

> > If I do turn on the mentioned variable `org-enforce-todo-dependencies'
> > to TRUE, I can still close the senior objective here. This is good,
> > but variable does not do expected.
> 
> > ** DONE Senior objective
> >CLOSED: [2020-12-13 Sun 11:22]

> I cannot reproduce what you observe. Also, one can forcefully change
> todo state to done even when org-enforce-todo-dependencies is set to
> TRUE. To do it, C-u C-u C-u C-c C-t needs to be used instead of C-c C-t
> 

Re: Someone to oversee Org bugs as reported with M-x report-emacs-bugs?

[Jean Louis]

* Bastien  [2020-12-13 12:53]:
> Jean Louis  writes:
> 
> > * Bastien  [2020-12-11 09:28]:
> >> Thanks Jean, I agree with most of your points.
> >> 
> >> Are you volunteering for this task?
> >
> > I am anyway answering to people. So I am already doing it.
> 
> Thanks but we need someone that is willing to personnally take
> charge of this.

Explain the workflow and gather few of us as fallbacks.

> > Normally GNU mailing lists are not subscriber based.
> 
> I don't know about other GNU mailing lists but I'm not under the
> impression that GNU mailing lists are "normally" not subscriber based.

I just know Org mode mailing list that requires subscription. To all
other lists I ever wrote no subscription was required. In other words,
user may subscribe but to write to mailing list no subscription is
required. I guess there are others like Org, but I do not know about
them.

Re: org-mode Publishing fails xhtml validation and LibreJS test.

[Jean Louis]

* Tim Cross  [2020-12-13 04:09]:
> Given the move to HTML5 and deprecation of XHTML, how valid are
> XHTML compliance requirements these days? Could it be time to
> 'reverse' the org defaults and export using HTML5 by default rather
> than XHTML?

There is no deprecation of XHTML, not until there comes XHTML5. And
XHTML will remain for good number of years. It serves slightly
different purpose and is more suitable for Org exports due to its
rigid structure.

XHTML must all the time be valid. Org export function should, when
possible, or by user configured, include the validator check.

It would not be good to switch to HTML5 because software does not
produce XHTML well. It is better finding those bugs.

> Would it be sufficient to just have the license information embedded
> as a simple comment?

Here are ways to make it compatible with LibreJS:
https://www.gnu.org/software/librejs/free-your-javascript.html

Jean

Re: from dired to an org file with list of files with links

[Jean Louis]

* TRS-80  [2020-12-11 19:21]:
> On 2020-12-11 03:09, Uwe Brauer wrote:
> > > Dear Uwe,
> > > * Uwe Brauer  [2020-12-10 22:45]:
> > 
> > > (require 'dired-x)
> > 
> > > (defun dired-to-org-links ()
> > >   "Generates Org links for Dired files and stores in memory. Yank
> > > it in other buffer"
> > >   (interactive)
> > >   (let* ((files (dired-get-marked-files)))
> > > (when files
> > >   (kill-new
> > >(with-temp-buffer
> > >(dolist (file files)
> > >  (let* ((base (file-name-nondirectory file))
> > > (link (format "[[file:%s][%s]]\n" file base)))
> > >(insert link)))
> > >(buffer-string))
> > 
> > Thanks, that is very nice.
> > I played a bit around with org-fstree, that is also useful.
> 
> Indeed, nice function!
> 
> And what great and fast service!  :)
> 
> If I may be permitted to pick a nit; Uwe, you may want to prefix the
> function with `my-` or `uwe-` or your initials, etc. for namespace
> reasons.  Unless of course this is something Jean Louis is planning on
> submitting as a patch to dired itself... ;)

It is more Org related. In my opinion all built-in Org hyperlink types
should be already integrated in Org, probably also this is integrated.

The org-store-link actually works in Dired.

The org-insert-last-link works to put link into buffer

So it is just iteration missing.

Re: Bring up a screen giving option to open a series of orgmode files

[Jean Louis]

* Ihor Radchenko  [2020-12-13 03:45]:
> Jean Louis  writes:
> 
> > While it is easy to teach people to open single program, press a key,
> > and insert title, it is harder and time consuming to teach random
> > people how to use Emacs. This may not be true, it is just my current
> > impression. 
> 
> I guess one would not need to teach people about everything in Emacs. If
> the aim is just editing and viewing PDF, one can provide custom Emacs
> configuration with added toolbars and menu items for common operations
> with pdf. I do not see why it would be any different from specialised
> pdf viewers. 

To see that assign Emacs tutorial to several people and observe
results. I do.

Re: Org Capture Menu cannot be fully viewed

[Jean Louis]

* TRS-80  [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: Emacs inserts hardwired org-agenda-files variable, overwriting user options

[Jean Louis]

* daniela-s...@gmx.it  [2020-12-13 08:52]:
> > In general Org mode is excellent for personal TODO lists. That is what
> > is offered in the menu, that is what is advertised. Problem is that
> > there is no warning for users that personal TODO lists are not meant
> > for anything but that. There is no collaboration, putting TODO items
> > eveywhere IS procrastination. Using org-agenda to find procrastination
> > is another procrastination. Trying to glue everything together is
> > absence of good planning and not planning.
> 
> Carsten would disagree with that evaluation.  It is also for organising
> professional life - with plain text.  Still, if you are disorganized,
> you can use it.  Or perhaps if one is lazy - like myself, many things
> I do nat have an interest in but have to oversee at least some parts of
> them.

Agree or not, it is written in the manual. The paradigm of organizing
life does not inherit from Org. What inherits from Org is the paradigm
to put any actionable items anywhere and compensate for scattered
things by using org-agenda.

Reference to manual:
(info "(org) TODO Items")

And it is definitely not a "plain text". It is probably largest mode
for Emacs, a true and full application handling much more than plain
text. It has more than 129 Emacs Lisp files. Maybe in beginning it was
plain text, not any more now. Now it is a wannabe database.

As I did notice the pattern of compensation for procrastination, and
that I need more and more Emacs Lisp to fullfil basic human real world
needs, then I rather made my own system that is meta level to Org
files. Collaboration becomes possible due to the database being
designed for multiple users. Privileges become possible for same
reason. Automatic version control becomes possible database
backed. Changes can be tracked back to know which user changed
SCHEDULED to DEADLINE or DEADLINE to SCHEDULED or moved SCHEDULED
forward in time or changed DEADLINE not to be DEADLINE any more. Who
assigned which task to which person is easily viewable. People
assigned need to be contacted, list of those people is there with
hyperlinks and functions to send them email, SMS or call them. Org
agenda need not compensate for anything. I can also put scattered
tasks and note as I wish but I don't. My capture templates are over
1100+ subjects among which I probably use actively only 20-50, did not
count it. Emacs Lisp handling that is currently 137 kilobytes. It did
not yet reach 4.7 megabytes as Org distribution. I can convert
everything to Org file when necessary.

Even editing Org file by updating database is possible, but I do not
wish to go back to complexities. My "headings" I call hyperdocuments
which can be just anything. They can be packaged together or released
together with the Org file summarizing them all. They can become Org
file all together. It can be markdown, really plain text, video files,
references of all kinds, also Org files, or just headings of
it. Everything becomes elementary object of one bigger picture
according to Engelbart:

Doug Engelbart Institute - Boosting mankind's capability for coping with 
complex, urgent problems
https://www.dougengelbart.org/

Draft OHS-Project Plan
https://web.archive.org/web/20070704185333/http://www.bootstrap.org/augdocs/bi-2120.html

TECHNOLOGY TEMPLATE PROJECT OHS Framework 
https://www.dougengelbart.org/content/view/110/460/

Design of any software would be better by following the Open
Hyperdocument System project plan.

> I often include org commands in source code which I can then parse.
> For instance, I can use it to determine the cyclomatic complexity of
> code, and help in admin tasks.

I have no idea what is cyclomatic. Code definitely get complex. Give
some example how are you putting org commands in source code.

On my side I also use GNU Hyperbole package. In Emacs lisp M-RET on a
function brings me to function definition which is very handy. I can
invoke email on region or buffer text. I can define buttons in any
source code to jump anywhere else. It works in Org as well.

Org hyperlinks can also work in any buffer including in source
codes. I am not sure if that is wanted. Text is definitely not any
more "plain text" as soon as it has Org hyperlink.

GNU Hyperbole type of hyperlinks:

 <(Look up word)>
 <(Find people without assigned groups)>

This is because these hyperlinks are in a separate directory file and
thus separate from the text file where they are located.

Org hyperlinks need to be included in the text and would look like
this:

[[elisp:(look-up-word)][Look up word]]

I do tend to have separate hyperlink meta data from the hyperlink
itself. I would prefer something more generic like

 look up word [3:I49] to expand to hyperlink 3 words backwords or
 [I49:3] 3 words forward when parsing and displaying such a file. Or
 simply [I49] to become hyperlink itself to the node 49.

 If node 49 is WWW hyperlink, let user go there. If it is note, show
 him the note, if it is something 

Re: Bring up a screen giving option to open a series of orgmode files

[Jean Louis]

* Ihor Radchenko  [2020-12-13 03:39]:
> Jean Louis  writes:
> 
> > For private annotations with hypothes.is one can install it on own
> > server and protect system for one's own group. That will do only a
> > group that is serious enough or have serious demands for annotations.
> 
> > Myself I do not prefer having too much software installed online
> > especially not databases that are private. What is private I keep off
> > the Internet. If I wish to communicate over Internet to somebody I
> > always establish first encrypted line.
> 
> I have hypothes.is installed inside docker container locally. No serious
> protection is required in such case (at least, no more than one would
> use to protect private files from dangerous software like browsers).

I can install it on VPS which is definitely in plan. Locally I do not
think so, as locally I have dynamic knowledge repository that may
export to Org if necessary or accessed by collaborative group of
people. 

> Public annotations would better be just exported to a public server
> (automatically or not).

When they are public yes. I have it rather private.

> > example.com/1/2/3/4 for ID 1234
> >
> > That would be HTML with PDF annotation where user could open PDF
> > inside of that HTML or click on the PDF to open it. I do hope that
> > pdfjs does support specific page jumps. And such annotation on HTML
> > should work with or without Javascript. Those without can simply open
> > PDF file and manually jump to specific page as annotated and
> > instructed.
> 
> I am not sure how it is different from using hypothes.is for the same
> purpose. Note that hypothes.is uses pdf fingerprinting, so you don't
> even need to store pdf on server side. If user can open the pdf
> (obtained from you directly, for example), hypothes.is will
> automatically show the up-to-date annotations shared via public
> hypothes.is instance for that particular user.

The difference is that annotation is separate from file, and there is
no need for Javascript. Hyperdocument may contain the PDF file and the
annotation together, dispatched to somebody, or referenced from WWW
page. It is lightweight. HTML file can be very small and speedy
loaded. 

> > Then I would inject web server password protection and protect it from
> > public. But that does not protect the document of those who could
> > intrude into the server and also does not protect from cracking
> > attempts as username and password are not alone well secure. Better
> > would be having the encrypted HTML that is protected by user's private
> > PGP key, but I have no idea if such technology exists yet.
> 
> hypothes.is uses OAuth mechanism with fine-grained control over the
> access to various annotations. Also, one can run it inside encrypted
> docker container (or even inside virtual machine) reducing the risk if
> server is compromised.

That is great yet introduces 2 different tools for one purpose. While
I support Hypothesi.is in general and will be using its hyperlinks for
some public purposes, those private purposes will remain off line and
I need not have any extra software to have my group of people learning
from annotated PDFs. They would be in local area network or VPN in
collaborative environment backed by database where they can open and
read PDFs without browser, Emacs is enough to browse it or exported to
some other format I can make it as well HTML or provide hyperlinks as
I wish, including to open it with the PDF in a built-in browser.  Each
software for its purpose. I recommended hypothesi.is but I already
have similar system built on same principles of Engelbart just as
Hypothes.is

Jean

Re: Org Capture Menu cannot be fully viewed

[Jean Louis]

* 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 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: Emacs as an Org LSP server

[TEC]

Jean Louis  writes:

> * TEC  [2020-12-13 13:44]:
>> 
>> A little progress update.
>> 
>> https://github.com/tecosaur/org-lsp now exists.
>
> As Org-mode does not have collaboration neither was initially designed
> for other editor, such idea is welcome.
>
> From a perspective that some server has to know what user is writing
> it is advisable to use one own's servers. But if idea gets popular
> some company will commercialize it and centralize user's data and
> privacy is gone.

FYI the nature of LSP (as I understand it) is that the "server" is a
locally running service that responds to signals from a "client" (code
editor / IDE).

Hope that clears things up,

Timothy

Re: org-capture user-error: Abort

[Jean Louis]

* Michael Albinus  [2020-12-13 11:25]:
> Jean Louis  writes:
> 
> Hi Jean,
> 
> > Even if it is error, why it should be written with the dash as
> > "user-error"?!
> 
> `user-error' is a standard error symbol in Emacs, which is fired by the
> function `user-error'. See (info "(elisp) Signaling Errors")

And error is by definition a wrong action attributable to bad judgment
or ignorance or inattention.

When user is offered choice:

[q] Abort

then such is not a wrong action or bad judgment or ignorance or
inattention. Even the function description says it should be used in
different set of circumstances.

Org capture screen does not provide that circumstance that function
should be used there as user's choice is not an error.

Jean

Re: Org Capture Menu cannot be fully viewed

[Jean Louis]

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

> 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: Emacs as an Org LSP server

[Jean Louis]

* TEC  [2020-12-13 13:44]:
> 
> A little progress update.
> 
> https://github.com/tecosaur/org-lsp now exists.

As Org-mode does not have collaboration neither was initially designed
for other editor, such idea is welcome.

>From a perspective that some server has to know what user is writing
it is advisable to use one own's servers. But if idea gets popular
some company will commercialize it and centralize user's data and
privacy is gone.

Re: org-capture user-error: Abort

[Jean Louis]

* Ihor Radchenko  [2020-12-13 11:21]:
> Jean Louis  writes:
> 
> > * daniela-s...@gmx.it  [2020-12-12 23:19]:
> >> Emacs fires "user-error: Abort" after pressing "q" to abort org-capture.
> >
> > Those are error messages invented by programmers who never had any
> > project supervisor who thinks of users.
> 
> (user-error "Action aborted") only prints "Action aborted".

Function is used wrongly. People do read source code.

(user-error FORMAT  ARGS)

  Probably introduced at or before Emacs version 24.

Signal a user error, making a message by passing ARGS to ‘format-message’.
This is like ‘error’ except that a user error (or "pilot error") comes
from an incorrect manipulation by the user, not from an actual problem.
In contrast with other errors, user errors normally do not cause
entry to the debugger, even when ‘debug-on-error’ is non-nil.
This can be overridden by ‘debug-ignored-errors’.

Did user incorrectly manipulated anything? I don't think so. 

There was definitely good intention to glue the things together and
make things function. But it was not made from viewpoint that software
will be used by people, maybe people read source code which is what we
want. Under certain condition that will come up as actual error, see
debug-ignored-errors.

Why tell to user that it was user error when it was not? It was one of
options.

Focus on technicality that causes the problem which does not fit
reasonably into human meanings. We like meanings, that is why we want
to fit meanings where they belong. Systems are not enough meaningful.

I can love my bicycle as I want, but it may not be usable by other
people due to all idiosyncratic enhancements I have made to it.

Jean

Re: Org Capture Menu cannot be fully viewed

[Jean Louis]

* pie...@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  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

[Jean Louis]

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

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 

Re: #+include and org-export-before-processing-hook

[Juan Manuel Macías]

Hello,

Eric S Fraga  writes:

> Hello,
>
> I have a particular function that I want to invoke when exporting an org
> file.  This works just fine, adding this function to the
> org-export-before-processing-hook, for simple org files.  However, if I
> have an org file which uses #+include: to include other org files, it
> seems like the processing doesn't happen on included files.

I have the same problem with a function that I wrote to not export
certain footnotes, and to date I have not been able to fix it. According
to the `org-export-before-processing-hook' docstring:

" *This is run before include keywords and macros are expanded*
and Babel code blocks executed, on a copy of the original buffer
being exported.  Visibility and narrowing are preserved.  Point
is at the beginning of the buffer.

Regards,

Juan Manuel 

Re: Bug: Orgmode export takes "AC:" as a link keyword [9.5 (nil @ /Users/junwei/.emacs.d/.local/straight/build-27.1/org-mode/)]

[Junwei Wang]

Thank you very much for your quick reply.


How can I let orgmode disable some built-in links if it allows? (The 
escape character solution sounds not ideal.)


On 13/12/2020 07:05, Kyle Meyer wrote:

Junwei Wang writes:


When exporting orgmode file into HTML file, the exporter "mistakely"
consider "AC:" as some keyword for linking and the string following
"AC:" would be something link to.

It looks like org-ref is setting up these links for you. Here's the
relevant bit from the configuration you included:

org-link-parameters '([...]
("Ac" :follow or-follow-acronym :face org-ref-acronym-face :help-echo
or-acronym-tooltip :export
#[771 "\211\301>\203\302\303\300A#\207\302\304\226\"\207"
[("Ac" . "Gls") (latex beamer) format "\\%s{%s}" "%s"] 7
"\n\n(fn PATH _ FORMAT)"]
)
("ac" :follow or-follow-acronym :face org-ref-acronym-face :help-echo
or-acronym-tooltip :export
#[771 "\211\301>\203\302\303\300A#\207\302\304\226\"\207"
[("ac" . "gls") (latex beamer) format "\\%s{%s}" "%s"] 7
"\n\n(fn PATH _ FORMAT)"]
[...]

I suspect the uppercase "AC" being treated as a link despite it not
appearing in org-link-parameters is a case-related bug somewhere in
Org's link handling.  While that's worth looking into, it just shifts
things as far as your original example is concerned: replace "AC" with
"ac", and you have the same issue that you reported.

One way to make Org not treat "ac:foo" as a link is to insert a
zero-width space (with, e.g., ) between "ac" and ":".

   (info "(org)Escape Character")

Re: org-table change time from UTC to other timezones

[Maxim Nikulin]

2020-12-13 Alan E. Davis wrote:


I think R would not be too unwieldy as a hammer here.  My use case  is a 
humble one: just take a several clock times in HH:MM format (utc) and 
adjust to  another timezone by adding or subtracting the relevant number 
of hours.  The day of week is not important; i will have to deal with 
it.  I did imagine a conditional subtraction by adding of subtracting 
24:00 as needed.


Likely your approach is suitable for you and you could ignore my 
comments. I just live in a city having longitude that should be (and it 
was) the border between time zones, so majority do not like any 
decision. Since cancellation of DST 10 years ago, local time has been 
shifted 2 times...


To get time offset for some timezone, it is necessary to specify 
timestamp, so a date is required in addition to time. Namely day of week 
is mostly irrelevant.


Time transitions are usually arranged at night when most of people are 
not active. Astronomers is a different case, that is why their chance to 
face a timezone bug is higher.


When operations with arbitrary time zones are not required and a process 
could be run with TZ variable set to desired time zone, libc functions 
should work correctly. I have not tried elisp functions 
https://www.gnu.org/software/emacs/manual/html_node/elisp/Time-Zone-Rules.html


A bookmark for those who still hopes to avoid complications with 
time-related operations


Falsehoods programmers believe about time
https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time

#+include and org-export-before-processing-hook

[Eric S Fraga]

Hello,

I have a particular function that I want to invoke when exporting an org
file.  This works just fine, adding this function to the
org-export-before-processing-hook, for simple org files.  However, if I
have an org file which uses #+include: to include other org files, it
seems like the processing doesn't happen on included files.

How can I get the function in the hook to process included files?  In
other words, I wish to process the complete org file that results from
incorporating the include files.

I have tried both
#+include: included.org
and
#+include: included.org src org
and neither works.

Thank you,
eric

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-160-g7c8dce

Re: Adding Org Files to org-agenda-files

[steve-humphreys]

> Sent: Sunday, December 13, 2020 at 4:36 PM
> From: "Ihor Radchenko" 
> To: "Jean Louis" 
> Cc: "Tim Cross" , daniela-s...@gmx.it, 
> emacs-orgmode@gnu.org
> Subject: Re: Adding Org Files to org-agenda-files
>
> 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.
>
> Jean Louis  writes:
>
> > * Ihor Radchenko  [2020-12-01 05:21]:
> >> Jean Louis  writes:
> >
> > Just as you got a hunch, random incidents happen all the time on
> > ground. There is set of policies and staff members get trained to
> > apply them. For example our coordination policy is to pretty much
> > coordinate any reasonable action before, during and after
> > execution. If staff member is departing to village such will send a
> > message and we know what is the action of a staff member. If
> > supervisor is on computer such action can be entered in same central
> > file. Otherwise email list of staff member holds track of actions.
> >
> > In that sense we help each other.
>
> Thanks for providing an example. I do agree that the management model
> you are using for your job fits into defining projects rather strictly
> and delegating the planning/non-trivial decision making to competent
> people. In such a context, ordered project plans with a single action at
> a time and each employee assigned to a single project do make a lot of
> sense. However, different perspectives do exist.
>
> My personal experience is doing a lot of research work. That's probably
> on the other side of the spectrum from the environment you are working
> in. I cannot define very concrete steps to execute a research project.
> Not because it is impossible, but rather because failures are pretty
> much guaranteed far before all the steps are executed. Moreover, most of
> time, it is not possible to consult someone else on resolution of the
> problem causing blockage, simply because the problem is something that
> never ever appeared in the past (that's the whole point of doing
> research). Instead, I need to spend a significant time trying to find
> *similar* problems digging through literature, talking to people working
> on related problems, or even just thinking. Then, waiting until the
> solution appears becomes a waste of time (there is even no guarantee
> that solution exists) - if there are other alternative approaches to
> achieve the global project objective, they would better be tried before
> the blockage in one particular direction in solved. In fact, switching
> to alternative approaches (or even projects) sometimes help to look at
> the problem from different angle and solve it. The described difficulty
> is *underestimation* of what can happen - even the initial project
> objectives can be changed according to the current research results.
> Trying to stick to a strict project structure in such a situation is a
> waste of time - project must be re-created from scratch very too often,
> unless it is more flexible from the very beginning.
>
> In fact, the situation does not apply to a single project. The whole
> project can be stuck and it is often helpful to have multiple projects
> that can be done (though it is necessary to stick to highest-priority
> project when possible).
>
> The described situation is where NEXT tasks/projects can become
> extremely helpful. Multiple NEXT tasks do not mean that I need to look
> at them every day and switch from one to another. There are NEXT tasks
> and there are NEXT tasks that are actually scheduled on specific day.
> One day cannot have more than several (ideally one) NEXT task (possibly
> containing a checklist). That's where agenda comes handy. It is not used
> to decide what to do during that day. It merely shows earlier decision
> when planning which project (and corresponding doable NEXT task) to do
> on specific day. Other items in agenda are things that must be done on
> that day anyway (meetings, mandatory habits, etc). Polluting agenda with
> unnecessary staff is no better than mindless browsing of youtube.
>
> > After this discussion and review of how SMOS implemented NEXT and how
> > some people implement NEXT while doing their planning with Org mode,
> > I see that it will never be necessary on my side. Just never.
> >
> > This is for reason that we use set of policies beforehand and train
> > people how to do projects. Number one is that person cannot start
> > doing any action without fully understanding all parts of the full
> > project. We expect person to be literate and capable at least in the
> > context of the project being executed. We push the purpose of the
> > project and reason, not the execution of single tasks. As purpose of
> > tasks are to achieve the purpose, person executing those tasks is
> > supposed to collaborate on the project and contribute to it. Executing
> > tasks 

Re: [PATCH] Enhance org-html--build-meta-info

[TEC]

Jens Lechtenboerger  writes:

> Without the second argument I get an error “Wrong type argument:
> stringp,” when evaluating regular expressions against the cons cell
> that is returned as title.
>
> As I see now, author and title are cons cells, which is why
> org-element-interpret-data is necessary to produce strings with Org
> syntax.
>
> Also, after fixing the title, I get “wrong-type-argument sequencep
> utf-8” for “(concat "text/html;charset=" charset)”.

Thanks for testing this :) I haven't forgotten about this.

Next version!

>From 1289e381aff7562df96945aa58838ad966aa9211 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Thu, 17 Sep 2020 21:27:18 +0800
Subject: [PATCH] lisp/ox-html.el: make html meta func nicer

* lisp/ox-html.el (org-html--build-meta-info): Multi-line repeated
structure extracted to new function `org-html--build-meta-entry'.
The opportunity was taken to extract most metadata info to custom
variable `org-html-meta-tags', allowing for easy end-user modification.
---
 lisp/ox-html.el | 131 +++-
 1 file changed, 73 insertions(+), 58 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index d2f24f5c6..93014e9c7 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -1425,6 +1425,31 @@ not be modified."
 
  Template :: Styles
 
+(defcustom org-html-meta-tags
+  '((lambda (_title author _info)
+  (when (org-string-nw-p author)
+	(list "name" "author" author)))
+(lambda (_title _author info)
+  (when (org-string-nw-p (plist-get info :description))
+	(list "name" "description"
+	  (plist-get info :description
+(lambda (_title _author info)
+  (when (org-string-nw-p (plist-get info :keywords))
+	(list "keywords" (plist-get info :keywords
+("name" "generator" "Org Mode"))
+  "A list of arguments to be passed to `org-html--build-meta-entry'.
+Each argument can either be an list which is applied, or a function which
+generates such a list with signature (TITLE AUTHOR INFO) where TITLE and AUTHOR
+are strings, and INFO a communication plist."
+  :group 'org-export-html
+  :package-version '(Org . "9.5")
+  :type '(repeat
+	  (choice
+	   (list (string :tag "Meta label")
+		 (string :tag "label value")
+		 (string :tag "Content value"))
+	   function)))
+
 (defcustom org-html-head-include-default-style t
   "Non-nil means include the default style in exported HTML files.
 The actual style is defined in `org-html-style-default' and
@@ -1835,78 +1860,68 @@ INFO is a plist used as a communication channel."
 
 ;;; Template
 
+(defun org-html--build-meta-entry (label identity  content-format  content-formatters)
+  "Construct  tag with LABEL=\"IDENTITY\" and content from CONTENT-FORMAT and CONTENT-FORMATTER."
+  (concat "\n"))
+
 (defun org-html--build-meta-info (info)
   "Return meta tags for exported document.
 INFO is a plist used as a communication channel."
-  (let* ((protect-string
-  (lambda (str)
-(replace-regexp-in-string
- "\"" "" (org-html-encode-plain-text str
- (title (org-export-data (plist-get info :title) info))
- ;; Set title to an invisible character instead of leaving it
- ;; empty, which is invalid.
- (title (if (org-string-nw-p title) title ""))
- (author (and (plist-get info :with-author)
-  (let ((auth (plist-get info :author)))
+  (let* ((title (org-html-encode-plain-text (or (car (plist-get info :title)) "Org Export")))
+	 ;; Set title to an invisible character instead of leaving it
+	 ;; empty, which is invalid.
+	 (title (if (org-string-nw-p title) title ""))
+	 (author (and (plist-get info :with-author)
+		  (let ((auth (plist-get info :author)))
 			;; Return raw Org syntax.
-(and auth (org-element-interpret-data auth)
- (description (plist-get info :description))
- (keywords (plist-get info :keywords))
- (charset (or (and org-html-coding-system
-   (fboundp 'coding-system-get)
-   (coding-system-get org-html-coding-system
-  'mime-charset))
-  "iso-8859-1")))
+			(and auth (org-element-interpret-data auth)
+	 (charset (or (and org-html-coding-system
+			   (fboundp 'coding-system-get)
+			   (symbol-name
+			(coding-system-get org-html-coding-system
+	   'mime-charset)))
+		  "iso-8859-1")))
 (concat
  (when (plist-get info :time-stamp-file)
(format-time-string
 	(concat "\n")))
- (format
-  (if (org-html-html5-p info)
-	  (org-html-close-tag "meta" "charset=\"%s\"" info)
-	(org-html-close-tag
-	 "meta" "http-equiv=\"Content-Type\" content=\"text/html;charset=%s\""
-	 info))
-  charset) "\n"
+
+ (if (org-html-html5-p info)
+	 (org-html--build-meta-entry "charset" charset)
+   (org-html--build-meta-entry "http-equiv" "Content-Type"
+   (concat "text/html;charset=" 

Re: org-plot line colors

[TEC]

Hi Ian,

Sorry for the slow response, I'm marked your email though, so I'm now
getting back to you :)

ian martins  writes:

> I wanted to change line colors but didn't find a way. Is there a way?

Indeed! Though I do it with lisp, and using my patches.

I think I saw a patch about multiline #+plot / set but I forget (ment
to send an email about that actually...).

In case it helps, here's the sort of thing I have:

#+begin_src emacs-lisp
(defun org-plot/generate-theme (_type)
  "Use the current Doom theme colours to generate a GnuPlot preamble."
  (format "[...]
set linetype 1 lw 2 lc rgb '%s' # red
set linetype 2 lw 2 lc rgb '%s' # blue
[...]")
  (doom-color 'red)
  (doom-color 'blue))
(setq org-plot/gnuplot-script-preamble #'org-plot/generate-theme)
#+end_src

org-plot/gnuplot-script-preamble can be either a function, or a plain
string.

Regarding the "with lines" bit, I'm not exactly sure what's required to
be changed without looking over my patches again  but I know I added
the capability to adapt the existing plot types quite easily.

If a particular modification seems like a good idea, do feel free to
share .

Hope that helps a bit,

Timothy.

Sv: New startup options, showlevels

[Gustav Wikström]

Hi,

I believe we still can change the name if that’s preferred. I'm not overly 
attached to the name I committed, although I fail to see the ugliness in it. 
And it's only in master since a few days. No biggie to change.

In my opinion it's important to see the names in their context. One context is 
the other available startup options.

Principles I tried to follow when choosing the names (Alt 0 below):
1) Keep the name as close to the intent as possible. It should be possible to 
understand it based on name alone, if possible. (I.e. avoid ambiguity)
2) Let the pattern for the name match with the pattern already existing for 
names in its surrounding context.
3) Keep it short, but prefer principle 1 and 2 to short.

The following options have been presented, where the first one is already in 
master:

Already in master (Alt 0): 
 `overview'Top-level headlines only.  
 `content' All headlines. 
 `show2levels' Headline levels 1-2.   
 `show3levels' Headline levels 1-3.   
 `show4levels' Headline levels 1-4.   
 `show5levels' Headline levels 1-5.   
 `showall' No folding on any entry.   
 `showeverything'  Show even drawer contents. 

Alt 1:
 `overview'Top-level headlines only.  
 `content' All headlines. 
 `show:2'  Headline levels 1-2.   
 `show:3'  Headline levels 1-3.   
 `show:4'  Headline levels 1-4.   
 `show:5'  Headline levels 1-5.   
 `showall' No folding on any entry.   
 `showeverything'  Show even drawer contents. 

Alt 2:
 `overview'Top-level headlines only.  
 `content' All headlines. 
 `levels:2'Headline levels 1-2.   
 `levels:3'Headline levels 1-3.   
 `levels:4'Headline levels 1-4.   
 `levels:5'Headline levels 1-5.   
 `showall' No folding on any entry.   
 `showeverything'  Show even drawer contents. 

Alt 3:
 `overview'Top-level headlines only.  
 `content' All headlines. 
 `content:2'   Headline levels 1-2.   
 `content:3'   Headline levels 1-3.   
 `content:4'   Headline levels 1-4.   
 `content:5'   Headline levels 1-5.   
 `showall' No folding on any entry.   
 `showeverything'  Show even drawer contents.

To me no option is perfect. There are incongruencies for all. Maybe a fourth 
option?

Alt 4:
`overview'Top-level headlines only.  
 `content' All headlines. 
 `2levels' Headline levels 1-2.   
 `3levels' Headline levels 1-3.   
 `4levels' Headline levels 1-4.   
 `5levels' Headline levels 1-5.   
 `showall' No folding on any entry.   
 `showeverything'  Show even drawer contents.

Since show in showall and showeverything seems to symbolize the unfolding of 
things.

That would be an improvement based on all three principles above, in that it 
removes the ambiguity of "show" (and how it relates to unfolding), makes the 
names shorter, and stays in line with the naming convention (i.e. no ':'). Not 
sure what the syntax says about names starting with numerals though.

Your call. Personally I'd prefer Alt 4 or the existing one.

/Gustav

> -Ursprungligt meddelande-
> Från: Eric S Fraga 
> Skickat: den 13 december 2020 10:49
> Till: Bastien 
> Kopia: Gustav Wikström ; emacs-orgmode@gnu.org
> Ämne: Re: New startup options, showlevels
> 
> On Saturday, 12 Dec 2020 at 18:54, Bastien wrote:
> > In this case, I think we could come up with better option names than
> > "show2levels", even if I don't have a better suggestion right now.
> 
> I agree.  I had started responding to Gustav when the original post
> appeared but then aborted my response.  I wonder whether something like
> levels:N or show:N or content:N is possible in a startup setting, akin
> to H:N in options?
> 
> I do have (org-content N) often in my file local variables in any case.
> --
> : Eric S Fraga via Emacs 28.0.50, Org release_9.4-160-g7c8dce

Re: Sv: New startup options, showlevels

[TEC]

Just a quick note on the values proposed.

All of the Alt Ns have overview + N-in-the-name options for N >= 2.
e.g. show2levels, show3levels...

For the sake of completeness/consistency I would suggest having a N=1
variant with that format too. This would duplicate the behaviour of
"overview", but if say I currently have "levels:2" and I want to bump it
down to 1, then I'd naturally go to "levels:1" and expect it to work.

--
Timothy.

Gustav Wikström  writes:

> Already in master (Alt 0): 
>  `overview'Top-level headlines only.  
>  `content' All headlines. 
>  `show2levels' Headline levels 1-2.   
>  `show3levels' Headline levels 1-3.   
>  `show4levels' Headline levels 1-4.   
>  `show5levels' Headline levels 1-5.   
>  `showall' No folding on any entry.   
>  `showeverything'  Show even drawer contents. 
>
> Alt 1:
>  `overview'Top-level headlines only.  
>  `content' All headlines. 
>  `show:2'  Headline levels 1-2.   
>  `show:3'  Headline levels 1-3.   
>  `show:4'  Headline levels 1-4.   
>  `show:5'  Headline levels 1-5.   
>  `showall' No folding on any entry.   
>  `showeverything'  Show even drawer contents. 
>
> Alt 2:
>  `overview'Top-level headlines only.  
>  `content' All headlines. 
>  `levels:2'Headline levels 1-2.   
>  `levels:3'Headline levels 1-3.   
>  `levels:4'Headline levels 1-4.   
>  `levels:5'Headline levels 1-5.   
>  `showall' No folding on any entry.   
>  `showeverything'  Show even drawer contents. 
>
> Alt 3:
>  `overview'Top-level headlines only.  
>  `content' All headlines. 
>  `content:2'   Headline levels 1-2.   
>  `content:3'   Headline levels 1-3.   
>  `content:4'   Headline levels 1-4.   
>  `content:5'   Headline levels 1-5.   
>  `showall' No folding on any entry.   
>  `showeverything'  Show even drawer contents.
>
> To me no option is perfect. There are incongruencies for all. Maybe a fourth 
> option?
>
> Alt 4:
> `overview'Top-level headlines only.  
>  `content' All headlines. 
>  `2levels' Headline levels 1-2.   
>  `3levels' Headline levels 1-3.   
>  `4levels' Headline levels 1-4.   
>  `5levels' Headline levels 1-5.   
>  `showall' No folding on any entry.   
>  `showeverything'  Show even drawer contents.
>
> Since show in showall and showeverything seems to symbolize the unfolding of 
> things.
>
> That would be an improvement based on all three principles above, in that it 
> removes the ambiguity of "show" (and how it relates to unfolding), makes the 
> names shorter, and stays in line with the naming convention (i.e. no ':'). 
> Not sure what the syntax says about names starting with numerals though.
>
> Your call. Personally I'd prefer Alt 4 or the existing one.
>
> /Gustav
>
>> -Ursprungligt meddelande-
>> Från: Eric S Fraga 
>> Skickat: den 13 december 2020 10:49
>> Till: Bastien 
>> Kopia: Gustav Wikström ; emacs-orgmode@gnu.org
>> Ämne: Re: New startup options, showlevels
>> 
>> On Saturday, 12 Dec 2020 at 18:54, Bastien wrote:
>> > In this case, I think we could come up with better option names than
>> > "show2levels", even if I don't have a better suggestion right now.
>> 
>> I agree.  I had started responding to Gustav when the original post
>> appeared but then aborted my response.  I wonder whether something like
>> levels:N or show:N or content:N is possible in a startup setting, akin
>> to H:N in options?
>> 
>> I do have (org-content N) often in my file local variables in any case.
>> --
>> : Eric S Fraga via Emacs 28.0.50, Org release_9.4-160-g7c8dce