Re: Release Org 9.4.2
Have people looked at sourcehut (https://sourcehut.org)? While it's still in alpha, and so has a number of rough edges, it seems pretty promising. Sourcehut is trying to build a platform with accessible web uis that is backed by mailing lists. Just annother option to consider, though there is no urgency to move from the current situtation. --Asa
[PATCH] ob-C.el: Fix a number a bugs related to table parameters
Here are a number of fixes to ob-C.el. There is still probably a bunch of general cleanup to do in this file, but these changes make it work for me. 0001-ob-C.el-Fix-a-number-a-bugs-related-to-table-paramet.patch Description: Binary data
Re: Thoughts on the standardization of Org
I have collected below some quotations to try to represent the general sentiments expressed so far in the conversation, upon which I would like to express some thoughts. Most of these have been repeated several times in spirit, so they are not just the opinions of the listed authors. Daniele Nicolodi said: > 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. Daniele Nicolodi said: > 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. I 100% agree that much of the power of org mode comes from the infinite customization. However, I do not agree that this fact makes standardization impossible (see below). Additionally, Emacs is not the only customizable tool, though it is a very good one. The org standard would have to be flexible to accommodate that "my org is not your org," but this is not impossible. Ken Mankoff said: > 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. TEC said: > I also think it's to our benefit that non-Emacsers become more comfortable > with seeing an org file --- as I see it that improves our chances that we can > directly share Org files with them, which they might be comfortable editing > and sending back for example, or that a generic tool might think to support > Org files. These points are especially important, and while a standard is not the only way to progress these goals, it is a good step. Also, re the MIME type discussion, while there was a long list of steps that need to occur for a MIME registration to be useful, I would like to point out that a standard is the first step towards that goal, and even though there are more steps, many of them difficult, that does not mean that we should not make progress. Greg Minshall > perhaps the standard for e-mail headers (originally, RFC822) might be a useful > way of thinking about this issue. it standardizes what it standardizes, and > then says, "and, by the way, you can put in almost anything else [X-Mailer, > ...], but you can't count on any other node understanding it". over time, new > things are standardized (and, so, moved to, e.g., Mailer, and other things > aren't. > > it seems to me this has worked fairly well, and partly this works because of > the late Jon Postel's admonition for designing internet protocols: be > conservative in what you send, and liberal in what you accept. This is a good precedent for how I would like to standardize org. First, standardize general structure, without the specifics. Then, as ideas around a particular feature stabilize, they can be separately standardized, and incrementally adopted. (Though likely many major implementations (aka Emacs) would have already implemented it, even though it is non standard.) For more details on how I think this should be accomplished, see my original post, and also this reply for clarification: https://lists.gnu.org/archive/html/emacs-orgmode/2020-11/msg9.html Ken Mankoff said: > The conversation should move from "it can't be done" or "it isn't helpful" > (why so much negativity on this thread?) to > > + What parts can be standardized and re-implemented outside of Emacs. > + How do we define graceful failure for the other parts. > + How do we support 3rd-party implementation in a way that benefits all of us. This post I also find especially important. There seem to be the ideas that (a) an incomplete implementation is not useful and (b) a standard would necessarily either require another implementation to implement all of Emacs or would eliminate the customizability of org. Thanks, Asa
Re: Thoughts on the standardization of Org
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
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: Thoughts on the standardization of Org
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
Re: Thoughts on the standardization of Org
On Sat, Oct 31, 2020 at 8:40 PM Dr. Arne Babenhauserheide
wrote:
> The most important point I see here is to avoid hindering the
> development of org-mode within Emacs.
While I definitely support enabling the further development of org-mode, and not
restricting it via a standard, I do see some problems.
> So the most important part of the standard would be areas it doesn’t
> standardize: Reserved for future use in org-mode.
The issue with this is that by picking what areas to reserve, one has
effectively limited the syntactic space that new features can use. This is not a
problem in and of itself, but does make the notion of leaving arbitrary syntax
space reserved impossible, particularly, since in org-mode and similar markup
languages, unadorned text is part of the content, rather than being ill formed,
as in programming languages. This also does not mean that tools can interpret
part of what org-mode considers content as having some domain or implementation
specific meaning. For example, latex blocks. In my opinion, the translation of
these are a language extension by the org-export tool. Even within parts of the
Emacs org implementation, latex blocks should not be considered part of the org
language. For example, the line "* Headline?" in the example below is still
identified as a headline, even though, if the area inside the \begin and \end
commands were supposed to be latex, not org, it should not be.
#+begin_example org
\begin{equation}
* Headline?
\end{equation}
#+end_example
> The most important point I see here is to avoid hindering the development of
> org-mode within Emacs.
> These would then be sections that external tools must handle as
> opaque text so their processing does not break usage within
> org-mode.
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).
Best,
Asa
On Sat, Oct 31, 2020 at 8:40 PM Dr. Arne Babenhauserheide
wrote:
>
>
> Asa Zeren writes:
> > I would appreciate thoughts on these ideas about how to develop and
> > org specification.
>
> The most important point I see here is to avoid hindering the
> development of org-mode within Emacs.
>
> So the most important part of the standard would be areas it doesn’t
> standardize: Reserved for future use in org-mode.
>
> These would then be sections that external tools must handle as opaque
> text so their processing does not break usage within org-mode.
>
> Best wishes,
> Arne
> --
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
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 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
