From: Tom Gillespie <tgbugs@gmail.com>
To: Samuel Wales <samologist@gmail.com>
Cc: Bastien <bzg@gnu.org>, Kyle Meyer <kyle@kyleam.com>,
Emacs Org mode mailing list <emacs-orgmode@gnu.org>
Subject: Re: did behaviour of RET change again?
Date: Wed, 23 Dec 2020 18:09:15 -0500 [thread overview]
Message-ID: <CA+G3_PO1p-QNGG3vf+8eZ8bG1NQH77NH7y51=knm9s3yUPwveA@mail.gmail.com> (raw)
In-Reply-To: <CAJcAo8vcdwLhbgqjXvT9_gLP=qM8TvPn9_w6tYORKU8p5TPBzA@mail.gmail.com>
> in case not obvious, i am suggesting a nil value for org adapt indentation.
> thus no physical indentation of all lines including planning lines.
> i'd even suggest no physical indentation as default for example and
> source blocks, but that is a can of worms.
I know that this is a can of worms, but I agree. Given that the effects of
org-adapt-indentation can be mimicked in other ways without having the
literal spaces present in the file it may not be as big a deal as we think.
The other reason I think this is a good idea is because I have been working
on a formal grammar for the org syntax, and everything would be SO much
simpler about the implementation after the first pass parse if the canonical
representation of an Org file did not allow significant whitespace (with an
exception for plain lists).
Just avoiding having to deal with any number of nasty edge cases for correctly
aligning org babel blocks would be worth it. Not to mention the fact that it
means that you have to do a triple pass over each incoming line in order to be
sure that what you are passing to an org babel block has had the leading
whitespace removed (once for a normal parse, second time to adjust whitespace
and a third time to actually parse the babel block). No significant
leading whitespace
would remove the need for an entire pass in the parser.
I will have more on the subject when I finally get around to sharing the
grammar, but suffice to say, that having org-adapt-indentation set to true
and putting the leading spaces in the file (instead of doing whatever it is
that doom does by default) induces significant complexity into the
implementation. I would love to see it gone, as I'm sure anyone wanting
to parse org files in future will too.
Best!
Tom
next prev parent reply other threads:[~2020-12-23 23:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-18 13:06 did behaviour of RET change again? Eric S Fraga
2020-12-18 14:42 ` Pankaj Jangid
2020-12-18 14:59 ` Eric S Fraga
2020-12-19 4:21 ` Pankaj Jangid
2020-12-18 18:33 ` Berry, Charles via General discussions about Org-mode.
2020-12-20 17:25 ` Bastien
2020-12-20 18:56 ` Gustavo Barros
2020-12-21 8:46 ` Eric S Fraga
2020-12-21 10:25 ` Eric S Fraga
2020-12-21 11:34 ` Kévin Le Gouguec
2020-12-22 15:36 ` Kyle Meyer
2020-12-22 23:15 ` Samuel Wales
2020-12-22 23:25 ` Samuel Wales
2020-12-23 23:09 ` Tom Gillespie [this message]
2020-12-24 3:34 ` Greg Minshall
2020-12-24 6:35 ` Tom Gillespie
2020-12-25 6:29 ` Devin Prater
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='CA+G3_PO1p-QNGG3vf+8eZ8bG1NQH77NH7y51=knm9s3yUPwveA@mail.gmail.com' \
--to=tgbugs@gmail.com \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=kyle@kyleam.com \
--cc=samologist@gmail.com \
/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).