[Pmwiki-users] Idea for extension of special list syntax

chr@home.se chr
Fri Jan 21 08:16:33 CST 2005


On Fri, 21 Jan 2005, Patrick R. Michaud wrote:

> Well, it looks as though I'm only going to receive 40% of the messages
> in this thread, so I'll reply as best I can via the archives... :-(

Bah... I couldn't help myself.. I'll answer this and then stop for today :-)

What about using 'gmane' and it's news interface?  (That's what I do most 
of the time anyway... although there is a time lag with that)

> In addition to being able to continue the text of a list item, authors
> would also like to be able to embed paragraphs, and even preformatted
> text, within list items.

Guess I'm forced to say "good point" at this moment...

> So, I'd prefer to explore solutions that enable this capability as well,
> rather than stop short with just the continue the current paragraph
> within a list item.
>
> There's an issue with using leading space for continuation in that it
> can make for some really ambiguous nesting.  Consider:
> 
>    * list item 1
>      continued list item 1
>    ** list item 2
>       continued list item 2
>      Is this part of 1, 2, or is it preformatted text?
>    **list item 3
>      How about this?  If this is part of 3, why wasn't the line above
>      part of 2, as they're both indented by two spaces.
> 
>      And this one?
>     Or this one?
>          Or this?

My interpretation would be that "Is this part of 1, 2, or" is preformatted 
text since it doesn't strictly align. Scott disagrees with this though, 
and thinks any indentation should make it become part of the previous 
level.

Continuing the interpretation, I'd say that "How about.." belongs to list 
item 3 since it is aligned with the start of the text of that item. In 
other words, I think the alignment depends on where the text of the item 
starts. So this would be fine with me:

	* list item
	*     list item 2
	      continued list item 2
	   preformatted text

This should hopefully explain why "Is this..." wasn't included.

> There doesn't seem to be an "obvious" interpretation, or, in other
> words, no matter what we decide, there's likely to be a signficant
> population of authors who will end up being very confused by it or
> strongly feel it should work differently.

Do you still feel that way if we make it clear that it's the position of 
the starting text of the element that the following text need to be 
aligned with?  (I probably hadn't made this clear, and it's also not 
something I really have a strict feeling about... mainly I would just like 
to be able to use this in a simple manner)

> Prior to this discussion I had been playing with the idea of a
> "remain within current item" markup to allow paragraphs and
> preformatted text to nest inside of lists.  I hadn't come up
> with a good markup for it yet, so just pretend that it's leading
> carets:
> 
>     * list item 1 that has a lot of text all on one line
> 
>     ** this is a sublist item
> 
>     ^^ This is text that continues at the sublist level
> 
>     ^ This is text that continues as part of the level 1 list item 1
> 
>     ^ still in list item 1
> 
>     Normal paragraph text
> 
> This still doesn't solve Christian's desire to be able to automatically
> join broken lines into list items, though.  
> 
> To brainstorm a bit, how about some sort of modifier that can be
> placed on the list markers... ?
> 
>     *> This is list item 1.  The '>' after the
>        bullet indicates that any indented lines that follow are
>        to be continuations of the current list item.
> 
>        This paragraph, being indented, is still part of the
>        list item above.
> 
>     *> Here's another list item.  Any indented lines that
>        follow this are also continuations.
> 
>     Now we're back to normal text.

Not bad... I could probably be happy with this.

Just to confuse the issue... what about something like:

	*> This is a list item. The '>' after the
	bullet indicates that we will include the following
	  lines regardless if they are indented or not.
	Until we come to a line containing something like '<'
	<*


> I'm also thinking that perhaps we should come up with some sort of markup
> that can clearly delineate code blocks.  The "space and [= at beginning
> of a line" solution is elegant and consistent, but too many authors
> seem to miss it entirely.  

The one thing that bothers me with 'space and [=' is that it forces an 
extra vertical space... I'd really like to avoid that sometimes...

> I think it's extremely unlikely that I will want to totally eliminate the
> "leading spaces produces monospaced text" rule, as that's a fairly common
> theme among a variety of text formatters, including wikis.

That reminds me... there's still a bug so that TAB doesn't work for 
producing monospaced text.

For the record, I mostly like the "leading space produces monospaced". 
However, see my message about how a single space on the beginning of a 
page can break the layout of the whole page by making it too wide :-(

> This doesn't mean that leading space in every circumstance has to
> produce monospace text, it just means that any proposals that can't
> accommodate it somehow would have to have some very compelling arguments
> for it.

Agreed.

/C

(Even though there's popped in like five messages while writing this, I'm 
signing of for today. Have a happy Friday)

-- 
Christian Ridderstr?m, +46-8-768 39 44               http://www.md.kth.se/~chr





More information about the pmwiki-users mailing list