Fwd: Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

 Start of forwarded message 
From: Ihor Radchenko 
To: No Wayman 
Subject: Re: [BUG] [BUG] inconsistent behavior when reading multiple tags
 [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]
Date: Sun, 20 Mar 2022 18:26:52 +0800

This patch is not listed in updates.orgmode.org
Marking it (hopefully)

Best,
Ihor
 End of forwarded message 

Re: citations: org-cite vs org-ref 3.0

[Vikas Rawal]

Dear John,

Thanks very much for taking time to write a detailed reply.

I do not think it is productive for the community to say or consider it
> is a sad situation.


>From the perspective of a user, this was only meant to express a sentiment
that one finds oneself in a situation of having to choose between two good
things, and that we have not been able to find a way to make both
compatible with each other. It was in not meant as a disrespect in any way.

My use case is very similar to yours and I have been an org-ref user for a
long time (I was surely one of the earliest beneficiaries of your work),
having written two books and innumerable research papers with org-ref
citation syntax. Being able to export to LaTeX has been my primary use but
the fact that citations were not exported easily to other formats thus far
was a problem I had to struggle with every now and then.


> There are more than 8 years of legacy org-ref documents. I have written
> 40+ scientific papers with it, and countless technical documents with
> more than 8000 cite links among them. org-ref has exceeded 190K
> downloads from MELPA, so I feel obligated to maintain org-ref for
> myself, and those users.


Given that it is not very difficult to convert a document from old org-ref
citation syntax to the org-cite syntax, at least as far as citation is
concerned, this should not be a big problem. Do these documents use
citation commands that are not available in org-cite? Can those not be
added to org-cite?


> I think org-ref and org-cite have different priorities, they solve
> different problems with different approaches, and they have different
> pros and cons.


It might be useful to discuss specific gaps (such as citenum) that need to
be plugged in org-cite for it to be usable. In fact, making org-cite usable
for a heavyweight user like you is a useful goalpost.

I understand that you do not particularly like the modularity and
complexity of org-cite way of specifying styles and variants. But if one is
able to make the two compatible, filling the gaps, they could have a
friendly co-existence with some way of being able to convert a document
between the two styles. And if there are some incompatibilities that cannot
be resolved, it would be good to know exactly what all those are. If
somebody was to write functions to convert from one format to the other,
they could choose how they want to deal with those incompatibilities.


