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

[Patrick R. Michaud]

On Sun, Aug 10, 2003 at 09:02:28PM +0200, Bernhard.Weichel at t-online.de wrote:
> Crisses wrote:
> > I see a problem of backward compatibility with your "one space at
> > beginning" suggestion
> >
> 
> 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.

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.

> 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 with a 
strong enough case that one is needed yet, or a scaleable markup 
strategy that satisfactorily meets PmWiki's other goals.

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.
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.

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.

> > 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
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.


> > 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.  :)

> 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
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 don't know how many people use separate lines for continuous
> > paragraphs...it does help when cut&pasting from emails and the like,
> > because there are line breaks in the paragraphs, and you don't have to
> > run through removing linebreaks when dropping new text into the wiki.
> 
> manual linebreaks in the source also allow to easily use the cursor
> keys to navigate within the text. And if the edit window is resizeable
> (what I do in my wikis), the text appears again different. So for
> ease of editing, it should be possible that the author adds insignificant
> line breaks.

These are two of the best arguments I've heard for keeping the current
linebreak markup system and rejecting my proposal that linebreaks in
the middle of paragraphs become significant by default--thanks.

> > But as a poet, I'd love to implement the final \ *for* line breaks!
> 
> but you should know, that the single space a the beginning is much easier
> to type, has much more similarity between source and rendition.

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.

> >> 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.

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.

> 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.

> > 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.

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.

> >> * Markup which appears in pairs such as [[table]] [[tableend]]. In
> >>   this case even the blockstructure of [[cell]] and [[cellnr]] can
> >>   safely be detected. If the markup is complete, PmWiki always
> >>   generates properly balanced HTML tags.
> >
> > 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.

> > 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.

> 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.

Pm