Re: [PATCH] New "project" option for org-link-file-path-type

[Kyle Meyer]

Jack Kamm writes:

> The attached patch adds a "project" option for org-link-file-path-type.
>
> When this is set, links to files under the current project root will be
> relative, while links elsewhere are absolute.

Thanks, that sounds useful.

> It relies on project.el, which appears to have been added in emacs 25. I
> used fboundp to check whether the functionality is available, and to
> silence compiler warnings. I'm not sure if this is the correct way to do
> it.

Functionally I think your current patch would only support Emacs's
unreleased master, unless the user installed a new project.el via ELPA.
More on that below.

> Subject: [PATCH] ol.el: New option "project" for org-link-file-path-type
[...]
> @@ -212,13 +212,17 @@ (defcustom org-link-file-path-type 'adaptive
>  absolute  Absolute path, if possible with ~ for home directory.
>  noabbrev  Absolute path, no abbreviation of home directory.
>  adaptive  Use relative path for files in the current directory and sub-
> -  directories of it.  For other files, use an absolute path."
> +  directories of it.  For other files, use an absolute path.
> +project   Use relative path for files in the current project and sub-
> +  directories of it. For other files, usue an absolute path.

s/usue/use/

> +  If project.el is not available, behave as adaptive."
>:group 'org-link
>:type '(choice
> (const relative)
> (const absolute)
> (const noabbrev)
> -   (const adaptive))
> +   (const adaptive)
> +   (const project))
>:safe #'symbolp)

The :package-version keyword should be added to signal the change in
value.

