Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

[Tom Gillespie]

Ignore the previous message. I see that this was about matching
tags not about specifying them. Best,
Tom

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

[Tom Gillespie]

Without wading too far into this, why do we need escape syntax for this?
The only character that might need an escape would be colon :, but
my reading of the syntax doc is that colo : will immediately terminate
the property, so we would update the doc to make it clear that property
names cannot contain a colon. As written, if there is an issue with the
minus sign in property names then that is a bug, but I feel like I might
be missing something?

Tom

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [BUG] URI handling is overly complicated and nonstandard [9.6.7 (N/A @ /gnu/store/mg7223g8mw90lccp6mm5g6f3

[Tom Gillespie]

This is a timely discussion. I have been thinking about how
to deal with prefixes defined by the #+link: keyword which is
directly related to this question.

I think the following might be a solution that also avoids the
issue brought up by Arne.

The original "bug" cannot be resolved because bare URIs
have syntax that conflicts with Org syntax. However I think
we can do better than directing users to org-link-set-parameters.

My suggestion is as follows. Schemes/prefixes defined by the
#+link: keyword can be used without surrounding syntax markers
but may not contain spaces etc. To support this Org parsers
should always parse prefix:suffix as a _putative_ link which
must then be checked against a list of known schemes that
are either built in or have been declared by the user to indeed
be legitimate schemes.

In the tel: case, the way to solve the original bug is simply
to add the line #+link: tel tel: which would tell Org that e.g.
tel:555-555- is a real uri, and that it should expand to
itself.

At the same time this solution would avoid Arne's issue
(which I also have in some of my documents where I have
use fig: and tbl: as prefixes in names and reference them
via [[fig:figure-name]]) because the parser would only treat
prefix: in an internal link as a scheme if it is defined explicitly
by the user in a #+link: keyword or in their init.el.

Thoughts?
Tom

Re: [BUG] Consider replacing bachload with batch in ob-maxima. [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)]

[Leo Butler]

On Fri, Sep 01 2023, Lockywolf  wrote:

> Dear org developers,
>
> At the moment, ob-maxima has a straightforward way of evaluating
> babel blocks,
>
> #+begin_src shell
> maxima --very-quiet -r batchload\(\"/tmp/ob-maximaFOOBAR.mac\"\)\$
> #+end_src
>
> (line 87 of ob-maxima.el),
>
> I suggest replacing batchload with batch(), and changing line 73 from
> "gnuplot_close ()$" to"gnuplot_close ()$ \nquit();"
>
> The difference between "batch" and "batchload" is that "batch" can
> process :lisp expressions in addition to maxima's own, and it prints
> input/output labels. However, it is possible to customise label printing
> from maxima's own code, and being able to evaluate :lisp just seems
> uncontrovercially good.
>
> It might be that I am missing something, but batch seems a better fit
> for Org-Babel.

Hello,

I think that your request may be handled by one of two improvements:

1. Implement session support in ob-maxima.el; and
2. Many of the design decisions in the existing ob-maxima code should be
customizable.

I am attaching a patch to address 2. Please try it out, I think that it
will satisfy your requests. Feedback is welcome.

---

This old thread may also be relevant:
https://list.orgmode.org/87o7q5rw62@t14.reltub.ca/

Best,
Leo


diff --git a/lisp/ob-maxima.el b/lisp/ob-maxima.el
index d1d7c7424..848811628 100644
--- a/lisp/ob-maxima.el
+++ b/lisp/ob-maxima.el
@@ -48,6 +48,33 @@
   :group 'org-babel
   :type 'string)
 
+(defcustom org-babel-maxima-command-arguments
+  "--very-quiet"
+  "Command-line arguments used when calling the Maxima executable. See `org-babel-maxima-batch/load' and `org-babel-execute:maxima'."
+  :group 'org-babel
+  :type 'string)
+
+(defcustom org-babel-maxima-batch/load
+  "batchload"
+  "The Maxima function used to read and execute Maxima code: `batchload' and `batch' are two alternatives, although a user-defined Maxima function may also be used. See `org-babel-execute:maxima'."
+  :options '("batchload" "batch")
+  :group 'org-babel
+  :type 'string)
+
+(defcustom org-babel-maxima-graphic-file-format-string
+  "(set_plot_option ('[gnuplot_term, png]), set_plot_option ('[gnuplot_out_file, %S]))$"
+  "A string with the Maxima code to set the graphic file terminal and name. It must contain `%S' to set the filename. See `org-babel-maxima-expand'."
+  :options '("(set_plot_option ('[gnuplot_term, png]), set_plot_option ('[gnuplot_out_file, %S]))$" "(load(draw), set_draw_option(terminal='pngcairo,file_name=%S))$")
+  :group 'org-babel
+  :type 'string)
+
+
+(defcustom org-babel-maxima-default-epilogue
+  "gnuplot_close ()$"
+  "A string with the final Maxima code executed. See `org-babel-maxima-expand'."
+  :group 'org-babel
+  :type 'string)
+
 (defun org-babel-maxima-expand (body params)
   "Expand a block of Maxima code according to its header arguments."
   (let ((vars (org-babel--get-vars params))
@@ -60,9 +87,7 @@
 		;; graphic output
 		(let ((graphic-file (ignore-errors (org-babel-graphical-output-file params
 		  (if graphic-file
-		  (format
-		   "set_plot_option ([gnuplot_term, png]); set_plot_option ([gnuplot_out_file, %S]);"
-		   graphic-file)
+		  (format org-babel-maxima-graphic-file-format-string graphic-file)
 		""))
 		;; variables
 		(mapconcat 'org-babel-maxima-var-to-maxima vars "\n")
@@ -70,7 +95,7 @@
 		body
 		;; Any code from the specified epilogue at the end.
 		epilogue
-		"gnuplot_close ()$")
+		org-babel-maxima-default-epilogue)
 	   "\n")))
 
 (defun org-babel-execute:maxima (body params)
@@ -81,10 +106,11 @@ This function is called by `org-babel-execute-src-block'."
 	(result
 	 (let* ((cmdline (or (cdr (assq :cmdline params)) ""))
 		(in-file (org-babel-temp-file "maxima-" ".max"))
-		(cmd (format "%s --very-quiet -r %s %s"
+		(cmd (format "%s %s -r %s %s"
 			 org-babel-maxima-command
+ org-babel-maxima-command-arguments
  (shell-quote-argument
-  (format "batchload(%S)$" in-file))
+  (format "%s(%S)$" org-babel-maxima-batch/load in-file))
  cmdline)))
 	   (with-temp-file in-file (insert (org-babel-maxima-expand body params)))
 	   (message cmd)

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

[Jens Schmidt]

On 2023-08-27  09:43, Ihor Radchenko wrote:
> Samuel Loury  writes:
> 
>> IMHO, "-tag&-todo=TODO" is totally ok. I even imagine we could say that
>> & and | are forbidden to say anything else than AND and OR and people
>> would be ok with that.
> 
> Actually, explicit & or | might be an easier way to not worry about
> escaping things. Except escaping & or | themselves.
> It might be the preferred way to put into the manual.
> 
>> IOW, I wonder of the time and effort to deal with optional & is worth
>> it. WDYT?
> 
> We cannot remove the optionality of &, because doing so will break
> existing user setups. But we can certainly change our recommendations in
> the manual.
> 
> Though pure tag matcher makes more sense with implicit &:
>  +tag1-tag2+tag3... vs +tag1&-tag2&+tag3
> Especially in the interactive agenda filters.

I feel it's a bit hard to reply to this message in the right places, so
I'll do a plain bottom post, sorry.

TL;DR:

- I think we cannot make "&" mandatory because of backward compatibility.

- Even if we made "&" mandatory, it would not really solve the quoting
  problem, since the parser is rather hacky and other quoting and
  context issues would still be there.

- But then I cannot see any real reason why we should recommend using
  "&" in the manual.

- Finally, we should hope for and work towards a "real parser", as Ihor
  has mentioned already in a previous post:

  (beginning of thread)
  
https://list.orgmode.org/orgmode/9132e58f-d89e-f7df-bbe4-43d53a236...@vodafonemail.de/
  (mentioning of peg)
  https://list.orgmode.org/orgmode/87wmyendr7.fsf@localhost/

Details, as far as still required:

The whole tag/property query parser seems to have a long tradition.  For
example, there is still that TODO-state special case that allows for
queries like this (example ripped from the manual):

  work/WAITING
 Same as work+TODO​="WAITING"

So people *have* been worrying about a) query brevity and b) backward
compatibility, and I think we should do so as well.

Then the current parser is horribly ad-hoc-ish and, as a plain
regexp-based parser, context insensitive.  For example, a tag regexp
match

  {regexp}

is matched simply as

  {[^}]+}

that is, you have no chance whatsoever to quote the closing curly
parenthesis.  Likewise for double-quoted strings.

In other words, even if we make | or & mandatory, there will still
remain a lot of ambiguities stemming from the rest of the parser.  And
I'm too lazy to think about how we could quote & in that whole picture.
(| is sort of handled already, but again in a completely
context-insensitive way.)

This all calls for a proper parser, based on peg or bovine or whatever.
Hopefully that parser would still keep backward compatibility, but
that's probably wishful thinking.

[BUG] Consider replacing bachload with batch in ob-maxima. [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)]

[Lockywolf]

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.


Dear org developers,

At the moment, ob-maxima has a straightforward way of evaluating
babel blocks,

#+begin_src shell
maxima --very-quiet -r batchload\(\"/tmp/ob-maximaFOOBAR.mac\"\)\$
#+end_src
(line 87 of ob-maxima.el),

I suggest replacing batchload with batch(), and changing line 73 from
"gnuplot_close ()$" to  "gnuplot_close ()$ \nquit();"

The difference between "batch" and "batchload" is that "batch" can
process :lisp expressions in addition to maxima's own, and it prints
input/output labels. However, it is possible to customise label printing
from maxima's own code, and being able to evaluate :lisp just seems
uncontrovercially good.

It might be that I am missing something, but batch seems a better fit
for Org-Babel.

Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-slackware-linux-gnu, GTK+ Version 
3.24.31, cairo version 1.16.0)
 of 2023-07-31
Package: Org mode version 9.6.6 (release_9.6.6 @ 
/usr/share/emacs/30.0.50/lisp/org/)
-- 
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)

Re: TMiO (was: "Re: Monthy emacs-devel digest, similar to "This month in Org")

[Timothy]

Hi Ihor,

> This is actually quite an effort. AFAIK, the author had difficulties
> allocating time to write more posts for TMiO.
>
> Also, for reference, we are talking about
> 

Each post took several hours to do, despite how short they were. The major
difficulty is in making sure that I’ve read as much as I can in that month, and
trying to feel like I’ve treated most contributions “fairly” (i.e. not missing
people out) which requires looking at the ML + git log since the last TMiO.

For what it’s worth, once the org-latex-preview branch gets merged, I plan on
doing another TMiO with the disclaimer that I may have missed out a bunch of
things in that edition.

Something else we could do is have some sort of “community draft” as is now
being done on the Julia discourse, which could help reduce the individual
workload (ref: 
).

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [BUG] URI handling is overly complicated and nonstandard [9.6.7 (N/A @ /gnu/store/mg7223g8mw90lccp6mm5g6f3

[Dr. Arne Babenhauserheide]

Ihor Radchenko  writes:

> "Dr. Arne Babenhauserheide"  writes:
>
>>> Any thoughts?
>>
>> Thinking about the effort I’d have to fix all internal links in all
>> org-documents I have (dozens of large ones and hundreds of small ones) I
>> don’t like the idea of breaking internal link syntax.
>
> May you elaborate about what is going to be broken?

I have many links where I use <> along with
[[sec:spielbeispiel]], often along with
@@latex:\phantomsection\label{sec:spielbeispiel}@@ to enable reliable
inline linking inside org-mode and across different export formats.

If I understood the proposal right, all of these would break. Or did I
misundestand that?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link?

[Jens Lechtenboerger]

On 2023-09-01, Ihor Radchenko wrote:

> In theory, we might change the parser to treat anything like foo:bar or
>  or [[foo:bar]] as a link with "foo" protocol and "bar" URI.
> And introduce [[::fig:something]] to allow explicit internal links.
> But, despite simplifying the parser, it will certainly be a breaking
> change.

What would the implications be?  FAQ 18.25 [1] contains a recipe to
use colors on text like this: [[color:red][red]]

Would that be a problem?

Also, I use custom link types for additional markup like this:

[[basic:https://en.wikipedia.org/wiki/Cache_(computing)][Caching]]

In both cases, the part before the first colon is certainly no
protocol.

Besides, concerning wording in this discussion: A URIs may or may
not embed a protocol.  It contains a scheme, then a colon, then a
scheme-specific part, see [2].

Best wishes
Jens

[1] https://orgmode.org/worg/org-faq.html
[2] https://datatracker.ietf.org/doc/html/rfc3986

Re: [ANN] org-jami-bot

[Ihor Radchenko]

Hanno  writes:

> Thank you for your kind words and for suggesting to add a reference on worg! 
> Putting a package on ELPA is on my bucket list, so why not? ;)
>
> I do not have the paperwork in place yet. I recently changed employment and 
> am under the impression that it should not be a problem though.
>
> I will let you know once that is done!

May I know if you managed to get any progress on this?
If you encounter any difficulties with the paperwork, we can try to help.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Unit-test for Please add support for dlangs packagemanager to ob-C.el

[Ihor Radchenko]

Christian Köstlin  writes:

> Subject: [PATCH 2/2] testing/lisp/test-ob-C.el: Add test for dub support in
>  ob-C.el

Canceled, due to no response.
See 
https://list.orgmode.org/orgmode/CAG741+bUT_Yt3PdLuVpMNH7vo-bb3n1iiynf2Cime1LW=21...@mail.gmail.com/

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Please add support for dlangs packagemanager to ob-C.el - v3

[Ihor Radchenko]

Ihor Radchenko  writes:

>> After adding unit-tests (following in another patchset) I found a bug in my
>> last patch.
>> Sorry for the noise.
>
> Sorry for the very late reply.
>
> If you are still interested, may you please document the new header
> argument in etc/ORG_NEWS and update
> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-C.html page?

Canceled.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH v2] org-faq.org: Inline comments

[Ihor Radchenko]

Max Nikulin  writes:

> On 08/07/2023 16:31, Ihor Radchenko wrote:
 - it is what we use ourselves in WORG sources.
>
>> Max Nikulin writes:
>>> I have not found it in the worg repository. There are enough @@html:@@
>>> with a handful of @@latex:@@.
>> 
>> Yeah, not in WORG.
>> https://orgmode.org/quickstart.html#text-comments
>
> It makes the FAQ entry having no value if your suggestions are taken 
> into account. (I would add a link to annotating that is another sort of 
> comments instead of dropping content further.) So I am giving up and 
> leaving opportunity to propose changes to somebody else.

https://git.sr.ht/~bzg/worg/commit/f598c7ef

> Bing rates quickstart reasonably, but Google avoids it and I have no 
> idea why. Some hypotheses:
> - quickstart uses generic metadata for the whole site, not specific for 
> this page
> -  repeating  has display:none property
> - invalid markup in index.html (a pitfall with affiliated keywords 
> breaking paragraphs) for the link to quickstart:
>
> 
> 
> 
>
> 
>  class="org-svg" title="Start using Org. You'll never stop.">
>
> 
>
> 
> 
>
> I am unsure, but I would expect something like
>
>  >   class="org-svg">

I have no idea here. I wish somebody more familiar with search engine
optimization chimed in.

>>> +#+begin_src org
>>> +The following line may become a patagraph separator.
>>> +@@comment: might give unexpected effect @@
>>> +Put some text before @@comment: a better variant
>>> +@@ and after instread.
>>> +#+end_src
>> 
>> May you please elaborate?
>> If you see inline export block starting a paragraph, it is a bug.
>
> I failed to convince you that it is a general issue, not a LaTeX 
> specific one.
>
> Ihor Radchenko to emacs-orgmode… Re: [BUG] No space after footnote with 
> org-export-with-footnotes set to nil [9.6.1 ( @ 
> /Users/test/.emacs.d/elpa/28.0/develop/org-9.6.1/)] Tue, 14 Mar 2023 
> 12:19:11 +. https://list.orgmode.org/87fsa7o79c.fsf@localhost
>
> try to export to MarkDown. Even for LaTeX the fix is in the development 
> branch only. There are enough users of built-in Org that deserve to be 
> warned.

The linked message was talking about macros. I still think that for
macros specifically it was not a bug - macros may be expanded into
multiple paragraphs, which is perfectly fine. We should not force macro
expansion to ensure a single paragraph.

As for comments, I tend to agree that it is indeed a bug.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [BUG] URI handling is overly complicated and nonstandard [9.6.7 (N/A @ /gnu/store/mg7223g8mw90lccp6mm5g6f3

[Ihor Radchenko]

"Dr. Arne Babenhauserheide"  writes:

>> Any thoughts?
>
> Thinking about the effort I’d have to fix all internal links in all
> org-documents I have (dozens of large ones and hundreds of small ones) I
> don’t like the idea of breaking internal link syntax.

May you elaborate about what is going to be broken?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [BUG] URI handling is overly complicated and nonstandard [9.6.7 (N/A @ /gnu/store/mg7223g8mw90lccp6mm5g6f3

[Dr. Arne Babenhauserheide]

Ihor Radchenko  writes:

> In theory, we might change the parser to treat anything like foo:bar or
>  or [[foo:bar]] as a link with "foo" protocol and "bar" URI.
> And introduce [[::fig:something]] to allow explicit internal links.
> But, despite simplifying the parser, it will certainly be a breaking
> change.
>
> Any thoughts?

Thinking about the effort I’d have to fix all internal links in all
org-documents I have (dozens of large ones and hundreds of small ones) I
don’t like the idea of breaking internal link syntax.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: Unclear where ob-spice.el is being maintained

[Ihor Radchenko]

Bastien Guerry  writes:

>> We may consider tagging a new release.
>
> Yes, please go ahead as you see fit.

I made a minor release, because apparently org-contrib 0.4 supposed to
remove ob-spice.el already:
https://git.sr.ht/~bzg/org-contrib/commit/c6aef31ccfc7c4418c3b51e98f7c3bd8e255f5e6

https://git.sr.ht/~bzg/org-contrib/commit/dce101b4612e6deef814516779ce216e8eace569

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Fallback fonts in LaTeX export for non latin scripts

[Ihor Radchenko]

Juan Manuel Macías  writes:

> ...In any
> case, the fonts issue is the most delicate part. What default fonts to
> add to the list? Here the user's taste or preferences would influence.

Commonly available libre fonts look like a good candidate.

> It must also be taken into account that if one has typographical
> scruples, not all fonts match each other. For design purposes, I mean.
> The Computer Modern, which is a modern style font (similar to the Didot
> or Bodoni), does not usually pair well with (for example) a Garamond,
> which is in the Renaissance style. That's why I think the best solution
> would be to offer a basic defcustom, based on the purely utilitarian,
> and let the user modify or extend it according to their taste,
> preferences or convenience.

+1.

> Another thing to keep in mind is the following. Offering basic
> readability based on the unicode scripts means that we rely on scripts
> and not languages. For example, the Cyrillic script covers several
> languages, as you well know: Russian, Bulgarian, etc. The Latin script
> is used for languages as diverse as English or Vietnamese. The choice of
> font based on the script is a low-level LuaTeX functionality, that is,
> it does not add features specific to each language, such as hyphenation
> patterns. This means that long texts in (for example) Cyrillic or Greek
> are not justified well because LaTeX does not know how hyphenate them:
> ...
> There is another possibility that I am working on in parallel: relying
> on languages instead of scripts. This would add both readability and
> support for each particular language. There could be two options for the
> user: a basic one (the low level one, based on scripts: ensures
> readability but the document may not look pretty) and an advanced one,
> based on language support. Something like this occurred to me:
>
> #+LaTeX_Header: % !enable-fonts-for ancientgreek russian:Old Standard
>  arabic

We already have #+language keyword and
`org-latex-guess-babel-language'/`org-latex-guess-polyglossia-language'.
May as well have default fonts for a given language.

As for multiple languages, do we actually support this?

>> What will happen if LuaTeX is not installed on the system?
>
> Yes, there should be some kind of warning. Also it's not just LuaTeX,
> but certain packages for fonts and multilingual support. The problem is
> that the different versions of TeX live cooked in the distros 
> usually name these packages differently. This is another added problem...
> Arch or Gentoo offer a more vanilla TeX live.

We might use `org-latex-known-warnings'.

>> Also, just to double check, is LuaTeX fully compatible to LaTeX? That
>> is, if we have an existing org file using LaTeX-specific commands and
>> packages, will it work with LuaTeX?
>
> Yes, it is fully compatible, except that LuaLaTeX does not need to load
> the fontenc or inputenc packages. LuaTeX is intended to be the natural
> replacement for pdfTeX. The latest edition of The LaTeX Companion is
> already very focused on LuaTeX. And 90% of the new LaTeX packages that
> are uploaded to CTAN only work in LuaLaTeX. One of the essential
> advantages of LuaTeX is that TeX now (finally!) has a simple scripting
> language. With a little Lua you can achieve very low level things in TeX
> that were horribly complicated in 'pure TeX'.

Then, we might even consider LuaTeX as the new default for
`org-latex-compiler'.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [BUG] URI handling is overly complicated and nonstandard [9.6.7 (N/A @ /gnu/store/mg7223g8mw90lccp6mm5g6f3mpjk

[Ihor Radchenko]

Max Nikulin  writes:

> However I do not mind to have an easy way to delegate URI from :export 
> function to the link transcoder of active export backend.

Just make the :export function return nil.

> Current behavior with with treating link paths as fuzzy search targets 
> is a kind of compromise. It allows internal search links to be shorter. 
> One may have e.g. #+name: fig:something code blocks, so not every link 
> looking as having some "scheme:" prefix should be treated as an external 
> URI. As a result link types must be enabled explicitly.

This is exactly the reason why Org recognizes a closed list of link
types and not just "anything looking like protocol:uri".

And I am honestly not a big fan - because of the limitations of Elisp
regexps, there is actually a hard limit on the number of link types we
can support - no more than few hundreds, AFAIR. This is because Elisp
regexps cannot be larger than certain length.

On the other hand, Org also supports "plain" links without brackets and
for such links it does make sense to avoid parsing something like A:B as
a link.

In theory, we might change the parser to treat anything like foo:bar or
 or [[foo:bar]] as a link with "foo" protocol and "bar" URI.
And introduce [[::fig:something]] to allow explicit internal links.
But, despite simplifying the parser, it will certainly be a breaking
change.

Any thoughts?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at