From: "Mark E. Shoulson" <mark@kli.org>
To: Bastien <bzg@altern.org>
Cc: org-mode mailing list <emacs-orgmode@gnu.org>,
Carsten Dominik <carsten.dominik@gmail.com>
Subject: Re: Flexible plain list bullets
Date: Fri, 20 Apr 2012 18:18:29 -0400 [thread overview]
Message-ID: <4F91E0B5.9090006@kli.org> (raw)
In-Reply-To: <8762cuttei.fsf@altern.org>
On 04/20/2012 09:38 AM, Bastien wrote:
> Hi Mark,
>
> I agree with Nicolas that a solution based on overlays would be better.
Probably, though very possibly not worth it.
>
> I also agree with you that there are many areas where we let the users
> modify the content of Org files in a way that makes them unparsable in
> a systematic manner.
>
> This is always a trade-off: user flexibility vs a rigid syntax.
Yes. And as I noted in my examples, some/many of the cases involved
were dealing with things that *really are worth* bending parsability for
(as was pointed out to me on IRC.) TODO keywords, for example, *really
do* have to be customizable, and the system has to deal with it. Even
with global configuration variables, that in no way follow the files
around. I agree that those were worth doing it for.
>
> On top of this trade-off there are many other one to consider, based
> on what are the available human (benevolent) resources to maintain Org.
>
> I try to prioritize things this way:
>
> 1. fix current bugs
> 2. improve syntax stability (against current state of flexibility)
> 3. extend current features
> 4. integrate new features
>
> Sometimes, a request raises a discussion somewhere between (3) and
> (2) -- which is precisely the discussion we have now. But pointing
> at failure in the current syntactic ground does not help promoting
> a feature request at (3) :)
Sure. I'm just noting these because probably nobody would have seen
them as issues if the importance of hard-coding the syntax hadn't come
up as a point in answering me. They (probably) aren't doing much harm
anyway. I'd offer to write a patch for some of the more obvious ones,
to free up that much time from others, but it would be so small, it
would probably take as long for someone to look over my patch as to
write it themselves, so it wouldn't save anyone any time really.
"Pointing out a failure in the current syntactic ground does not help
promoting a feature request at (3)"... It might have, had the failures
been so widespread as to show that this was the intended mode all along
(as was not the case, so no, it doesn't). But getting the feature
request in was already mostly off the table, I thought. I found some
stuff that might be useful to know about; thought I should say so. (I'm
talkative, yes, but not necessarily a jerk.)
>
> Also, Nicolas is working on a generic parser which will be the
> base for future decision on (2), and (consequently) on (3).
That was mentioned, especially with respect to the source-blocks.
>
> So yes, this is complicate. We have many users. And an overlay
> based solution will *not* be a temporary fix, it will be something
> that any user can enjoy.
>
I played with making the customization only able to ADD new characters,
which I think would not be so harmful, but really only for my own
edification; I can see that there really is no desire (outside me) to
add this feature anyway.
~mark
next prev parent reply other threads:[~2012-04-20 22:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-19 1:24 Flexible plain list bullets Mark E. Shoulson
2012-04-19 8:18 ` Nicolas Goaziou
2012-04-19 9:40 ` suvayu ali
2012-04-19 10:01 ` Carsten Dominik
2012-04-20 4:19 ` Mark E. Shoulson
2012-04-20 5:58 ` Jambunathan K
2012-04-20 13:38 ` Bastien
2012-04-20 22:18 ` Mark E. Shoulson [this message]
2012-04-20 22:35 ` Bastien
2012-04-22 13:43 ` Mike McLean
2012-04-20 14:51 ` Carsten Dominik
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=4F91E0B5.9090006@kli.org \
--to=mark@kli.org \
--cc=bzg@altern.org \
--cc=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
/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).