> Cross-references are critical for me; without them, there is no path
> forward for me with org-cite. I did work on a cross-reference approach
> that leveraged org-cite syntax
> (https://github.com/jkitchin/org-ref-cite/issues/16), but there was not
> much appetite for the approach so I abandoned that.


What org-ref seems to do with cross-references is very nice. Unfortunately
this would not be available if a user chooses to use org-cite. Do the
capabilities of cross-referencing have to be wedded to the citation system?

Can this not be resolved?


> I am content to agree to disagree on these points and move forward with
> both packages because they solve different problems, are suitable for
> different communities, and they continue to benefit each other.


Friendly co-existence should be our goal. But can that be a situation in
which one is able to choose between the best of both and, as far as
possible, switch from one to the other.

Thanks again for your time and effort,

Vikas

Re: citations: org-cite vs org-ref 3.0

[Timothy]

Hi John,

Thanks for your considered response.

When you contrast org-cite and org-ref, you say:

> With org-ref, bib(la)tex export is almost fully supported, and is easy,

I find this odd as org-cite supports bib(la)tex export, and rather easily.

┌
│ #+bibliography: references.bib
│ #+cite_export: biblatex authortitle/authortitle-ibid
│ 
│ [cite:@key] etc.
│ 
│ #+print_bibliography:
└

The limitation which I think is on your mind is that not all bib(la)tex commands
are supported, and not in the “usual” form. For instance, to get `pnotecite' one
would use `[cite/locators:]'. However, to get a 1-to-1 name mapping, you can 
just
customise `org-cite-biblatex-styles'. For instance, `parencite' is not currently
available, but if I just add `("parencite" nil "parencite" nil nil)' I can then 
do
`[cite/parencite:]' or if I replace the first `"parencite"' with `"paren"', just
`[cite/paren:]'.

A package could be created, say `org-cite-literal-biblatex' which is just a copy
of `oc-biblatex.el' with a different default `org-cite-biblatex-styles' and
`org-cite-biblatex-style-shortcuts' (or just sets those variables in
`org-cite-biblatex'). As far as I can tell this would provide exactly the
functionality you say org-cite can’t provide but org-ref does.

You can already use `.bib' files, and so frankly I cannot myself see the point 
in
org-ref’s existence beyond bifurcating the community on this. At this point the
only remaining motivation I see is old documents and current users, and for this
a migration tool seems more appropriate.

I don’t mean to be overly critical, however this is my current honest assessment
of the situation.

–
All the best,
Timothy

John Kitchin  writes:

> I do not think it is productive for the community to say or consider it
> is a sad situation. Many good things have emerged from these
> discussions, even if it is not yet consensus on a solution. It is a
> complex problem, with many years of effort by many people on each side.
> That is an indication of how ambitious this project is and that there
> may be more than one solution that is needed. It pains me quite a bit
> there is a sentiment of fractionation, and that I may be contributing to
> it.
>
> My regular job workload the past few years has been crushing, and I have
> not had the time to participate in this that I wish I had. I am not sure
> I can add much here without sounding or feeling defensive about org-ref,
> and my decision to continue supporting and developing it. I have thought
> about this for most of the day, and in the (very long, apologies in
> advance) response that follows I will do my best to provide a balanced
> perspective (from my point of view) on the situation.
>
> Some specific context that is important to me is that I wrote org-ref
> long ago to solve a specific problem for me in the preparation of
> scientific publications that are destined for LaTeX export. I intended
> it to provide nearly equivalent bib(la)tex citation export, and as
> reasonable an export as possible for everything else. I use org-ref
> professionally, and it is a complete solution for me. I simply cannot
> compromise on the capability org-ref provides me, or wait for an
> alternative complete solution in org-mode. I have work I have to do now,
> and org-ref lets me do it. This alone is reason enough for me to
> continue using, developing and supporting org-ref. I understand org is
> not intended to be a substitute for writing LaTeX, but it is a fact of
> my job that I have to do that.
>
> There are more than 8 years of legacy org-ref documents. I have written
> 40+ scientific papers with it, and countless technical documents with
> more than 8000 cite links among them. org-ref has exceeded 190K
> downloads from MELPA, so I feel obligated to maintain org-ref for
> myself, and those users. org-ref may be heavyweight in bundling a lot of
> capability together that could be separated into individual packages,
> but it is also convenient for people who need it, and a GitHUB issue or
> pull request away from new features. I remain committed to supporting
> this, and I do it in a way I can manage, hence the monolithic package
> design.
>
> org-cite was also developed to solve some specific citation problems for
> others that org-ref did not address well at the time it was started. I
> believe those were issues like better pre/post note support, and
> integration with CSL.
>
> I think org-ref and org-cite have different priorities, they solve
> different problems with different approaches, and they have different
> pros and cons. I believe there are mutually incompatible compromises one
> must make here because the specific choices you make determine what is
> easy and what is possible. There is not a direct mapping of bib(la)tex
> and CSL as a citation processor. They are different programs and they
> don’t share citation commands, or style information. It is inevitable
> that something will be lost in the translation between these 

Re: Links to javascript-based websites from orgmode.org: Paypal and Github

[Bradley M. Kuhn]

> "Bradley M. Kuhn"  writes:
> > I generally recommend PayPal to projects that want to minimize
> > proprietary Javascript because you cn often make it all the way through a
> > PayPal transaction (if you already have a PayPal account with a credit
> > card attached and you're in the USA) with Javascript fully turned off.

Ihor Radchenko wrote:
> Could you elaborate a bit why you consider PayPal better than Librepay
> (Stripe)?

Note that Librepay isn't a payment processor; it's a fundraising site that is
a consumer (rather than provider) of payment processing.  Underneath,
Librepay uses PayPal and/or Stripe (and maybe other payment processors, but I
think those are the primary two, and possibly the only two, that Librepay
supports).

In my work at Software Freedom Conservancy (and at other charities before
it), I've evaluated and keep good tabs on how much proprietary software users
are required to install (usually in the form of proprietary Javascript) to
donate money via various payment processors.  It *is* possible to get all the
way through a PayPal donation without running proprietary Javascript once you
already have a PayPal account.  This isn't true with Stripe; every Stripe
transaction needs proprietary Javascript.

Meanwhile, PayPal definitely keeps getting worse, so their advantage over
Stripe isn't particularly strong.  I have heard from folks outside the USA
that it's absolutely impossible to do anything on PayPal without proprietary
Javascript.  When you're geolocated as being in the USA, things are slightly
better with PayPal with regard to Javascript requirements.  If you are in the
USA and have a pre-existing PayPal account, then likely you can get all the
way through the payment without running proprietary Javascript.

> I made an attempt to pay using PayPal with LibreJS extension and I was
> unable to go through even a little.  …  For Librepay, I made all the way to
> the point where I had to run Stripe.

Right, but that is merely comparing an apple martini to an apple juice box,
and pointing out the latter didn't cause the user to become intoxicated.
AFAICT, Librepay doesn't process payments without Stripe or PayPal (or some
other payment processor).  Obviously if you like the add-on services that
Librepay offers for donation solicitation/management on top of payment
processing, then by all means use that too.  But ultimately underneath,
you'll be using some payment processor.

> Now, we have removed PayPal and left Librepay option in orgmode.org, but if
> you think that PayPal should be considered better compared to Librepay
> ethically, we would like to hear your opinion.

Again, the individual (and I think it is just one person) that runs Librepay
is providing a service that some folks like, but that service isn't
processing payments, AFAIK.

If you're encourage people to donate to orgmode via Librepay, you're
encouraging them to use either PayPal or Stripe, ultimately, since they won't
finish the donation transaction without using an underlying payment
processor.  As I said, if you like the add-ons that Librepay is providing on
top of PayPal and/or Stripe, then of course enjoy them, since Librepay
*itself* (AFAIK) is licensed freely.  But, if you goal is to find a payment
processor that doesn't require users to (at least sometimes) run proprietary
Javascript, then there is basically no way to do it, unless you do the PCI
compliance yourself, which is a staffing commitment. (I discussed this in my
prior email.)

Thank you again for orgmode.  I use it every day!

  -- bkuhn

Re: citations: org-cite vs org-ref 3.0

[John Kitchin]

I do not think it is productive for the community to say or consider it
is a sad situation. Many good things have emerged from these
discussions, even if it is not yet consensus on a solution. It is a
complex problem, with many years of effort by many people on each side.
That is an indication of how ambitious this project is and that there
may be more than one solution that is needed. It pains me quite a bit
there is a sentiment of fractionation, and that I may be contributing to
it.

My regular job workload the past few years has been crushing, and I have
not had the time to participate in this that I wish I had. I am not sure
I can add much here without sounding or feeling defensive about org-ref,
and my decision to continue supporting and developing it. I have thought
about this for most of the day, and in the (very long, apologies in
advance) response that follows I will do my best to provide a balanced
perspective (from my point of view) on the situation.

Some specific context that is important to me is that I wrote org-ref
long ago to solve a specific problem for me in the preparation of
scientific publications that are destined for LaTeX export. I intended
it to provide nearly equivalent bib(la)tex citation export, and as
reasonable an export as possible for everything else. I use org-ref
professionally, and it is a complete solution for me. I simply cannot
compromise on the capability org-ref provides me, or wait for an
alternative complete solution in org-mode. I have work I have to do now,
and org-ref lets me do it. This alone is reason enough for me to
continue using, developing and supporting org-ref. I understand org is
not intended to be a substitute for writing LaTeX, but it is a fact of
my job that I have to do that.

There are more than 8 years of legacy org-ref documents. I have written
40+ scientific papers with it, and countless technical documents with
more than 8000 cite links among them. org-ref has exceeded 190K
downloads from MELPA, so I feel obligated to maintain org-ref for
myself, and those users. org-ref may be heavyweight in bundling a lot of
capability together that could be separated into individual packages,
but it is also convenient for people who need it, and a GitHUB issue or
pull request away from new features. I remain committed to supporting
this, and I do it in a way I can manage, hence the monolithic package
design.

org-cite was also developed to solve some specific citation problems for
others that org-ref did not address well at the time it was started. I
believe those were issues like better pre/post note support, and
integration with CSL.

I think org-ref and org-cite have different priorities, they solve
different problems with different approaches, and they have different
pros and cons. I believe there are mutually incompatible compromises one
must make here because the specific choices you make determine what is
easy and what is possible. There is not a direct mapping of bib(la)tex
and CSL as a citation processor. They are different programs and they
don't share citation commands, or style information. It is inevitable
that something will be lost in the translation between these from a
single source like org, and whether that loss is acceptable depends on
what you need. For many things, close enough is ok for me, but for
manuscripts and proposals, they must be perfect, and in bib(la)tex form
for the journals I publish in. It is not that one thing is possible in
one and not the other; it is that you have to compromise one to do the
other no matter what you choose and that typically makes one thing or
the other easier to do. I am not even sure it is possible to do
everything one can do in bib(la)tex with CSL, for example, I don't know
the equivalent of \citenum in CSL. org-ref sides on making bib(la)tex
easy, and CSL is possible.

With org-cite, CSL can be readily used across export backends, more
bibliography database formats are supported, and it is also possible to
get LaTeX export, although there is no goal to fully support all of
bib(la)tex. A pure org approach (e.g. org-files as bibliography
database) can be used, there are a lot of CSL styles to work with, and
you can develop or adapt your own style if needed. With reasonable
defaults this should be a straightforward introduction to using
citations for new users that works out of the box. I support that.

With org-ref, bib(la)tex export is almost fully supported, and is easy,
and other exports via CSL are possible. Of course, you must have a
working LaTeX installation, only bibtex databases are supported, and
working knowledge of bib(la)tex is required to leverage this. Whether
you want it or not, you get a lot of extra utilities for getting bibtex
entries from a DOI, and support for cross-references, indexes,
glossaries and acronyms. This is a lot to ask of people who don't need
it, and convenient for those who do. I support this.

Which one of these approaches is right depends on what you want to 

Re: citations: org-cite vs org-ref 3.0

[Dominik Schrempf]

“Bruce D’Arcus”  writes:

> On Sun, Mar 20, 2022 at 4:21 PM Dominik Schrempf
>  wrote:
>
>> For what it’s worth, I use `org-ref` because fine-grained citation export 
>> with
>> LaTeX (using BibTeX or BibLaTeX) only works with `org-ref`, and not with
>> `org-cite`.
>
> Part of the challenge is this isn’t an apples-apples comparison;
> org-cite a framework, and it’s the processors that really provide the
> functionality.
>
>> If I remember correctly, `org-cite` exports the formatted citations into the
>> LaTeX file …
>
> This is not true.

Thanks for correcting me on that. I remember having LaTeX files with full
citations in them, but maybe I messed something up.

>
> Or rather, it’s only true if you use the oc-csl export processor; you
> can use other export processors (like oc-biblatex) to get whatever
> LaTeX output you want, and …
>
>>  …. it is really difficult to use different style files, etc. With
>> `org-ref`, I can use BibLaTeX with specific style files. (Journal require
>> different style files). I can even use my personal LaTeX classes (with 
>> specific
>> bibliography styles) for Org export.
>
> … I believe Nicolas recently added support for customizing the
> export styles for biblatex.
>
> Bruce

When I tried setting `org-cite` up, it didn’t work. Maybe I should give it
another try at some point. For now, I am happy with `org-ref`.

Re: How do you manage complex project with Org-mode

[Tim Cross]

Ihor Radchenko  writes:

> Tim Cross  writes:
>
>> For example, I
>> would not have a task which says to review my tasks twice a week. Do you
>> really need a task to remind you to do this twice a week? Do you really
>> need to track that you have done this? I would classify such tasks as
>> 'noise' tasks. They really don't perform any real purpose.  It is
>> similar to brain dead project policies which state things like "every
>> function must have a unit test". Many functions don't need a unit test
>> and forcing people to write pointless unit tests does more damage than
>> not having them.
>
> I disagree about this specific example (not with your whole idea).
> Reviewing tasks is important for people who can easily fall into
> continuous routine. Dedicating several hours per week to look into what
> you are doing in a broader perspective is valuable.
>
> Note that I do not mean "review" as looking through _all_ the tasks.
> Rather looking into current projects and deciding what to do, and, more
> importantly, what not to do in the coming week/days/months.
>
> See https://www.benkuhn.net/weekly/
>

My point was not that you don't need to review on a regular basis.
Reviewing your tasks and projects regularly is essential. My point was
that creating a todo task telling you to review your tasks/projects is
an example of a 'noise' task.

A common beginner error I've seen is for people to be so impressed with
org-mode, they decide to create tasks, templates and projects which map
out every aspect of their life. The problem with doing this is that you
then create additional work for yourself in managing these tasks and you
run the risk of being overwhelmed - you have so many tasks that instead
of making your life easier, you now become paralysed by too many task
choices.  

Getting the right balance is challenging and we do need to review
what/how we do things and refine our process in a continuous analyse,
plan, implement, review cycle.  

Re: citations: org-cite vs org-ref 3.0

[chris]

On Sunday, 20 March 2022 20:44:50 CET Bruce D'Arcus wrote:
> On Sun, Mar 20, 2022 at 9:42 AM Ihor Radchenko  wrote:
> > For citar, why not simply using ivy-bibtex? It supports org-cite, AFAIK.
> 
> Not really; or rather minimally.

I use `org-cite` with a very minimal configuration, and it works very well. I 
don't use `ivy` at all. I don't use `helm` at all. Those are very large 
framework and should not be forced to people. (I don't use `org-ref`.)

I only use `citar` with minimal configuration. I use `vertico` for the 
completion. `citar` is simple enough for me to be able to read and understand 
a large part of it.

IMO the more layers of code there are, the more difficult it is to have things 
work right. And similarly with the size of the code.

Chris

> 
> Ivy-bibtex supports, for example, inserting of org-cite citations, but
> not via org-cite-insert.

And I have `org-cite-insert` working straight out of the box.

> 
> So there are currently no org-cite processors for ivy-bibtex etc.
> 
> Bruce

Re: [BUG] Resolving idle clocks needs multiple keystrokes [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]

[Roméo La Spina]

Thanks for your answer! I will do that as soon as I have a little more time.

Ignacio Casso  writes:

>> Hmm, I see the problem. I didn't think about that.
>> Thank you very much for your suggestion. But what about using
>> read-char-exclusive? It seems to have a timeout argument too, and
>> should apparently fix the issue (ie. the prompt will no longer
>> disappear at the first unintentional click).
>>
>> Romeo
>>
>
> That would indeed fix your bug, it seems. Not mine, since it
> does not reset the idle timer either. I suggest you reply
> https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00278.html
> with a patch, just replacing `read-char' with `read-char-exclusive'.
>
> --Ignacio

Re: citations: org-cite vs org-ref 3.0

[Bruce D'Arcus]

On Sun, Mar 20, 2022 at 4:21 PM Dominik Schrempf
 wrote:

> For what it’s worth, I use `org-ref` because fine-grained citation export with
> LaTeX (using BibTeX or BibLaTeX) only works with `org-ref`, and not with
> `org-cite`.

Part of the challenge is this isn't an apples-apples comparison;
org-cite a framework, and it's the processors that really provide the
functionality.

> If I remember correctly, `org-cite` exports the formatted citations into the
> LaTeX file ...

This is not true.

Or rather, it's only true if you use the oc-csl export processor; you
can use other export processors (like oc-biblatex) to get whatever
LaTeX output you want, and ...

>   it is really difficult to use different style files, etc. With
> `org-ref`, I can use BibLaTeX with specific style files. (Journal require
> different style files). I can even use my personal LaTeX classes (with 
> specific
> bibliography styles) for Org export.

... I believe Nicolas recently added support for customizing the
export styles for biblatex.

Bruce

Re: citations: org-cite vs org-ref 3.0

[Vikas Rawal]

>
>
>
> For what it’s worth, I use `org-ref` because fine-grained citation export
> with
> LaTeX (using BibTeX or BibLaTeX) only works with `org-ref`, and not with
> `org-cite`.
>

 It would help if you can explain what you mean.

If I remember correctly, `org-cite` exports the formatted citations into the
> LaTeX file, which is a no-go for me (let me know if I am wrong).


This is not correct. org-cite exports citation commands to LaTeX, and LaTeX
does rest of the processing. I do not think there is any difference in the
approach between org-cite and org-ref.


> Then, for
> example, it is really difficult to use different style files, etc. With
> `org-ref`, I can use BibLaTeX with specific style files. (Journal require
> different style files). I can even use my personal LaTeX classes (with
> specific
> bibliography styles) for Org export.
>
>
Surely org-cite allows you to do all of this.

Vikas

Re: citations: org-cite vs org-ref 3.0

[Dominik Schrempf]

“Thomas S. Dye”  writes:

> Ihor Radchenko  writes:
>
>> Vikas Rawal  writes:
>>
>>> What is the general view of the community about this? Is there a
>>> comprehensive discussion of pros and cons of each?
>>
>> Prof. Kitchin himself provided a summary on why he decided to give up on
>> using org-cite. See 
>>
> This claim in Kitchin’s summary surprised me:
>
> “It comes down to org-ref using bibtex/biblatex as the predominant citation
> processor, and org-cite using CSL. These two processors have different 
> syntaxes,
> and I don’t think it is possible to have a single approach that works for both
> of them without making compromises in capability.”
>
> I wonder what are the “compromises in capability” required to support both?
>
> I haven’t found them yet, though I’m just now finishing old projects started
> prior to the release of org-cite and haven’t worked through a LaTeX export
> project with it.  My first, and so far only, project with org-cite was for a
> simple html-based presentation using CSL, and I was pleased with the results 
> and
> relative ease of setup.
>
> All the best,
> Tom

For what it’s worth, I use `org-ref` because fine-grained citation export with
LaTeX (using BibTeX or BibLaTeX) only works with `org-ref`, and not with
`org-cite`.

If I remember correctly, `org-cite` exports the formatted citations into the
LaTeX file, which is a no-go for me (let me know if I am wrong). Then, for
example, it is really difficult to use different style files, etc. With
`org-ref`, I can use BibLaTeX with specific style files. (Journal require
different style files). I can even use my personal LaTeX classes (with specific
bibliography styles) for Org export.

Not sure if this helps…, but this is maybe what John Kitchin is referring to.

Dominik

Re: citations: org-cite vs org-ref 3.0

[Bruce D'Arcus]

On Sun, Mar 20, 2022 at 9:42 AM Ihor Radchenko  wrote:

> For citar, why not simply using ivy-bibtex? It supports org-cite, AFAIK.

Not really; or rather minimally.

Ivy-bibtex supports, for example, inserting of org-cite citations, but
not via org-cite-insert.

So there are currently no org-cite processors for ivy-bibtex etc.

Bruce

Re: citations: org-cite vs org-ref 3.0

[Thomas S. Dye]

Ihor Radchenko  writes:


Vikas Rawal  writes:

What is the general view of the community about this? Is there 
a

comprehensive discussion of pros and cons of each?


Prof. Kitchin himself provided a summary on why he decided to 
give up on
using org-cite. See 
https://github.com/jkitchin/org-ref/issues/892



This claim in Kitchin's summary surprised me:

"It comes down to org-ref using bibtex/biblatex as the predominant 
citation processor, and org-cite using CSL. These two processors 
have different syntaxes, and I don't think it is possible to have 
a single approach that works for both of them without making 
compromises in capability."


I wonder what are the "compromises in capability" required to 
support both?


I haven't found them yet, though I'm just now finishing old 
projects started prior to the release of org-cite and haven't 
worked through a LaTeX export project with it.  My first, and so 
far only, project with org-cite was for a simple html-based 
presentation using CSL, and I was pleased with the results and 
relative ease of setup.


All the best,
Tom

--
Thomas S. Dye
https://tsdye.online/tsdye

Re: [RFC] DOCT: Declarative Org Capture Templates (easier template syntax)

[Mark Barton]

+1 as interested
I saw this project a while ago
https://github.com/progfolio/doct 

I was concerned about long term support and if I would be left with templates I 
would have to rewrite again, plus I was too busy at the time to adopt it and it 
stays in my list of TODOs that are not scheduled. That being said, I use org 
capture daily, but to the points you raise, I avoid changing or adding to to my 
capture templates.



> On Mar 20, 2022, at 3:19 AM, Ihor Radchenko  wrote:
> 
> I am pinging this thread again because I believe that doct syntax is
> much easier to write compared to current defaults. It should be added to
> Org core.
> 
> Also, if anyone agrees with my arguments below, do not stay silent and
> drop a "+1" email below. Otherwise, this whole thing will be stalled.
> There is no point discussing technical aspects, if there is no interest.
> 
> Citing again an example illustrating the difference between a slightly
> non-trivial capture template using current vs. doct syntax:
> 
> No Wayman  writes:
> 
>> Without DOCT:
>> 
>> ;;rest of template configured elsewhere...
>> ;;make sure you update this if you ever change the key for this 
>>  template!
>> (defun my-org-template-hook ()
>>  (when (string= (org-capture-get :key t) "t")
>>(message "Template \"t\" selected.")))
>> 
>> (add-hook 'org-capture-mode-hook 'my-org-template-hook)
>> 
>> With DOCT:
>> 
>> (doct `("Example" :keys "t" :file ""
>>:hook (lambda () (message "Template %s selected." 
>>(doct-get :keys)
>> 
>> DOCT ensures that function is only run for that template without 
>> having the user manually filter against `org-capture-plist's :key.
>> It also allows the user to do this inline with the rest of the 
>> declaration vs spreading it out.
> 
> I believe that the right way to introduce this syntax is creating an
> easy-to-use macro like (org-declare-capture-template ...), which takes
> care about fiddling with org-capture-templates variable and its format.
> 
> The current format of a number of Org customisations is cumbersome. For
> example, org-capture-templates and org-agenda-custom-commands often
> become long list of lists with each element that must have a very
> specific position. Every single time I need to write a new template, I
> have to carefully consult the docstring; and every single time I an
> reviewing my templates, I have to consult the docstring again simply to
> understand the meaning of the first, second, ..., nth element of the
> template. Having CL-style :keyword value plists is much more readable.
> 
> More generally, it would be useful to provide a doct-like functionality
> for org-agenda-custom-commands and similar variables (like
> org-agenda-custom-commands, or say, also org-latex-classes).
> 
> Best,
> Ihor
> 

Re: citations: org-cite vs org-ref 3.0

[Bruce D'Arcus]

On Sun, Mar 20, 2022 at 10:08 AM Vikas Rawal  wrote:
>>
>> > What is the general view of the community about this?
>>
>> I don't know about the general view of the community, but, as a data
>> point, I find it very sad.
>
>
> Exactly how I feel. Particularly so because org-cite was indeed inspired from 
> org-ref and all the great work John has done on this over the years. I do not 
> see any substantive discussion of the limitations that John has pointed out 
> with org-cite in the archives of the mailing list. We should have a 
> conversation about those.
>
> If I understand correctly, the main limitation according to him is that 
> org-cite does not handle cross-references. Is that the only problem? What do 
> others think about it? Do we want the citation system to be able to handle 
> cross-references? If not, do we need a separate system that handles 
> cross-references beyond what is available in org-mode already? Can that 
> system not be created in a manner that would not break the org-cite syntax?
>
> I think we should have a conversation and collectively think of what is the 
> best way forward.

Yes, and no.

Conversation on org-cite took place on this list for years, with
diverse people, with diverse expertise and POV, cycling in and out
over that time.

John raised the cross-reference question towards the very end, during
the testing period, when it was almost merged.

https://www.mail-archive.com/emacs-orgmode@gnu.org/msg138349.html

I still think the path forward on that is TBD, though as I said, I
don't think it should be in scope for org-cite per se, but org more
generally yes.

If he has some other issues (which I suspect he does; maybe related to
fontification?) that might be addressed, I'm sure he'll raise them.

Bruce

Re: citations: org-cite vs org-ref 3.0

[Vikas Rawal]

>
> > What is the general view of the community about this?
>
> I don't know about the general view of the community, but, as a data
> point, I find it very sad.
>

Exactly how I feel. Particularly so because org-cite was indeed inspired
from org-ref and all the great work John has done on this over the years. I
do not see any substantive discussion of the limitations that John has
pointed out with org-cite in the archives of the mailing list. We should
have a conversation about those.

If I understand correctly, the main limitation according to him is that
org-cite does not handle cross-references. Is that the only problem? What
do others think about it? Do we want the citation system to be able to
handle cross-references? If not, do we need a separate system that handles
cross-references beyond what is available in org-mode already? Can that
system not be created in a manner that would not break the org-cite syntax?

I think we should have a conversation and collectively think of what is the
best way forward.

Vikas

Re: citations: org-cite vs org-ref 3.0

[Ihor Radchenko]

Vikas Rawal  writes:

> What is the general view of the community about this? Is there a
> comprehensive discussion of pros and cons of each?

Prof. Kitchin himself provided a summary on why he decided to give up on
using org-cite. See https://github.com/jkitchin/org-ref/issues/892

> What is everyone doing? I was an org-ref user for long before I switched to
> org-cite. I can now shift to citar but since I am an ivy user, the switch
> is not trivial. Also, I like many helper functions that John has created,
> and would have to miss those if I do not use org-ref/org-ref-cite.

I personally used org-ref for a long time simply because no
alternatives. I dislike org-ref because Prof. Kitchin prefers to do
things in very specific way and it is not always possible to customise
them. It is hard to use only a part of org-ref without using everything
and getting surprising behaviour.

Now, I am trying to switch to org-cite + .org files as bibliography. But
the whole thing is an ad-hoc mess.

For citar, why not simply using ivy-bibtex? It supports org-cite, AFAIK.

Best,
Ihor

Re: citations: org-cite vs org-ref 3.0

[Bruce D'Arcus]

On Sun, Mar 20, 2022 at 8:09 AM Vikas Rawal  wrote:

> What is the general view of the community about this? Is there a 
> comprehensive discussion of pros and cons of each?

Not really, but there's John's summary here:

https://github.com/jkitchin/org-ref#what-about-org-cite

The high-level discussion at the beginning, including the enumerated
points, seems right to me.

The following point that "org-cite does not meet my citation and
technical document publishing needs, and it was not possible to
integrate it into org-ref without compromising those" is more subject
to debate, particularly the first clause.

I don't see any practical advantage to the org-ref syntax and model,
unless you include cross-references and such.

But that's because I just don't think cross-references and indexes
should be handled in org-cite; I think if we need improvements in
existing cross-references etc support, we should add those there.

I suspect he's also meaning the different ways that citation
commands/styles are handled in the two systems.

Here's an example from org-ref 3:

[[citealp:See  page 2]]

Note that first piece: "citealp". That's the command, which org-ref
will output directly to LaTeX/Natbib as \citealp. Note that command
only makes sense for natbib.

Org-cite has a different abstraction here: the style/substyle system.
So the above would be ...

[cite/bare:See @kitchin-2015-examp page 2]

... and then whatever export processor would map that "bare" style to
the appropriate output.

So that leaves the last bit; the "not possible" point, which I can't
address. It would obviously be nice if org-ref supported org-cite in
the future.

> What is everyone doing? I was an org-ref user for long before I switched to 
> org-cite. I can now shift to citar but since I am an ivy user, the switch is 
> not trivial. Also, I like many helper functions that John has created, and 
> would have to miss those if I do not use org-ref/org-ref-cite.

A month or so ago, John offered to turn over maintenance of
org-ref-cite to someone else, which might be one good option for
someone who uses ivy, in particular, and interested in developing it
further.

More generally, the modular design of org-cite should result, in time,
with diverse components, including for different completion
frameworks. For example, I think it'd be pretty easy to create an
insert process for helm-bibtex or ivy-bibtex, and a follow processor
for bibtex-completion.

Or alternatively, as citar now no longer requires bibtex-completion,
someone could write a small citar front-end for ivy as an insert
processor.

The whole point of the org-ctite design is it should be easy for users
to mix-and-match different pieces, and for documents to remain
compatible across users and export backends. It also allows developers
to focus on those small components.

Bruce

Re: citations: org-cite vs org-ref 3.0

[Nicolas Goaziou]

Hello,

Vikas Rawal  writes:

> This obviously creates many problems including that two people using
> different citation systems cannot share org files.

Indeed.
>
> What is the general view of the community about this?

I don't know about the general view of the community, but, as a data
point, I find it very sad.

That's not helpful, tho.

Regards,
-- 
Nicolas Goaziou

Re: [RFC] DOCT: Declarative Org Capture Templates (easier template syntax)

[Nicolas Goaziou]

Hello,

Ihor Radchenko  writes:

> I am pinging this thread again because I believe that doct syntax is
> much easier to write compared to current defaults. It should be added to
> Org core.
>
> Also, if anyone agrees with my arguments below, do not stay silent and
> drop a "+1" email below. Otherwise, this whole thing will be stalled.
> There is no point discussing technical aspects, if there is no
> interest.

I think there should be a direct mapping between Customize interface and
values. Adding this macro as a band-aid to simply configuration is not,
IMO, a solution.

If capture templates values are too complicated, what about simplifying
them, and possibly use this macro as a temporary solution to help
transition?

Regards,
-- 
Nicolas Goaziou

Re: [BUG] Resolving idle clocks needs multiple keystrokes [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]

[Ignacio Casso]

> Hmm, I see the problem. I didn't think about that.
> Thank you very much for your suggestion. But what about using
> read-char-exclusive? It seems to have a timeout argument too, and
> should apparently fix the issue (ie. the prompt will no longer
> disappear at the first unintentional click).
>
> Romeo
>

That would indeed fix your bug, it seems. Not mine, since it
does not reset the idle timer either. I suggest you reply
https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00278.html
with a patch, just replacing `read-char' with `read-char-exclusive'.

--Ignacio

[PATCH] Re: [BUG] Hard-coded begin/end in org-insert-structure-template [9.5.2 (release_9.5.2-24-g668205 @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]

[Ihor Radchenko]

Rudolf Adamkovič  writes:

> Inspired by Protesilaos Stavrou, I started using uppercase Org keywords.
> I like the results so far, but I also noticed some inflexibility in the
> Org mode.  Specifically, the `org-insert-structure-template' procedure
> hard-codes lowercase "begin_" and "end_".  Thus, even if one customizes
> the `org-structure-template-alist' with uppercase keywords, Org still
> inserts them as "begin_SRC".  Given that Org lets the user pick their
> preferred style, I consider this a bug.

I would not call it a bug, but the situation can certainly be improved.

We can auto-magically determine whether to use BEGIN_ or begin_
depending on the case in template type. Tentative patch attached.

Best,
Ihor

>From bdf8340ab8b41f0c9f26f5b0bdadbf079b8f6d66 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Sun, 20 Mar 2022 20:15:21 +0800
Subject: [PATCH] Auto-Upcase/downcase #+begin/#+end in structure templates

* lisp/org-tempo.el (org-tempo-add-block):
* lisp/org.el (org-insert-structure-template): When inserting
 #+begin_type/#+end_type, follow type's case.  TYPE will become
 #+BEGIN_TYPE and type will become #+bein_type.

(org-insert-structure-template): Make sure that we use
case-insensitive match even when user changes case-fold-search value.

(org-structure-template-alist): Clarify selection of #+BEGIN/END
vs. #+begin/end in the docstring.
---
 lisp/org-tempo.el | 13 ++---
 lisp/org.el   | 19 +--
 2 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/lisp/org-tempo.el b/lisp/org-tempo.el
index b34007bf7..cd5ef9e8e 100644
--- a/lisp/org-tempo.el
+++ b/lisp/org-tempo.el
@@ -119,11 +119,18 @@ (defun org-tempo-add-block (entry)
   "Add block entry from `org-structure-template-alist'."
   (let* ((key (format "<%s" (car entry)))
 	 (name (cdr entry))
-	 (special (member name '("src" "export"
+	 (special (member name '("src" "export")))
+ (upcase? (string= (car (split-string name))
+   (upcase (car (split-string name))
 (tempo-define-template (format "org-%s" (replace-regexp-in-string " " "-" name))
-			   `(,(format "#+begin_%s%s" name (if special " " ""))
+			   `(,(format "#+%s_%s%s"
+  (if upcase? "BEGIN" "begin")
+  name
+  (if special " " ""))
 			 ,(when special 'p) '> n ,(unless special 'p) n
-			 ,(format "#+end_%s" (car (split-string name " ")))
+			 ,(format "#+%s_%s"
+  (if upcase? "END" "end")
+  (car (split-string name " ")))
 			 >)
 			   key
 			   (format "Insert a %s block" name)
diff --git a/lisp/org.el b/lisp/org.el
index 9455c15c8..26617d7c8 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -9492,7 +9492,9 @@ (defcustom org-structure-template-alist
   "An alist of keys and block types.
 `org-insert-structure-template' will display a menu with this
 list of templates to choose from.  The block type is inserted,
-with \"#+BEGIN_\" and \"#+END_\" added automatically.
+with \"#+begin_\" and \"#+end_\" added automatically.  If the block
+type is written using upper case letter, \"#+BEGIN_\" and \"#+END_\"
+are added instead.
 
 The menu keys are defined by the car of each entry in this alist.
 If two entries have the keys \"a\" and \"aa\" respectively, the
@@ -9624,18 +9626,23 @@ (defun org-insert-structure-template (type)
 Select a block from `org-structure-template-alist' then type
 either RET, TAB or SPC to write the block type.  With an active
 region, wrap the region in the block.  Otherwise, insert an empty
-block."
+block.
+
+When foo is written as FOO, upcase the #+BEGIN/END as well."
   (interactive
(list (pcase (org--insert-structure-template-mks)
 	   (`("\t" . ,_) (read-string "Structure type: "))
 	   (`(,_ ,choice . ,_) choice
-  (let* ((region? (use-region-p))
+  (let* ((case-fold-search t) ; Make sure that matches are case-insnsitive.
+ (region? (use-region-p))
 	 (region-start (and region? (region-beginning)))
 	 (region-end (and region? (copy-marker (region-end
 	 (extended? (string-match-p "\\`\\(src\\|export\\)\\'" type))
 	 (verbatim? (string-match-p
 		 (concat "\\`" (regexp-opt '("example" "export" "src")))
-		 type)))
+		 type))
+ (upcase? (string= (car (split-string type))
+   (upcase (car (split-string type))
 (when region? (goto-char region-start))
 (let ((column (current-indentation)))
   (if (save-excursion (skip-chars-backward " \t") (bolp))
@@ -9643,7 +9650,7 @@ (defun org-insert-structure-template (type)
 	(insert "\n"))
   (save-excursion
 	(indent-to column)
-	(insert (format "#+begin_%s%s\n" type (if extended? " " "")))
+	(insert (format "#+%s_%s%s\n" (if upcase? "BEGIN" "begin") type (if extended? " " "")))
 	(when region?
 	  (when verbatim? (org-escape-code-in-region (point) 

citations: org-cite vs org-ref 3.0

[Vikas Rawal]

I am sorry I have not followed the discussions recently. I had
happily settled on org-cite but I find that much has changed again.

In particular, John Kitchin has given up the work on org-ref-cite and
switched back to org-ref. There is a new org-ref version 3.0 which is not
compatible with org-cite.

This obviously creates many problems including that two people using
different citation systems cannot share org files.

What is the general view of the community about this? Is there a
comprehensive discussion of pros and cons of each?

What is everyone doing? I was an org-ref user for long before I switched to
org-cite. I can now shift to citar but since I am an ivy user, the switch
is not trivial. Also, I like many helper functions that John has created,
and would have to miss those if I do not use org-ref/org-ref-cite.

This seems messy.

Vikas

[BUG] Hard-coded begin/end in org-insert-structure-template [9.5.2 (release_9.5.2-24-g668205 @ /Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)]

[Rudolf Adamkovič]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.

Hello smart people!

Inspired by Protesilaos Stavrou, I started using uppercase Org keywords.
I like the results so far, but I also noticed some inflexibility in the
Org mode.  Specifically, the `org-insert-structure-template' procedure
hard-codes lowercase "begin_" and "end_".  Thus, even if one customizes
the `org-structure-template-alist' with uppercase keywords, Org still
inserts them as "begin_SRC".  Given that Org lets the user pick their
preferred style, I consider this a bug.

Rudy

Emacs  : GNU Emacs 29.0.50 (build 14, x86_64-apple-darwin21.2.0, NS 
appkit-2113.20 Version 12.1 (Build 21C52))
 of 2022-03-15
Package: Org mode version 9.5.2 (release_9.5.2-24-g668205 @ 
/Users/salutis/src/emacs/nextstep/Emacs.app/Contents/Resources/lisp/org/)
-- 
"Thinking is a momentary dismissal of irrelevancies."
-- Richard Buckminster Fuller, 1969

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: Links to javascript-based websites from orgmode.org: Paypal and Github

[Ihor Radchenko]

"Bradley M. Kuhn"  writes:

> I'd be glad to discuss how I've come to these assessments in more detail if
> that's useful to the discussion.  (However, I won't have time to check back
> into this thread until Tuesday due to a deadline.)
>
> I generally recommend PayPal to projects that want to minimize proprietary
> Javascript because you cn often make it all the way through a PayPal
> transaction (if you already have a PayPal account with a credit card attached
> and you're in the USA) with Javascript fully turned off.  That's not saying
> much, but it's better than other processors.  I retest that every 3-6 months;
> the last time I tested it was November.
>
> Comparatively, Stripe is particularly bad because they mandate that you load
> their proprietary Javascript on your own page (see below in footnote for
> more) if you want them to handle the PCI compliance.
>
>
> [0] Someone mentioned liberapay — but it simply uses Stripe and/or PayPal
> underneath for the donations.  I just double checked this and noticed
> that the payment page has:
>  https://js.stripe.com/v3/";>
> which is what Stripe requires if you want them to handle the PCI
> compliance.

Thanks for the insight! Could you elaborate a bit why you consider
PayPal better than Librepay (Stripe)? I made an attempt to pay using
PayPal with LibreJS extension and I was unable to go through even a
little. For Librepay, I made all the way to the point where I had to run
Stripe.

Now, we have removed PayPal and left Librepay option in orgmode.org, but
if you think that PayPal should be considered better compared to
Librepay ethically, we would like to hear your opinion.

Best,
Ihor

Re: [PATCH] lisp/org-capture.el: Add hook & hook options to org-capture (Valentin Herrmann)

[Ihor Radchenko]

No Wayman  writes:

>> I think Nicolas gave some reasonable comments, didn't he? He 
>> suggested
>> to incorporate some of the ideas into the existing Org mode 
>> code.
>>
>> https://orgmode.org/list/87wo66t8i7@gmail.com
>
> I believe you're referring to:
>
> https://list.orgmode.org/87y2qlgq33@nicolasgoaziou.fr/
>
> He had some reasonable questions about the design, but said he 
> only uses very basic capture templates, and could not comment 
> beyond that on the design. The hope was that people who use more 
> of org-capture's features would chime in. That didn't happen.

I just pinged that thread again. Note that I strongly support adding
doct to Org.

> Of course doct's features could be added to org-capture in a 
> piecemeal fashion, but I'm not too keen on contributing anything 
> non-trivial to Org these days. Too much back and forth coupled 
> with discussion that can stall due to lack of interest. 
> e.g.

> https://list.orgmode.org/87h7e6dluc@gmail.com/
> https://list.orgmode.org/87tuit73ij@gmail.com/

I cannot comment on the lexical binding thing. I do not really know
lexical binding internals enough to judge what kind of problem that
patch is trying to solve. However, Bastien commented on the second
patch. I do find it useful as well. I think the only problem with that
patch is that it is not listed in updates.orgmode.org and Bastien missed
your last reply.

Best,
Ihor

Re: [RFC] DOCT: Declarative Org Capture Templates (easier template syntax)

[Ihor Radchenko]

I am pinging this thread again because I believe that doct syntax is
much easier to write compared to current defaults. It should be added to
Org core.

Also, if anyone agrees with my arguments below, do not stay silent and
drop a "+1" email below. Otherwise, this whole thing will be stalled.
There is no point discussing technical aspects, if there is no interest.

Citing again an example illustrating the difference between a slightly
non-trivial capture template using current vs. doct syntax:

No Wayman  writes:

> Without DOCT:
>
> ;;rest of template configured elsewhere...
> ;;make sure you update this if you ever change the key for this 
>   template!
> (defun my-org-template-hook ()
>   (when (string= (org-capture-get :key t) "t")
> (message "Template \"t\" selected.")))
>
> (add-hook 'org-capture-mode-hook 'my-org-template-hook)
>
> With DOCT:
>
> (doct `("Example" :keys "t" :file ""
> :hook (lambda () (message "Template %s selected." 
> (doct-get :keys)
>
> DOCT ensures that function is only run for that template without 
> having the user manually filter against `org-capture-plist's :key.
> It also allows the user to do this inline with the rest of the 
> declaration vs spreading it out.

I believe that the right way to introduce this syntax is creating an
easy-to-use macro like (org-declare-capture-template ...), which takes
care about fiddling with org-capture-templates variable and its format.

The current format of a number of Org customisations is cumbersome. For
example, org-capture-templates and org-agenda-custom-commands often
become long list of lists with each element that must have a very
specific position. Every single time I need to write a new template, I
have to carefully consult the docstring; and every single time I an
reviewing my templates, I have to consult the docstring again simply to
understand the meaning of the first, second, ..., nth element of the
template. Having CL-style :keyword value plists is much more readable.

More generally, it would be useful to provide a doct-like functionality
for org-agenda-custom-commands and similar variables (like
org-agenda-custom-commands, or say, also org-latex-classes).

Best,
Ihor

Re: Communication problems and possible problems with the website

[Ihor Radchenko]

Bastien Guerry  writes:

> Discourse is nice but I'm not favor of installing an instance for Org.
>
> Beginners often ask questions on reddit.com and stackoverflow.com (and
> perhaps elsewhere): perhaps some regular users of these websites could
> serve as "contributors stewards", redirecting interesting bug reports,
> patches or feature requests on this mailing list.

That's an unfortunate truth. reddit and stackoverflow require users to
run non-free JS to write comments. Discourse would provide a familiar
interface for beginners + not force them to use non-free JS. In
addition, there will be no risk to lose information or the annoying
reddit behaviour when no comments can be added to old posts.

> My gut feeling is that we should focus on making the mailing list more
> accessible for beginners, more useful for everyone before considering
> setting up another communication channel.
>
> I have a new version for Woof! (https://git.sr.ht/~bzg/woof) that I'd
> like to finalize and set up this month - let's see how this helps and
> reopen this topic in three or four months?

I do like the idea of Woof!. My main concern is that adding new features
to Woof! (like tagging threads, adding more categories, etc) is putting
even more load on you. I am not sure if Woof! can be on-par with
Discourse features given that you are the only contributor.

Best,
Ihor

Re: Links to javascript-based websites from orgmode.org: Paypal and Github

[Ihor Radchenko]

Max Nikulin  writes:

> Actually I considered Atom and VS Code (that are still on the main page) 
> quite similar. I admit that they are open source, but are available 
> packages are really free? Maybe my opinion was just distorted by a 
> mention of a project aiming to remove telemetry code from VS Code, 
> however even that code is actually free, not to mention that privacy is 
> completely distinct issue.

Note that not all Emacs packages are truly free (GPL), which is why we
have MELPA and non-GNU ELPA. Nothing can stop people from creating a
proprietary extension either.

As for Atom and VS Code, we do not refer to them directly, but only to
GPL-licensed Org extensions for Atom and VS Code. In general, we cannot
expect non-GNU software to avoid promoting proprietary software. 

Here is what GNU standards say on this issue:

>> What about chains of links? Following links from nearly any web site
>> can lead eventually to promotion of non-free software; this is
>> inherent in the nature of the web. Here’s how we treat that.
>> 
>> You should not refer to AT’s web site if that recommends AT’s
>> non-free software packages; you should not refer to a page p that
>> links to AT’s site presenting it as a place to get some non-free
>> program, because that part of the page p itself recommends and
>> legitimizes the non-free program.
>> 
>> However, if p contains a link to AT’s web site for some other
>> purpose (such as long-distance telephone service), that is no reason
>> you should not link to p.

When linking to Org extensions for Atom and VS Code, not presenting them
as a place to get non-free software (because Atom and VS Code are not
non-free themselves). Non-free extension are a deeper level of the link
chain. I interpret GNU Standards statement as allowing second-level
links to non-free software.

In contrast, Org extension for Sublime requires installing non-free
Sublime editor to work. I see it against GNU standards.

Note that I do not fully agree with how strict are GNU standards exactly
because of the discoverability issues you mentioned. But I do not feel
that we should ignore GNU standards in Org without getting approval from
RMS or GNU. Certainly not when Bastien (the maintainer) decided to
follow GNU standards more strictly.

Best,
Ihor

Re: Inconsistent handling of multi-line properties

[Ihor Radchenko]

Hanno Perrey  writes:

> Hej,
>
> I have noticed that properties that stretch over multiple lines using 
> the :value+: syntax are ignored by org-element-property and therefore 
> also by e.g. org-export-get-node-property when exporting to ics via 
> ox-icalendar.el (see example below). I was wondering now whether this is 
> intentional and to be expected or a bug?
>
> * heading with multi-line property
> :PROPERTIES:
> :LOCATION: Someplace
> :LOCATION+: Some Street 5
> :LOCATION+: 12345 Small Town
> :END:

Confirmed.

I am not sure if this should be fixed on org-export-get-node-property
level. Icalendar may want to concatenate the multi-line property
specially. The usual Org approach is merging such properties into a
single line.

I can see multiple solutions:
1. Change Org's behaviour globally and make org-element-property return
   a list for multi-line properties. This will likely break things, but
   I would be in favour, unless Nicolas disagrees.
2. Change org-export-get-node-property to behave like org-entry-get and
   concatenate multi-line properties into a single line
3. Change ox-icalendar to consider :LOCATION+ properties and merge them
   during export.

Best,
Ihor