Hello, Robert and Lorenz,
sorry for my long silence. I'm privately swamped at the moment but hope
to get a rest soon.
Yes, the parser deals with lists as you investigated, mostly to make
usage as simple and intuitive as possible. So a list end is detected
whenever another paragraph type starts. This implies that lists do not
need to be closed explicitly, regardless of their nesting level. The
parser closes them implicitly.
The internal grammar of nested lists is a *chain*: a sequence of lists
separated by nothing or a shift paragraph.
But of course, the *result* of this parsing could be streamed in a
*nested* manner, and possibly this is a better approach then the chain
I implemented. I see no reason for changing the stream format
appropriately. As you suggested:
> > Probably the Parser should implement a stack of lists.
>
>Indeed. And expect backends to do so.
(Note: The shift paragraph, by the way, is restricted to lists because
I doubt there is a general meaning of paragraph shifts in *all* (or
most) target languages. That's why I hesitated to implement an old idea
of Jeffrey who suggested to make paragraph shifts generally available.
If there are ideas how to translate them a general way, we could make
them a "usual" paragraph.)
> > Another problem is the continuation of numbered lists, which may be
> > interrupted by an example (verbatim) block.
>
>I think the opposite: if the parser expects back-ends to deal with
>nested lists, the continuation will solve itself.
This is a parsing issue. For example, it is difficult to recognize
whether the following is a verbatim paragraph in a list or a sequence
of a list, an example and another list:
* a
* b
example code
* c
* d
If shifts remain restricted to lists, things would be clear if
something is embedded into a sublevel list, but it would be hard for
users to learn that "embedding is allowed except in first level lists".
In my opinion, usage should remain as intuitive as possible, and the
syntax is designed as a sequence of paragraphs.
Another parsing difficulty is that I would have to delay list
completion (and handling of all subsequent paragraphs) until the end of
a chapter where I could finally say: "whatever came after the last list
was not embedded because every list ends with the chapter".
So we would need extra syntax to say that embedded elements follow
"continuing" the list - a kind of glue that combines list and non-list
elements. Can we find an intuitive way to establish something like
that?
Illustration (not intended to be imple,ented this way):
* a
* b
|
example code
|
* c
* d
The second "glue part" would be redundant, of course.
>What you'll need is
>a way to start a NEW numbered list right after the old one!
I'm not sure what you meant here - the same problem as described above?
>But maybe that is best solved by a way of setting the list counter.
> #=<1>
>This would then allow you to continue numbered lists across
>a number of slides...
Ah, hm, I see. Let me think about this.
Because shift paragraphs can take a number immediately after the
startup character, maybe
#1
would be consistent.
But it would imply that an ordered list point cannot begin with a
number, or that spaces after the intro sequence become mandatory.
Good luck with your presentation, Robert!
Greetings
Jochen
sorry for my long silence. I'm privately swamped at the moment but hope
to get a rest soon.
Yes, the parser deals with lists as you investigated, mostly to make
usage as simple and intuitive as possible. So a list end is detected
whenever another paragraph type starts. This implies that lists do not
need to be closed explicitly, regardless of their nesting level. The
parser closes them implicitly.
The internal grammar of nested lists is a *chain*: a sequence of lists
separated by nothing or a shift paragraph.
But of course, the *result* of this parsing could be streamed in a
*nested* manner, and possibly this is a better approach then the chain
I implemented. I see no reason for changing the stream format
appropriately. As you suggested:
> > Probably the Parser should implement a stack of lists.
>
>Indeed. And expect backends to do so.
(Note: The shift paragraph, by the way, is restricted to lists because
I doubt there is a general meaning of paragraph shifts in *all* (or
most) target languages. That's why I hesitated to implement an old idea
of Jeffrey who suggested to make paragraph shifts generally available.
If there are ideas how to translate them a general way, we could make
them a "usual" paragraph.)
> > Another problem is the continuation of numbered lists, which may be
> > interrupted by an example (verbatim) block.
>
>I think the opposite: if the parser expects back-ends to deal with
>nested lists, the continuation will solve itself.
This is a parsing issue. For example, it is difficult to recognize
whether the following is a verbatim paragraph in a list or a sequence
of a list, an example and another list:
* a
* b
example code
* c
* d
If shifts remain restricted to lists, things would be clear if
something is embedded into a sublevel list, but it would be hard for
users to learn that "embedding is allowed except in first level lists".
In my opinion, usage should remain as intuitive as possible, and the
syntax is designed as a sequence of paragraphs.
Another parsing difficulty is that I would have to delay list
completion (and handling of all subsequent paragraphs) until the end of
a chapter where I could finally say: "whatever came after the last list
was not embedded because every list ends with the chapter".
So we would need extra syntax to say that embedded elements follow
"continuing" the list - a kind of glue that combines list and non-list
elements. Can we find an intuitive way to establish something like
that?
Illustration (not intended to be imple,ented this way):
* a
* b
|
example code
|
* c
* d
The second "glue part" would be redundant, of course.
>What you'll need is
>a way to start a NEW numbered list right after the old one!
I'm not sure what you meant here - the same problem as described above?
>But maybe that is best solved by a way of setting the list counter.
> #=<1>
>This would then allow you to continue numbered lists across
>a number of slides...
Ah, hm, I see. Let me think about this.
Because shift paragraphs can take a number immediately after the
startup character, maybe
#1
would be consistent.
But it would imply that an ordered list point cannot begin with a
number, or that spaces after the intro sequence become mandatory.
Good luck with your presentation, Robert!
Greetings
Jochen