[pmwiki] Re: [Pmwiki-users] discussion on line breaks

[Bernhard.Weichel@t-online.de]

Patrick R. Michaud wrote:
> On Sun, Aug 10, 2003 at 09:02:28PM +0200,
> Bernhard.Weichel at t-online.de wrote:

>> This is pretty true. I fear backwards compatibility will one of
>> these days terminate the further development of PmWiki.
>
> I must respectfully disagree.  Backwards compatibility is a highly
> desirable goal but not a law--I've never claimed that I would preserve
> backwards compatibility at all costs.  However, I've yet to encounter
> a situation where that has been a real problem.

Sorry, I should have mentioned that in this mail I intended to overstretch
the "backwards compatibility" argument to a sarcastic mode.

If "I fear" there is nothing to disagree but rather to comfort or to
convince ;-)
And as a good luck we do not deal with Nuclear Plants (Tschernobyl) or
spacecrafts (Challenger), or Aircrafts, or even Websites being really
important for business.

> And if I do ever have to introduce a feature that breaks backwards
> compatibility, I would certainly expect to provide tools to migrate
> older data into the system.

I fear this is not that easy:

* how to invoke the tool
* how to check the results
* how to prevent multiple invocations
* how to ensure robustness (in particular with customized sites)
* ...


>> The markup
>> strategy is not scaleable enough. There is also no safely separation
>> between "native PmWiki" and "customized markup"...
>
> Again, I disagree on these points.  We can introduce a scaleable
> markup strategy whenever we want--I simply haven't been presented

I would be quiet if I at least have an imagination how it could be done.
Then I can find someone who does it for me and contribute it.

> with a
> strong enough case that one is needed yet, or a scaleable markup
> strategy that satisfactorily meets PmWiki's other goals.

I tried to start the discussion how the strategy could be. But as long
as we do not agree upon the necessity, we cannot have a target driven
discussion.

> I can make a similar arguments for the separation between native
> PmWiki markup and customized markup:
>   1.  I've been presented with very few situations where this is
>       actually a problem,
>   2.  I haven't been presented with any workable solutions to this
>       "problem" (within PmWiki's other goals),
>   3.  Almost all of the "native PmWiki markup" can in fact be
>       overridden, redefined, or disabled as needed by site
>       administrators, so future compatibility isn't really a problem.
>       Even if a future version of PmWiki introduces a markup that
>       someone else has been using for a different purpose, they can
>       easily redefine it to be a different sequence or decide what
> works best for them.

In the long term this can lead to a PostPmWiki (phpnuke -> postnuke,
ingres -> postgres ...) because in this scenarion one would either have
to migrate his data or to cut himself off the future development.

> Designing a system in which conflicts never arise is usually complex
> and often nearly impossible.  The better approach is to keep things
> simple and have mechanisms in place to resolve conflicts when they do
> appear.

And as a good luck we do not deal with Nuclear Plants (Tschernobyl) or
spacecrafts (Challenger), or Aircrafts, or even Websites being really
important for business.

> I will continually point to PmWikiPhilosophy #3, which basically says
> to resist implementing new features until there are actual problems
> and applications that require it and it's clearly understood how they
> will
> be used.

I agree. But we should also keep in mind the options for future development.
And if we use all characters and all tricks for markup one days we will have
no more characters and no more tricks. I now know that Wikis deal with
probabilities, and perhaps this is what makes them attractive. Such as
Microsoft tools which automagically do what Bill Gates think that 80%
of the customers will expect ;-)

>>> Note that I don't personally see any problem with the ending slash,
>>> except that I think it could be used the other way around and then
>>> it won't affect backwards-compatibility (see below)
>>
>> Note that this is already implemented!
>
> I chose the backslash-suppresses-newline approach because it's
> commonly
> used that way in many programming and scripting languages.  It
> would've confused a lot of people in that audience if it had been
> used the other

I really like the backslash-suppress-newline-feature.

> way.  We could consider having a forward slash at the end of a line
> cause line breaks--I don't think that occurs very often in markup
> text,
> and if the author wants the slash to appear he/she simply adds a space
> after the slash.
>
>     What is rooted is easy to nourish. /
>     What is recent is easy to correct. /
>     What is brittle is easy to break. /
>     What is small is easy to scatter.

My personal preference is:

* single line breaks are never significant.
* single line breaks can be made significant by Markup
* blocks are separated always by two line breaks

Then "\" markup can be used to handle the exceptions (in lists and simple
tables).
The "/" approach can even be introduced in lists and simple tables.
And if one wants to end the line with "/" he can add spaces to it.

