emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@posteo.net>
To: Timothy <orgmode@tec.tecosaur.net>,
	Wes Hardaker <wjhns209@hardakers.net>
Cc: emacs-orgmode@gnu.org
Subject: Re: On org-syntax and IANA MIME type registration
Date: Fri, 26 Jan 2024 13:55:38 +0000	[thread overview]
Message-ID: <87msssdwrp.fsf@localhost> (raw)
In-Reply-To: <87wmrw3gpy.fsf@tec.tecosaur.net>

[CCing Wes Hardaker]

Timothy <orgmode@tec.tecosaur.net> writes:

> With the recent mention of the text/org mime type, and registering it as an IANA
> in-tree MIME type in particular, I’d like to draw attention to this part of
> <https://www.rfc-editor.org/rfc/rfc6838.html#section-3.1>:
>
>> When review is required, a change request may be denied if it renders entities
>> that were valid under the previous definition invalid under the new definition.

AFAIU from the other instances of word "entities" in the document, it
refers to files of Org type. So, the above is meant that previously
valid Org documents cannot become invalid.

> While the org-syntax document is a work in progress to accurately describe the
> current state of affairs, there are currently supported syntactic elements that
> I think are broadly seen as “would be nice if we didn’t do that”. For example:
> the special switch syntax in babel headers, and support for $-maths.

I do not think that $-math or switches are significant enough to render
Org mode documents invalid. They are minor changes.

> This does make me wonder if we should actually try to register a slightly
> different org-syntax to “what org-mode parses”, without these elements that we
> now think we’re better off without, but have org-mode still parse them.

Maybe for $...$, but not for switches. We may instead make the syntax
description broad enough to allow switches without explicitly describing
how they should be interpreted.

> My thinking is we don’t want to lock ourselves into a situation where we would
> /like/ to deprecate certain syntax over the long term, but are unable to do so
> without diverging from the IANA-registered specification, and can’t register the
> change in syntax because of the paragraph I’ve quoted.

I don't think that it is going to be a major problem.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>


      reply	other threads:[~2024-01-26 13:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-26  3:30 On org-syntax and IANA MIME type registration Timothy
2024-01-26 13:55 ` Ihor Radchenko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87msssdwrp.fsf@localhost \
    --to=yantar92@posteo.net \
    --cc=emacs-orgmode@gnu.org \
    --cc=orgmode@tec.tecosaur.net \
    --cc=wjhns209@hardakers.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).