>  (defcustom org-link-abbrev-alist nil
> @@ -1876,6 +1880,15 @@ (defun org-insert-link ( complete-file 
> link-location description)
>   (setq path (expand-file-name path)))
>  ((eq org-link-file-path-type 'relative)
>   (setq path (file-relative-name path)))
> +((and (fboundp 'project-current)
> +  (fboundp 'project-root)
> +  (project-current)
> +  (eq org-link-file-path-type 'project))

Minor: the org-link-file-path-type check would be better positioned at
the top, or at least before the project-current call, to avoid
needlessly finding the project when the option is at its default value
of adaptive.

Also, I think it'd be good to let-bind the project-current result to
avoid a repeated call.

> + (if (string-prefix-p (expand-file-name (project-root
> + (project-current)))
> +  (expand-file-name path))

It looks like project-root isn't available until 5044c19001 (project.el:
A project has only one main root now, 2020-05-23), which isn't yet part
of an Emacs release.  Before that, it'd be (car (project-roots ...), I
think.  Do you think it's worth adding a compatibility kludge here?

As a projectile user, I'm tempted to suggest that, instead of the adding
the `project' value, org-insert-link could learn to call
org-link-file-path-type if it is a function and, if that returns
non-nil, do the prefix check.  Then projectile users could set it to
projectile-project-root.  It seems project.el doesn't have a similar
function that could be called without any arguments, but I guess we
could add a simple ol- wrapper.  I'm not sure that's a good idea,
though.

> + (setq path (file-relative-name path))
> +   (setq path (abbreviate-file-name (expand-file-name path)

A cosmetic preference that you can take or leave: the condition can be
moved inside the setq form:

  (setq path (if ...))

And another: let-binding (expand-file-name path) would avoid a repeating
the expand-file-name in the abbreviate-file-name case.

Re: Thoughts on the standardization of Org

[Ken Mankoff]

To all who argue that Org is too tightly coupled to Emacs to consider working 
with it outside of Emacs, I point to GitHub. The fact that GitHub natively 
renders Org files "well enough" is a huge benefit to those of us who use Org. 
It is also useful for gaining new users (assuming more users is a good thing).

Therefore, if other tools have the ability to do *something* with an Org file 
(display most of it well enough, allow editing without breaking things, maybe 
implementing a simple Babel interpreter for a few popular languages, whatever), 
this would be A Good Thing.

For example, I'd contribute more to Stack Exchange sites if I could answer 
using Org syntax rather than Markdown syntax. None of these 3rd party 
implementations need to be comprehensive or perfect, just as the GitHub 
renderer is neither complete nor perfect. But we all benefit from the GitHub 
rendering.

  -k.

Re: Org mode fontification error in # in python and ipython source blocks

[Sebastian Gimeno]

Hi Jack,

I have cloned the git master. Running without configuration ("make
vanilla"), emacs correctly fontifies the source block and it also gets
exported to HTML. It seems that it is a configuration problem. Sorry for
not double checking first!

Many thanks for your help!

Cheers,
Sebastian


On Mon, Nov 2, 2020 at 12:43 AM Sebastian Gimeno 
wrote:

> Hi Jack,
>
> thanks for replying!
>
> The error does not happen using "emacs -q" (built-in package: org 9.3). I
> haven't tried with the git version yet. i will and let you know.
>
> Cheers,
> Sebastian
>
> On Sun, Nov 1, 2020 at 9:19 PM Jack Kamm  wrote:
>
>> Hi Sebastian --
>>
>> > I am having problems with the fontification of python and ipython source
>> > blocks when the code contains curly brackets "{}" (other course blocks
>> are
>> > ok). For instance, the following snippet
>> >
>> > #+BEGIN_SRC python :results drawer
>> > import matplotlib.pyplot as plt
>> > plt.plot([1,2,3])
>> > plt.show()
>> > a=1
>> > print("a={}".format{a})
>> > #+END_SRC
>> >
>> > does not fontify correctly in either python or ipython source blocks.
>> >
>> > As a consequence, when exporting the org file to HTML (C-c C-e h h), it
>> > fails with the following message:
>> >
>> > font-lock-fontify-keywords-region: Invalid function: #
>>
>> I'm unable to reproduce this behavior on emacs 27.1 and git
>> master. Fontification and export work fine with this code block for me.
>>
>> Does the error still happen when you use emacs -q ? Or if you use git
>> master?
>>
>> Jack
>>
>>

Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

[吴锐扬]

Can confirm that. Thanks for your work!

Best,
Ruiyang

> On Nov 1, 2020, at 4:44 PM, Kyle Meyer  wrote:
> 
> Kyle Meyer writes:
> 
>> It looks like the query went away with dbb375fdf (Simplify Babel calls
>> evaluation, 2016-06-16), which was included in the 9.0 release.  Based
>> on a quick glance at that commit, I don't think that was an intentional
>> change.
>> 
>> I won't take a closer look at this until at least this weekend, though.
>> I'd be very happy if someone beat me to it.
> 
> Should be fixed by 20374f69e.  That includes a regression test that will
> hopefully prevent an unintended change in either direction (no prompting
> or repeat prompting).

Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

[Kyle Meyer]

Kyle Meyer writes:

> It looks like the query went away with dbb375fdf (Simplify Babel calls
> evaluation, 2016-06-16), which was included in the 9.0 release.  Based
> on a quick glance at that commit, I don't think that was an intentional
> change.
>
> I won't take a closer look at this until at least this weekend, though.
> I'd be very happy if someone beat me to it.

Should be fixed by 20374f69e.  That includes a regression test that will
hopefully prevent an unintended change in either direction (no prompting
or repeat prompting).

Re: Org mode fontification error in # in python and ipython source blocks

[Sebastian Gimeno]

Hi Jack,

thanks for replying!

The error does not happen using "emacs -q" (built-in package: org 9.3). I
haven't tried with the git version yet. i will and let you know.

Cheers,
Sebastian

On Sun, Nov 1, 2020 at 9:19 PM Jack Kamm  wrote:

> Hi Sebastian --
>
> > I am having problems with the fontification of python and ipython source
> > blocks when the code contains curly brackets "{}" (other course blocks
> are
> > ok). For instance, the following snippet
> >
> > #+BEGIN_SRC python :results drawer
> > import matplotlib.pyplot as plt
> > plt.plot([1,2,3])
> > plt.show()
> > a=1
> > print("a={}".format{a})
> > #+END_SRC
> >
> > does not fontify correctly in either python or ipython source blocks.
> >
> > As a consequence, when exporting the org file to HTML (C-c C-e h h), it
> > fails with the following message:
> >
> > font-lock-fontify-keywords-region: Invalid function: #
>
> I'm unable to reproduce this behavior on emacs 27.1 and git
> master. Fontification and export work fine with this code block for me.
>
> Does the error still happen when you use emacs -q ? Or if you use git
> master?
>
> Jack
>
>

Re: Thoughts on the standardization of Org

[Dr. Arne Babenhauserheide]

Daniele Nicolodi  writes:
> Maybe the standardization should cover only the "static" parts of Org
> (ie no table formulas, no babel, no agenda, no exporters, etc). However,
> in this case, what is left is little more of a markup language with an
> editor that allows sections folding. You can have this on top of pretty
> much any markup language using Emacs' outline-minor-mode.

It could become stronger competition for asciidoc by being available in
more places.

Having an acceptance criterion for “supports basic org-mode
presentation” and “can edit org-files without breaking editing in
org-mode” could help adoption.

That would be the only part I’d really expect from standardization:
There would be a clear-cut point when a tool could claim compatibility
with org level N or by components (i.e. basic presentation, code-blocks,
…).

Having org-files parsed as html on a VCS-infopage is pretty nice.

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


signature.asc
Description: PGP signature

Re: Org mode fontification error in # in python and ipython source blocks

[Jack Kamm]

Hi Sebastian --

> I am having problems with the fontification of python and ipython source
> blocks when the code contains curly brackets "{}" (other course blocks are
> ok). For instance, the following snippet
>
> #+BEGIN_SRC python :results drawer
> import matplotlib.pyplot as plt
> plt.plot([1,2,3])
> plt.show()
> a=1
> print("a={}".format{a})
> #+END_SRC
>
> does not fontify correctly in either python or ipython source blocks.
>
> As a consequence, when exporting the org file to HTML (C-c C-e h h), it
> fails with the following message:
>
> font-lock-fontify-keywords-region: Invalid function: #

I'm unable to reproduce this behavior on emacs 27.1 and git
master. Fontification and export work fine with this code block for me.

Does the error still happen when you use emacs -q ? Or if you use git
master?

Jack

Re: Thoughts on the standardization of Org

[Daniele Nicolodi]

On 01/11/2020 17:13, Russell Adams wrote:
> On Sat, Oct 31, 2020 at 08:22:01PM -0400, Asa Zeren wrote:
>> First, I would like to repeat the importance of developing standards
>> for org-mode. If we want to expand the influence of org, tooling must
>> expand beyond Emacs.
> 
> I disagree. There are other open text based formats outside of
> Emacs. That Org is so compelling is because it's tightly integrated
> into an Emacs mode which makes using Org data so easy.

I cannot agree more with this statement and a similar statement (that I
am too lazy to go search to provide correct authorship) that stated that
one of the advantages of Org is that, being implemented in Emacs, it has
infinite potential for customization, thus we would need to agree about
what org mode is before standardizing it: my Org is not your org, and,
thank to the features offered be the Emacs environment, I use different
flavors of Org in different buffers.

Reading the thread I have the impression that what wants to be
standardized is the syntax of Org, but that is not very different from
the syntax of other text based markup languages such at
reStructuredText, asciidoc, Markdown, or others. What makes Org stand
out, for some applications, is "org-mode" (as the implementation of Org
in Emacs) and the tools built on top of the syntax.

I don't think it is reasonable to expect much of org-mode being
implemented in another environment, because that quickly becomes a task
as complex as implementing Emacs. For example, Org has org-tables, and
the formula syntax allows for Emacs Calc expressions or Elisp functions
to be called: should an hypothetical implementation of Org allow the
same formulas to be executed? Wouldn't that mean that this
implementation needs to re-implement a good fraction of Emacs (or use
Emacs itself for interpreting the formulas?

Maybe the standardization should cover only the "static" parts of Org
(ie no table formulas, no babel, no agenda, no exporters, etc). However,
in this case, what is left is little more of a markup language with an
editor that allows sections folding. You can have this on top of pretty
much any markup language using Emacs' outline-minor-mode.

If this is what you are after, I think a much more interesting goal
(from the point of view of Emacs users and Org developers) would be to
fold back some of the improvements org-mode builds on top of
outline-mode back into outline-mode itself. This would immediately be
beneficial as it would probably make Org simpler and the improvements
could be actually be used by many.

I also think that, if you are in the position to choose a format to use
for collaborative projects, reStructuredText may be a better choice as
the syntax is simple, well defined, and extensible. Although, without
trying I don't know if outline-minor-mode can be made to work with
reST-style sections headers. But, if it does not, it should not be hard
to adjust it (see previous paragraph).

Cheers,
Dan

Re: Bug: HTML not formatted correctly from R source code block [9.3.6 (9.3.6-23-g01ee25-elpaplus @ /home/opdfa/.emacs.d/elpa/org-plus-contrib-20200309/)]

[Jack Kamm]

Hi Steven,

Sorry for the delayed response.

> The problem, however, is that what is exported to html and displayed in the
> exported block is either the actual UUID or the tempfile path and not the
> results from evaluating the R code. In the case of the tempfile, the tempfile
> exists but is empty.

Yes, async doesn't work well with export. I think it would be very
challenging to make it work correctly.

For my recent patch to add this functionality into org-mode [0], my
workaround was to simply disable async evaluation during export.

[0] https://orgmode.org/list/87h7qi2l2m@gmail.com/

Re: Thoughts on the standardization of Org

[Asa Zeren]

Dr. Arne Babenhauserheide  wrote:

> Why should this be in a separate document? The obvious place for a
> standard is worg, and the way forward is to improve what’s there.

It does not necessarily need to be in a separate file, and if it is it should be
in worg or another communally owned place, and could just be another top level
heading. What I really mean, however, is that the three parts I outline should
be logically separate entities.

Re: Thoughts on the standardization of Org

[Asa Zeren]

Hi all,

Thank you for your comments on my post "Thoughts on the Standardization of Org."
I appreciate all the feedback you have given me, I feel that, based off of the
responses, there have been a number of miscommunications as to my intention.

First, I did not mean the post to be primarily an argument for whether/when org
should be standardized, but rather a discussion on how a standard should be
structured. I realize now that including my position on whether org should be
standardized in the preamble was a mistake. Also, I want to note that I was not
intending to discuss by whom the standard should be governed. (Though I do
believe it should be by the org community, not an external standards body.)

Second, there is the matter of principle and practice. I am not arguing for the
org community to direct volunteer effort to a second editing environment, as
some are concerned. I am also personally not planning on creating one. However,
I want to make sure that standardization effort does not prevent another
first-class editing environment from being created, should there at some point
in the future emerge a group of people motivated to do that. In summary, I think
that it is important to think about the Emacs implementation as one of many /in
principle/, even though it is the sole implementation /in practice/, and may
remain so.

I hope we can have a productive discussion on how an org standard should be
structured, separate from, though perhaps in addition to, the discussion of
whether org should be standardized.

Thanks,
Asa

Re: Reply-All noise

[Anthony Carrico]

On 10/9/20 3:24 PM, c.bu...@posteo.jp wrote:

Do you receive double mails? Doesn't it bother you?


Normally I would agree with you, but there is a very simple explanation 
for this particular list: This mailing list is very high traffic and 
people can't pay attention all the time.


I automatically filter it out of my email and look at it occasionally, 
so I miss most of the discussion, which is fine, except if I submit a 
patch or an issue, etc., and weeks or months later activity moves toward 
my patch/issue/etc. Basically, you need to reply-all to wake people up 
when a topic that interests them comes around.


--
Anthony Carrico

Re: Org-Mode as DSL

[Lejon]

TEC  writes:

>
> Hence, any and all concerns about feature parity etc. are completely
> resolved. One 'just' needs to implement the bindings and piping (as
> opposed to the whole shebang).
>

Something that I am missing when hacking on org-mode is some form of api
reference. Things like 'org-map-entries' or 'org-agenda-get-deadlines'
can be very useful for when you want to extend org's functionality, or
use org's functionality in a different way, but can be hard to find.

In order to implement this "Emacs as org-mode lsp server" idea I think org
would need a stable (for some measure of stable) api, which I think
would benefit org anyways. I think it would be a good idea at least to
put some some effort into gathering the useful functions and put that
list somewhere in the manual for example.

Regards,

Lejon

Org mode fontification error in # in python and ipython source blocks

[Sebastian Gimeno]

Hi,

I am using emacs 27.1 and org-plus-contrib 20201026.

I am having problems with the fontification of python and ipython source
blocks when the code contains curly brackets "{}" (other course blocks are
ok). For instance, the following snippet

#+BEGIN_SRC python :results drawer
import matplotlib.pyplot as plt
plt.plot([1,2,3])
plt.show()
a=1
print("a={}".format{a})
#+END_SRC

does not fontify correctly in either python or ipython source blocks.

As a consequence, when exporting the org file to HTML (C-c C-e h h), it
fails with the following message:

font-lock-fontify-keywords-region: Invalid function: #

If changing the code snippet to:

#+BEGIN_SRC python :results drawer
import matplotlib.pyplot as plt
plt.plot([1,2,3])
plt.show()
a=1
print("a=%s" % a)
#+END_SRC

the block fontifies and the file is exported to HTML correctly.

Can you reproduce this behaviour?

Many thanks in advance!

Re: Default fold state of property drawers?

[Kyle Meyer]

Gustav Wikström writes:

> But maybe my issue rather lies in how the visibility toggling with
> S-TAB functions. The file property drawer is open in OVERVIEW and
> CONTENT but hidden in SHOW ALL. My intuition says that the
> file-property drawer should be closed for all toggle-states. Thoughts?

I agree.  While I've never used file-level property drawers, my
expectation would be for them to behave in the same way a heading's
would.

FWIW when you introduced file-level property drawers in 1bdff9f73 (Org
document property-drawers, 2019-05-26), it looks like cycling wasn't
considered and S-TAB would just ignore these drawers, preserving their
current state.

The cycling behavior you described above appears to come with 1aa095ccf
(Fix drawer invisibility, 2020-06-06).  I think that was in response to
.  While I
haven't taken a close look, my guess is that the effect on file-level
property drawers was unintended, and that improvements here would be
welcomed.

Re: Thoughts on the standardization of Org

[Jack Kamm]

Hi Timothy,

TEC  writes:

> I feel that this also ties into my earlier idea of putting Emacs
> as/inside an LSP server for Org.  I suspect there may be a a lot 
> of
> potential in making it dead easy to use Emacs as a tool.

I'm too busy to help on this, but I think it's a very good idea and hope
you can pursue it.

In terms of making org-mode more accessible outside emacs, there are 2
main benefits I'd personally be excited about:

1. Being able to collaborate on org-babel computational notebooks with
non-emacs users.
2. Improved mobile apps for org-mode.

Jack

Re: Thoughts on the standardization of Org

[TEC]

Dr. Arne Babenhauserheide  writes:


Asa Zeren  writes:
Also another note is that the worg syntax document does begin 
to specify

this. My point is to bring this out into a separate document.


Why should this be in a separate document? The obvious place for 
a
standard is worg, and the way forward is to improve what’s 
there.


I'll try to avoid interpreting others words for them :P but my 
take is
that it while documents like the worg syntax document are 
fantastic, we
may want to add a bit more into a single more comprehensive 
document.


I have a suggestion in this regard. #+include

Why not have the best of both worlds :P

--
Timothy

Re: Thoughts on the standardization of Org

[Dr. Arne Babenhauserheide]

Asa Zeren  writes:
> Also another note is that the worg syntax document does begin to specify
> this. My point is to bring this out into a separate document.

Why should this be in a separate document? The obvious place for a
standard is worg, and the way forward is to improve what’s there.

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


signature.asc
Description: PGP signature

[PATCH] ox.el: Add missing polish translations in export dictionary

[General discussions about Org-mode.]

Hi All,

This patch is just a quick addition to export dictionary for polish language. 
Things which were translated:

- Continued from previous page -> Ciąg dalszy poprzedniej strony
- Continued on next page-> Kontynuacja na następnej stronie

Let me know if it's ok.

Karol Wójcik>From 0e3f6184ccf034902f66ea7d73eb82e372cfe7ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Karol=20W=C3=B3jcik?= 
Date: Sun, 1 Nov 2020 17:41:50 +0100
Subject: [PATCH] ox.el: Add missing polish translations in export dictionary
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

TINYCHANGE

Signed-off-by: Karol Wójcik 
---
 lisp/ox.el | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lisp/ox.el b/lisp/ox.el
index 5ffd66816..79ccfde32 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -5757,6 +5757,7 @@ them."
  ("it" :default "Continua da pagina precedente")
  ("ja" :default "前ページからの続き")
  ("nl" :default "Vervolg van vorige pagina")
+ ("pl" :default "Ciąg dalszy poprzedniej strony")
  ("pt" :default "Continuação da página anterior")
  ("pt_BR" :html "Continuao da pgina anterior" :ascii "Continuacao da pagina anterior" :default "Continuação da página anterior")
  ("ro" :default "Continuare de pe pagina precedentă")
@@ -5772,6 +5773,7 @@ them."
  ("it" :default "Continua alla pagina successiva")
  ("ja" :default "次ページに続く")
  ("nl" :default "Vervolg op volgende pagina")
+ ("pl" :default "Kontynuacja na następnej stronie")
  ("pt" :default "Continua na página seguinte")
  ("pt_BR" :html "Continua na prxima pgina" :ascii "Continua na proxima pagina" :default "Continua na próxima página")
  ("ro" :default "Continuare pe pagina următoare")

base-commit: 2b3bbf361813ee9082d17dc86a77a8b8b87848af
-- 
2.26.2

Re: Thoughts on the standardization of Org

[Russell Adams]

On Sat, Oct 31, 2020 at 08:22:01PM -0400, Asa Zeren wrote:
> First, I would like to repeat the importance of developing standards
> for org-mode. If we want to expand the influence of org, tooling must
> expand beyond Emacs.

I disagree. There are other open text based formats outside of
Emacs. That Org is so compelling is because it's tightly integrated
into an Emacs mode which makes using Org data so easy.

Like many open source projects no one is paid to work on and develop
Org. Despite the best volunteer efforts, Org has burnt out many
volunteer maintainers along the way. To ask for more of Org outside of
Emacs when the main Org project inside Emacs is understaffed seems a
backward notion to me.

> While Emacs is an amazing tool, (a) we cannot convince the entire
> world to use Emacs

We also cannot expect our maintainers to spend their time on the world
outside of Emacs.

> (b) org-mode should be integrated into tooling unrelated to text
> editing, and is outside of the Emacs-Lisp environment.

Isn't that the opposite goal? Org mode is all about your data being
text only and easy to edit inside Emacs, so why would "unrelated to
text editing and outside Emacs" be of any interest or worth any time?

> Without additional org implementations, this is impossible. If org
> catches on before it is standardized, we end up in the situation of
> Markdown, with many competing standards and non-standards. Hence,
> standardization is essential.

Org has caught on. Org has a reference implementation, which you could
consider the standard parser. Org isn't just the format, it's the
editing experience. That's only realized inside of Emacs.

Could it benefit from better documentation, and finishing up some
rough edges? Of course. That would be an excellent place to spend
volunteer time.

I can't recommend asking for volunteer time on tools outside of Emacs
though.

I've recommended a few times now the idea that if you want to work on
Org data outside of Emacs, use Org to do an export your data into a
machine readable format (xml, json, etc). Don't parse it directly from
text. I believe there are already exporters which can help with that,
and they may be worthy of additional effort.

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Thoughts on the standardization of Org

[Asa Zeren]

Thanks for the comments.

Both of you have raised some very good points, but I think that there has been
some confusion as to a number of my arguments. I hope to clarify some things
below.

On Sun Nov. 1, 2020, at 1:20AM Tom Gillespie wrote:
> My general take is that any active work toward standardization
> would be premature. At the very least a full implementation outside
> of Emacs would need to exist. In the absence of that there is little
> point to standardization. There is ample existing documentation to
> build a compliant parser (pandoc exists as well ...) and any effort
> toward standardization right now would be better spent improving
> the existing implementation or fixing broken ones (e.g. org-ruby).

This could very well be the case. When to create a formal standard is a very
hard question, and there are lots of reasons for it to be too early.

One point I do think needs to be clarified is the extent of a "full
implementation". I don't think that a full editing environment like the one that
exists in Emacs today needs to exist, only a fully functional export
framework. This would require it to understand the full org syntax and
semantics.

Also, part of the reason I wrote my original thoughts is because I observed
some motivation towards standardization, as part of the MIME type effort.

> From your comments, I would suggest reading through
> https://orgmode.org/worg/dev/org-syntax.html if you have not done so
> already. Much of what you mention is already there.

I did give it a read, and I have just given it another read. While I do confess
I did make some terminology mistakes, most of my points still stand after giving
it another read through.

> If something like standardization is still desired, I would suggest that the
> proper framing for any such activities would be as improvement and
> clarification in the documentation, and potentially as formalization of some
> of the existing behaviors of the system. Org is a fairly stable system, and as
> others have said, explicitly leaving things open an unspecified would be
> vital.  There are also parts of org (e.g. babel) where the behavior needs to
> be regularized and made consistent. At the moment those areas need
> contributors, not standardization.

I do agree that this is the right method of creating the standard. Org-mode is a
very large beast to standardize, and it can only be done incrementally, or it is
doomed to fail.

> On Sat, Oct 31, 2020 at 8:22 PM Asa Zeren  wrote:
> > this is impossible. If org catches on before it is standardized, we end up
> > in the situation of Markdown, with many competing standards and
> > non-standards. Hence, standardization is essential.
> The situation for Org is not comparable to markdown. There is a single
> reference implementation for org at the moment. The codebase is massive. There
> are many existing parsers for org files. Many are obviously broken since they
> do not match the reference implementation's behavior. The obviousness is a
> sign that there is not a need for standardization at this time. Further, there
> is little risk that another impl will be created without interoperating with
> the elisp implementation. For example, consider Mauro's use case: being able
> to get colleagues who do not use Emacs to use Org. I suspect most of the
> people who would be working on other implementations would be starting from
> Emacs and would be unlikely to leave. Also unlike markdown, html export is
> just one tiny part of Org, whereas markdown was implemented repeatedly to
> allow text input on web pages where people needed to implement parts of html
> that had not already been specified in markdown.

I agree that this is the current situation. However, there is a real danger
here. People are continually trying to create org implementations (myself
included), and if one of these is successful before an org standard is created,
and it differs from the original elisp implementation in non-trivial to fix
ways, then we have an issue. Perhaps this will not come to pass, and other
implementations should strive for parity, but it is still a danger.

> Standardizing org is much harder than standardizing something like Markdown,
> but I think by breaking it down as follows will maximize the portability of
> org while not compromising on development of org. See some of my other
> recent emails. In the short term this is impossible due to the deep
> dependence on Emacs Lisp. Any outside implementation that is created today
> would have to implement elisp. Few have been able to do this in over 30
> years. Moving beyond elisp requires additional machinery to be added to
> org to be able to specify other top level languages. This is not something
> that is remotely ready for standardization because no one even has a single
> working implementation yet!

I definitely agree that a deep dependence on Emacs Lisp should not be
standardized, and thus there are certain parts of the current org-mode
implementation 

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

[Bastien]

Hi Corwin,

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

All best,

-- 
 Bastien

Re: Thoughts on the standardization of Org

[Gustav Wikström]

Hi,

I agree with your sentiment Asa. It would indeed be good to "standardize" Org. 
It's worth spending a few words here reasoning about what this standardization 
would mean. The text below are not specifically to you, Asa. But to the list. 
As food for thought on this topic. FWIW.

It's easy to be hesitant to standardization, thinking it will slow down and 
limit development. Personally I don't think Org mode is at risk of that. The 
issues come first with coordination between multiple parties. Especially if the 
visions, goals and perspectives of the parties differ. For Org mode this 
coordination should not be an issue, since no one as of now could dispute that 
Emacs Org mode implementation is the standard implementation. Few would also 
dispute which party has the leading role in defining the standard. (I.e. this 
community, with the maintainers as the "signing" bodies, define the standard. 
And it can be done either in the manual or in worg).

Issues with a standard hindering evolution of Emacs Org mode can be dealt with 
in the same way as the evolution of Org mode itself is handled. By versioning. 
Right now the Org mode version effectively declares what the DOM and syntax is. 
If we can extract that information from the source code. And assign a version 
to the DOM and syntax so they can be managed separate from the Emacs 
implementation, it's quite easy to evolve them as well. Although I think the 
syntax will evolve much less than the tool itself, since much of the changes 
aren't about changing the syntax but rather about changing the way Emacs 
augments and works with that syntax!

What it really boils down to, I think, is that there is a benefit of a clear 
document describing what an org mode document can consist of (DOM in your 
terminology I suppose?) and what the textual representation of that is (the 
syntax). Put a version number on that/those things that can be incremented as 
the community see fit. And it's done. Standard is defined.  No third party 
should need to sign it. It would be the "Emacs Org mode" community 
standardization of the Org mode object model and textual syntax and document 
format. And that in itself should be more than enough to get the ".org" file 
extension globally approved. And help parser developers and other tool 
developers to support the format. AND help further develop Emacs 
implementation. Discussions regarding composing these documents are already 
started in the MIME-type threads. In my humble opinion there is not much else 
needed to get this "standardization" done.

Nicolas has started the journey in an excellent way with the Org element 
documentation and source code library in my opinion. Hats off to him! Anyone 
willing of following in his footstep gets another hat off. I'm sure it will be 
of great benefit to all Org mode users out there!

Kind regards
Gustav

> -Ursprungligt meddelande-
> Från: Emacs-orgmode  För Asa
> Zeren
> Skickat: den 1 november 2020 01:22
> Till: emacs-orgmode@gnu.org
> Ämne: Thoughts on the standardization of Org
> 
> Hi,
> 
> Even though I am new to the org-mode community, I would like to share
> some thoughts on the specification of org-mode, especially since I
> have seen some recent discussion of it in relation to registering org
> as a MIME type.
> 
> First, I would like to repeat the importance of developing standards
> for org-mode. If we want to expand the influence of org, tooling must
> expand beyond Emacs. While Emacs is an amazing tool, (a) we cannot
> convince the entire world to use Emacs and (b) org-mode should be
> integrated into tooling unrelated to text editing, and is outside of
> the Emacs-Lisp environment. Without additional org implementations,
> this is impossible. If org catches on before it is standardized, we
> end up in the situation of Markdown, with many competing standards and
> non-standards. Hence, standardization is essential.
> 
> Standardizing org is much harder than standardizing something like
> Markdown, but I think by breaking it down as follows will maximize the
> portability of org while not compromising on development of org.
> 
> I see three areas of standardization, which I think should be
> standardized separately:
>  - Org DOM
>  - Org Syntax
>  - Org Standard Environments
> 
> Before we get to that, a brief note on /how/ I think that org should
> be specified. I think that org should be specified in terms of an
> /environment/ that defines the properties, etc. that can be used in a
> document. For instance, the org standard would say something to the
> effect of "An environment may specify block bounding keywords that may
> be used like #+\n...#+. and the environment would specify
> "begin_src and end_src are a pair of block bounding keyword that
> indicates a source code block." This is for two reasons. First, this
> allows for development of org tool features independent of the
> standard. Second, this separates the individual features of org mode
> from the 

Re: Thoughts on the standardization of Org

[TEC]

I feel that this also ties into my earlier idea of putting Emacs
as/inside an LSP server for Org.  I suspect there may be a a lot 
of

potential in making it dead easy to use Emacs as a tool.

I'm rather busy over the next few weeks, but I'd be happy to 
spearhead a

project in this direction.

Timothy.

Dr. Arne Babenhauserheide  writes:


see discussion on Mauro's thread about
the fact that it is probably just easier to use Emacs directly 
if you

need to export
to a certain format in a specific way. It is free software 
after all.


I would like to add, that this is pretty easy to do, and also to 
make
independent of the users emacs environment. Here is an example 
that
uses the whole orgmode-babel-latex-html machinery to create 
derived
documents from source-of-truth org-mode files which get exported 
to a

book:
https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/Makefile.am?rev=b8e3899c6d8b#L121


chargen.tex: chargen.org $(ewstables_SOURCES) 
kasten-alter-groesse-gewicht.org ews30setup.el
	echo yes > $$(tty); Xvfb :3 -screen 0 1024x768x16 & time 
DISPLAY=:3 HOME=@abs_top_srcdir@ @EMACS@ -l 
"@abs_top_srcdir@/ews30setup.el" --eval '(setq 
vc-follow-symlinks nil)' --eval '(setq org-id-locations-file 
"@abs_top_builddir@/.org-id-locations")' "$<" -e 
org-latex-export-to-latex -e kill-emacs  < $$(tty) >> build.log 
&& rm -f "@abs_top_builddir@/.org-id-locations"


Note how this sets the HOME to the sourcedir (so a 
project-specific

.emacs.d setup is used) and loads ews30setup.el at startup for
additional customization. Also note the call to Xvfb which 
avoids

showing a graphical Emacs during build.


This uses an org-mode file that pulls data from tables in other 
org-mode

files by setting variables for code based on autotools-included
datafiles. Here’s an example of pulling the tables into 
variables:

https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/chargen.org.in?rev=b8e3899c6d8b#L153

#+begin_src scheme :exports none :results output raw :prologue 
"(import (srfi srfi-1)(ice-9 match)(ice-9 receive))(set! 
*random-state*  (random-state-from-platform))\n" :tangle 
chargen.scm :noweb yes :var kernantriebe=tabelle-kernantriebe 
:var hautfarbe=tabelle-hautfarbe :var 
haarfarbe=tabelle-haarfarbe :var augenfarbe=tabelle-augenfarbe 
:var darstellung1=tabelle-darstellung1 :var 
darstellung2=tabelle-darstellung2 :var 
kleidung_oben_maenner=tabelle-kleidung-fantasy-oben-maenner 
:var 
kleidung_unten_maenner=tabelle-kleidung-fantasy-unten-maenner 
:var kleidung_oben_frauen=tabelle-kleidung-fantasy-oben-frauen 
:var kleidung_unten_frauen=tabelle-kleidung-fantasy-unten-frauen 
:var kleidung_oben_frauen=tabelle-kleidung-fantasy-oben-frauen 
:var kleidung_unten_frauen=tabelle-kleidung-fantasy-unten-frauen 
:var namen=tabelle-namen-fantasy-jetzt :var 
sex=tabelle-sexualitaet :var stichwort=tabelle-stichwort-fantasy

  (let ()
{{{chargen-setup}}}
{{{chargen-generic}}}
{{{chargen-colors}}}
{{{chargen-specifics-fantasy}}}
{{{chargen-print-char}}}
(chargen-print-char)
  )
#+end_src


Note the {{{…}}} blocks. Those use literate programming to 
include

blocks defined below, with customized separators:
chargen-setup block: 
https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/chargen.org.in?rev=b8e3899c6d8b#L360
customization of separators: 
https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/chargen.org.in?rev=b8e3899c6d8b#L638

# Local Variables:
# org-confirm-babel-evaluate: nil
# org-export-allow-bind-keywords: t
# org-babel-noweb-wrap-start: "{{{"
# org-babel-noweb-wrap-end: "}}}"
# End:


Here’s how it pulls tables:
https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/chargen.org.in?rev=b8e3899c6d8b#L578
@tabelle_aussehen@


And this is an example of the datafiles that are used as 
source-of-truth

and also directly inluded in the main book as tables:
https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/tabelle-aussehen.org?rev=b8e3899c6d8b#L578

#+tblname: tabelle-hautfarbe
|  | -5 | direkt  | 6  |
|--++-+|
|   -3 | blass  | rosig   | sommersprossig |
|   -1 | grau   | gelblich| elfenbein  |
|2 | kupfer | rotbraun| bronze |
|4 | oliv   | dunkelbraun | schwarz|
| -5/6 | albino | -   | fleckig|


All this machinery can be invoked without ever seeing Emacs.


So yes, the Emacs implementation is the source of truth, and 
yes, this
can be used without requiring people to operate Emacs by simply 
using
Emacs as utility with project-specific setup — just as you would 
do it

with a compiler.


Best wishes,
Arne

Re: Thoughts on the standardization of Org

[Dr. Arne Babenhauserheide]

> see discussion on Mauro's thread about
> the fact that it is probably just easier to use Emacs directly if you
> need to export
> to a certain format in a specific way. It is free software after all.

I would like to add, that this is pretty easy to do, and also to make
independent of the users emacs environment. Here is an example that
uses the whole orgmode-babel-latex-html machinery to create derived
documents from source-of-truth org-mode files which get exported to a
book:
https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/Makefile.am?rev=b8e3899c6d8b#L121


chargen.tex: chargen.org $(ewstables_SOURCES) kasten-alter-groesse-gewicht.org 
ews30setup.el
echo yes > $$(tty); Xvfb :3 -screen 0 1024x768x16 & time DISPLAY=:3 
HOME=@abs_top_srcdir@ @EMACS@ -l "@abs_top_srcdir@/ews30setup.el" --eval '(setq 
vc-follow-symlinks nil)' --eval '(setq org-id-locations-file 
"@abs_top_builddir@/.org-id-locations")' "$<" -e org-latex-export-to-latex -e 
kill-emacs  < $$(tty) >> build.log && rm -f 
"@abs_top_builddir@/.org-id-locations"

Note how this sets the HOME to the sourcedir (so a project-specific
.emacs.d setup is used) and loads ews30setup.el at startup for
additional customization. Also note the call to Xvfb which avoids
showing a graphical Emacs during build.


This uses an org-mode file that pulls data from tables in other org-mode
files by setting variables for code based on autotools-included
datafiles. Here’s an example of pulling the tables into variables:
https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/chargen.org.in?rev=b8e3899c6d8b#L153

#+begin_src scheme :exports none :results output raw :prologue "(import (srfi 
srfi-1)(ice-9 match)(ice-9 receive))(set! *random-state*  
(random-state-from-platform))\n" :tangle chargen.scm :noweb yes :var 
kernantriebe=tabelle-kernantriebe :var hautfarbe=tabelle-hautfarbe :var 
haarfarbe=tabelle-haarfarbe :var augenfarbe=tabelle-augenfarbe :var 
darstellung1=tabelle-darstellung1 :var darstellung2=tabelle-darstellung2 :var 
kleidung_oben_maenner=tabelle-kleidung-fantasy-oben-maenner  :var 
kleidung_unten_maenner=tabelle-kleidung-fantasy-unten-maenner :var 
kleidung_oben_frauen=tabelle-kleidung-fantasy-oben-frauen  :var 
kleidung_unten_frauen=tabelle-kleidung-fantasy-unten-frauen :var 
kleidung_oben_frauen=tabelle-kleidung-fantasy-oben-frauen  :var 
kleidung_unten_frauen=tabelle-kleidung-fantasy-unten-frauen :var 
namen=tabelle-namen-fantasy-jetzt :var sex=tabelle-sexualitaet :var 
stichwort=tabelle-stichwort-fantasy
  (let ()
{{{chargen-setup}}}
{{{chargen-generic}}}
{{{chargen-colors}}}
{{{chargen-specifics-fantasy}}}
{{{chargen-print-char}}}
(chargen-print-char)
  )
#+end_src


Note the {{{…}}} blocks. Those use literate programming to include
blocks defined below, with customized separators:
chargen-setup block: 
https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/chargen.org.in?rev=b8e3899c6d8b#L360
customization of separators: 
https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/chargen.org.in?rev=b8e3899c6d8b#L638
# Local Variables:
# org-confirm-babel-evaluate: nil
# org-export-allow-bind-keywords: t
# org-babel-noweb-wrap-start: "{{{"
# org-babel-noweb-wrap-end: "}}}"
# End:


Here’s how it pulls tables:
https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/chargen.org.in?rev=b8e3899c6d8b#L578
@tabelle_aussehen@


And this is an example of the datafiles that are used as source-of-truth
and also directly inluded in the main book as tables:
https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/tabelle-aussehen.org?rev=b8e3899c6d8b#L578

#+tblname: tabelle-hautfarbe
|  | -5 | direkt  | 6  |
|--++-+|
|   -3 | blass  | rosig   | sommersprossig |
|   -1 | grau   | gelblich| elfenbein  |
|2 | kupfer | rotbraun| bronze |
|4 | oliv   | dunkelbraun | schwarz|
| -5/6 | albino | -   | fleckig|


All this machinery can be invoked without ever seeing Emacs.


So yes, the Emacs implementation is the source of truth, and yes, this
can be used without requiring people to operate Emacs by simply using
Emacs as utility with project-specific setup — just as you would do it
with a compiler.


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


signature.asc
Description: PGP signature

Re: Thoughts on the standardization of Org

[Tim Cross]

Asa Zeren  writes:

>
> In these concerns I see one major flaw. The way they are worded at present
> implies that the Emacs implementation of org is the "one true implementation,"
> and that all tools in other environments are auxiliary. I believe that if we
> want org to grow, then it needs to become unbound from Emacs. It should 
> become a
> universal markup format, which just happens to have had many tools first
> implemented for Emacs (even if Emacs still will probably remain the best way 
> to
> edit org files).
>

I think the above is likely the biggest point of disagreement amongst
many org users. Org is not simply a different markup language. Org-mode
is primarily and Emacs mode to help organise *things*. The fact
non-Emacs users have seen it, like it and wish it was available outside
of emacs is great, but for me, not a significant objective. Anything
which took org-mode out of Emacs or made non-Emacs requirements a higher
priority than the on-going development of the mode in Emacs would be
misplaced.

For me and I suspect many others, the ability for non-Emacs users to
work with org files is a 'nice to have', but not a key objective. The
main objective is to make org-mode an even more useful and powerful
Emacs package. I do over 90% of my work from within Emacs - writing this
email, browsing documentation, writing code in various languages,
developing software requirement documentation, writing user manuals,
interacting with version control, compiling, testing software, working
with databases, tracking tasks and time, invoicing clients, planning and
managing projects, appointments etc. About the only things I don't do
with Emacs are general web browsing (because I need Javascript support),
playing music (though I can do this from Emacs as well) and playing the
occasional game.

The old cliche about open source is that it is about scratching your own
itch. For many org-mode users, that means configuring and extending
org-mode as an Emacs package. I suspect this is part of the reason there
are few org-mode tools outside of Emacs. Many of those which do exist
seem to be more oriented towards minimal org-mode support on platforms
where Emacs cannot run (or run easily), like mobile devices. There are
other efforts to bring org-mode into other editors, like vscode, but the
lack of a powerful elisp equivalent (particularly one with all the
editor oriented support of elisp) makes the effort prohibitive.

In many respects, the real 'genius' of org-mode was that it took many of
the separate features and existing functions of Emacs and elisp, wrapped
them all up in a consistent interface called org-mode. Many of the
features and much of the functionality which makes up org-mode existed
in Emacs before org-mode was developed (folding, overlays, font-lock,
inferior process buffers, latex fragment previews, hyperlinks,
encryption, networking, etc.). To implement all of this on another
platform is a large job. Even editors which support many of these
individual features can't easily achieve the same level of integration
because those features are implemented as distinct modules and lack the
consistent extensible power of elisp.

I'm sorry if all of this and other responses seem too negative. The
desire to bring org-mode to non-Emacs users is a worthy goal, but I fear
the size of the task is too large. What may be feasible are stand-alone
org-mode parses which can make up parts of tool chains for limited
processing of org files and perhaps basic org-mode modules for other
editors which enable basic editing of org files.

Tim

Re: Thoughts on the standardization of Org

[TEC]

Hi all,

Following what I've read on the list I've developed thoughts on 
what the
best approach might be. My current thinking is that it may be 
possible
to have Org registered as a standard in such a way that it does 
not

constrain our development efforts.

How?

We forgo locking down the precise format and behaviour of every 
Org

element. Instead we only submit something like
https://orgmode.org/worg/dev/org-syntax.html which /just/ 
describes the
overall syntax. I don't imagine that 'locking' ourself into the 
current
syntax described in https://orgmode.org/worg/dev/org-syntax.html 
would
actually hurt development, but might be enough for a MIME type 
etc.


Then perhaps just say for description of how specific/special 
instances
of those structural elements are supposed to work see the 
reference

implementation.

Just a few thoughts from me.

All the best,
Timothy.

Asa Zeren  writes:


Hi,

Even though I am new to the org-mode community, I would like to 
share
some thoughts on the specification of org-mode, especially since 
I
have seen some recent discussion of it in relation to 
registering org

as a MIME type.

First, I would like to repeat the importance of developing 
standards
for org-mode. If we want to expand the influence of org, tooling 
must
expand beyond Emacs. While Emacs is an amazing tool, (a) we 
cannot
convince the entire world to use Emacs and (b) org-mode should 
be
integrated into tooling unrelated to text editing, and is 
outside of
the Emacs-Lisp environment. Without additional org 
implementations,
this is impossible. If org catches on before it is standardized, 
we
end up in the situation of Markdown, with many competing 
standards and

non-standards. Hence, standardization is essential.

Standardizing org is much harder than standardizing something 
like
Markdown, but I think by breaking it down as follows will 
maximize the

portability of org while not compromising on development of org.

I see three areas of standardization, which I think should be
standardized separately:
 - Org DOM
 - Org Syntax
 - Org Standard Environments

Before we get to that, a brief note on /how/ I think that org 
should
be specified. I think that org should be specified in terms of 
an
/environment/ that defines the properties, etc. that can be used 
in a
document. For instance, the org standard would say something to 
the
effect of "An environment may specify block bounding keywords 
that may
be used like #+\n...#+. and the environment would 
specify

"begin_src and end_src are a pair of block bounding keyword that
indicates a source code block." This is for two reasons. First, 
this

allows for development of org tool features independent of the
standard. Second, this separates the individual features of org 
mode

from the overall structure.

Org DOM:
The first thing to specify is the org DOM. (Maybe a different 
name

should be used to avoid confusion with the HTML DOM) This is the
structure of an org-mode document, without the textual
representation. Many org-related tools operate on org documents
without needing to use the textual representation. Specifying 
the DOM
separately would (a) create a separation of concerns and (b) 
allow for

better libraries built around org mode.

Org Syntax:
This would be specifying the mapping between the DOM and the 
textual

representation, specified in terms of an environment.

Org Standard Environments:
This is how I would specify elements such as 
#+begin_src..#+end_src
would be specified, as standardized elements of the environment. 
This
would be structured as a number of individual standard 
environments,
such as "Source Blocks" or "Standard Header Properties" 
(specifying

#+title, #+author, etc.)

I would appreciate thoughts on these ideas about how to develop 
and

org specification.

Thanks for reading,
Asa Zeren