Felix Wiemann <Felix.Wiemann@...> writes:
> David Abrahams wrote:
>> David Abrahams writes:
>>> David Goodger writes:
>>>> I'm very busy right now, but I'll try to take a look this weekend.
>>> Me too; I know how it is. There's no rush,
>> Okay, I probably shouldn't have said that, but...
>>> but I do want to make sure it hasn't fallen into a black hole.
>> ...now I am getting desperate. The book is finished;
> Cool. I mean, that the book is finished.
>> I have to move on to my next project, and I need to choose a
>> documentation system.
> If there are any reasons against reST, I'd be glad to hear them.
Some areas of hard-to-maintain and understand spaghetti-ish code.
Poor response time from the one person who can help with that code.
If you look backwards in this thread you'll see that I asked for a
simple look at a problem I am facing a long time ago, and nothing has
I implemented nested inline markup months and months (maybe a year?)
ago. It languished on a branch and received essentially no attention
for many months. Then, an objection was raised to part of the
solution's approach that it will break in the presence pathologically
deep nesting. I'm sure I can fix that (although I'm not sure of its
importance) and I eventually found time to do it, but by then the
codebase had moved on. I tried to bring my code up-to-date with the
current state of the trunk, and David reported that some tests were
failing. I am not entirely sure that those tests should be passing in
the first place and I lack the understanding of the codebase to
analyze the problem further. I have been waiting for months for
David to take a look at that.
I am not indicting anyone -- since we're all volunteers here -- least
of all David G. without whom this project couldn't exist. That said,
I hope you can see why I'd wonder if I should invest any more in ReST.
>> I need to know whether there's a future for me here.
> Depends on whose future you mean:
> *Your* future here, as a user and/or developer: Sure, you're always
Welcome isn't the same as supported.
> (You hopefully didn't expect anything else, did you?)
> The future of the nested inline parser you started: I don't know for
> sure. Frankly, I reckon it might be necessary to refactor the inline
> parser from scratch in order to get nested inline markup working,
> especially because the parser uses many regexes.
> (I don't mean the design is bad or so. It's just that it may be
> unsuitable for nested markup.)
Emphatically, NO. This is a myth. It's a relatively simple thing to
fix. I just need to replace some of the regex groups with unnamed
> On the other hand, I must admit that I do not fully understand how
> the implementation of the current inline parser is structured, and
> neither do I know very much about writing parsers in general, so I
> might very well be wrong.
Fortunately, this time, you are.
> The future of nested inline markup in general: I'm quite confident
> that it will be implemented sooner or later.
The idea that my very significant investment in coding could be
scrapped and re-done because of a myth is very discouraging.