>
>>> Ok, for the record I hate the [[<<]] convention to induce line
>>> breaks.
>
> Everyone hates [[<<]]--even me.  I'm still wide open for suitable
> alternatives.  :-)
>
>>> It takes more wiki markup to use a linebreak than to do the HTML
>>> markup for a line break :)
>
> This is an excellent point.  I never really intended [[<<]] for simple
> line breaks--I introduced it because I needed a way to do the
> equivalent
> of <br clear='all'>.  We could always introduce [<<] instead, which
> would be the same number of characters.  And the line break continues
> to be the one place where I would seriously consider allowing the
> actual HTML <br> sequence in the wiki markup.  :)

I would rather make it such that line breaks also appear in the source
which makes the source looking more similar to the rendition.

>> Any new markup like :p also potentially smashes backwards
>> compatibility. so it must be something in [ ] ...
>
> Baloney.  We introduce new markup all of the time that has the
> *potential* to smash backwards compatibility but in *practice* never
> does--it just takes judicious choice of markup.  If we hold the
> principle that we can never introduce something that "might" break
> backwards compatibility then we

 as pointed out earlier, I was in a sarcastic mode ..

> can never introduce anything new.  Even "more structured" markup
> languages have this problem--new features always have the potential
> of causing an existing system to break.  The question is one of
> probability, not possibility.

I disagree somehow. "More structured" markup systems do not have this
problem.

e.g.

<dl>
   <dt>pmwiki</dt>
   <dd>an excellent wiki system</dd>
   <dt>cms</dt>
   <dd>content management system</dd>
</dl>

can safely be converted to

<dl>
  <dle>
    <dt>pmwiki</dt>
    <dd>an excellent wiki system</dd>
  </dle>
  <dle>
    <dt>cms</dt>
    <dd>content management system</dd>
  </dle>
</dl>

A proper css file would render both in the same way. A tre based rendition
engine can easily be made such that it safely presents both the same way.
And believe me this is also true for much mor complex markup (I am dealing
with XML dtds of 700 Elements, and compatibility is my daily bread).
>
> I still think the ultimate solution is to come up with a way in which
> we can have an inline linebreak that is much less intrusive than
> [[<<]].
> I'm sure it can be done.

And IMHO it should be the "/" at the end.

>
>>>> So, if by any mean a solution for the nested blocks would be of a
>>>> great help.
>>>> It could be something like:
>>>> * empty lines markup a block sequence. This generates Paragraphs
>>>> etc.
>>>
>>> The current way of rendering lines in a bulleted list, and closing
>>> paragraph marks, IMNSHO stinks.  I understand why it's necessary
>>> given the current way that PmWiki is rendering code.
>
> Actually, it's not *necessary*--it's just the intermediate and quick
> off-the-cuff solution I came up with in order to allow PmWiki to gain
> XHTML compliance and not hold up the 0.5 release.  There are other
> solutions (including many that preserve backwards compatibility), but
> I'm trying to understand the problem space better before committing to
> a particular solution.

For me, the problem is that Wiki syntax does not allow to safely determine
the block borders. Then it won't be a problem.

> Part of the problem is that XHTML says that paragraphs are block
> elements that cannot have nested block elements (such as lists or
> tables) inside of them.  Thus each paragraph must be closed before
> any other block element
> can be created--i.e., paragraphs don't nest.
>

You can safely overcome this by using <div class="P"> elements. <div>
may be nested, my contain tables and lists and anything else.

>> My proposal was not that the user *has* to use [/ .../] for ordinary
>> paragraphs. I think PmWiki should render ordinary paragraphs in <p>
>> ..</p>.
>
> Agreed.
>
>> But for example, if one wants to add a table into a list, he could
>> wrap the table in  [/ .. /]. The same applies, if he wants multiple
>> paragraphs in the list. So it would be an extension to the current
>> approach.
>
> While I agree with the idea of [/ ... /] for nesting paragraphs within
> block elements such as lists (and that's how I proposed it in my
> message
> of several weeks ago), I'm still not sure I'm ready for arbitrary
> nestings of block-level items such as tables within lists.  We can
> already do lists-within-lists, and I agree that paragraphs within
> lists ought to be possible, but I think tables-within-lists gets
> pretty messy
> from a markup perspective and is probably better left avoided.

First let me say, that tables in lists are really useful. And it is
not impossible:

 * the first argument uses these keywords: \

   ||kw1 || this is the first keyword ||
   ||kw2 || this is the second keyword ||

 * the second argument uses those keywords: \

I agree that this smashes the "pre" approach ...

