emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Flexible plain list bullets


From: Mark E. Shoulson
Subject: Re: [O] Flexible plain list bullets
Date: Fri, 20 Apr 2012 18:18:29 -0400
User-agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]