Re: [O] Flexible plain list bullets

[Mark E. Shoulson]

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