>>> That's why I'd personally prefer the blank line over this...it's
>>> easy
>>> to hit return twice...it sticks with the wiki principles...it's
>>> natural for a new user (the only other thing I can think of being
>>> "natural" is 5 spaces at the beginning of a paragraph...or hitting
>>> "tab" at the beginning of a paragraph, in which case such a user
>>> might use only one return at the end of a paragraph.
>
> Here's a bizarre idea that I'm only lukewarm about but will throw into
> the discussion mix anyway: How about having a special paragraph markup
> that means "I want a new paragraph within the current block element
> at the same level".  I'll use "+" here as an example, but it could
> probably be something else.
>
>     * Here is bullet 1
>     ## Here is bullet 1.1
>     ## Here is bullet 1.2
>     ++ and this is a new paragraph in 1.2
>     that continues on several lines
>     ++
>     and here's another new paragraph
>     in 1.2 with more lines
>     + but this paragraph is within bullet 1
>
>     And now the list is done.
>
> resulting in
>
>    <ul><li>Here is bullet 1
>       <ol><li>Here is bullet 1.1</li>
>         <li>Here is bullet 1.2
>         <p>and this is a new paragraph in 1.2
>         that continues on several lines</p>
>         <p>and here's another new paragraph
>         in 1.2 with more lines</p></li>
>       </ol>
>       <p>But this paragraph is within bullet 1</p></li>
>     </ul>
>     <p>And now the list is done.</p>
>
> and displaying as
>
>      * Here is bullet 1
>          1. Here is bullet 1.1
>          2. Here is bullet 1.2
>
>             and this is a new paragraph in 1.2 that continues on
>             several lines
>
>             and here's another new paragraph in 1.2 with more lines
>
>        But this paragraph is within bullet 1
>
>    And now the list is done.

patrick, this would be the markup for Lists, I desire.
So I think we should make the PRE markup more explicit. Then we have
much more freedom for lists. In particular, the markup should be

----------------------- snippet
 * Here is bullet 1

   1. Here is bullet 1.1

   2. Here is bullet 1.2

      and this is a new paragraph in 1.2 that continues on
      several lines

      and here's another new paragraph in 1.2 with more lines

      * this is another list within 1.2 /
      * this is another item which is an item because of "/"
        which made the line break significant.
      * this would not be recognized as Item, since the line
        break was not significant. The user will notice this
        rather soon.

   But this paragraph is within bullet 1

 * this is bullet 2

And now the list is done.
----------------------- snipet

this list markup is easy to read in the source. The effort of the
user has to go to make a clean source which is honored by a good
rendition. This IMHO really follows the Wiki principle.

> The main problem I have with this idea is that the "++" in the markup
> doesn't look anything like the rendered output, but it is a possible
> alternative.

Yes.

Perhaps we can overcome the whole thing by adding a [[list-1]] or [[list-2]]
markup to allow the user to switch between the two list engines. And later
we make list-2 the default.

>>> Trust the user not to complete the markup.  This is not a joke:
>>> people will forget ending tags.  Or someone else will come along and
>>> accidentally screw up the ending tags.
>
> This is why I did advanced tables the way I did, with [[cell]] and
> [[cellnr]] tags at the same level instead of trying to duplicate
> HTML's <tr> and <td> structures and their closing tags.  That way
> the lack of ending tags (or even start tags!) doesn't produce totally
> unpredictable results.

This is a good job. In the first hand I did not like it. But remembering
good old SGML minization now I love it.

>>> I'm not thrilled with the advanced table markup, because a new user
>>> wanting to add information to an existing table would have a heck
>>> of a time figuring out how to do so...(although a plea like
>>> "Someone please add the following to the table above!" might work
>>> in a wiki ;) )
>
> I'm not entirely thrilled with it either, but it did solve some
> important needs I had.  The reason why the advanced table markup
> works to the extent that it does is largely because it makes no
> pretensions towards nesting advanced tables.  Once arbitrary nesting
> is introduced, the markup can
> get far far worse.

I think advanced table markup can safely be extended to nested tables.
(Thanks fore [[tableend]].

>> We need to decide, if PmWiki strictly follows the wiki prinicples and
>> therefore is just another wiki or if it should also be useful as
>> poor man's content management system which requires a little more.
>
> Ummm, I've never said or believed that PmWiki must strictly follow
> the wiki principles, I don't think that PmWiki is necessarily limited
> to just the two options stated here, and I don't agree with the
> unstated premise that PmWiki is not currently useful as a content
> management
> system.  PmWiki doesn't aspire to fit any preconceived definition
> of what a wiki or CMS should be--PmWiki simply incorporates those
> features that fit well with the overall philosophy and needs of its
> user community, and PmWiki postpones or discards the features that
> don't currently fit.

Yes, Patrick, I treated PmWiki more a lean CMS than a strict wiki.
For this reason I really miss Page preview and Track Authorship.

The lack of "Track Authorship" is IMHO a problem even on pmichaud.com
and is also on the way to kill PmWiki for our CVJM application.

The last issue which would really help for CMS like applications is
"page fallback".

--bernhard weichel