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

[Bernhard.Weichel@t-online.de]

Hi Crisses,

thanks for your reply. I know it is difficult to go through lenghty
contributions. The more I appreaciate your message.
Was there any reason that you did not send your reply to the mailing list?
Assuming that it was a mistake, I quote your full message.


Crisses wrote:
> I see a problem of backward compatibility with your "one space at
> beginning" suggestion
>
> Too many people would have to hand-edit pages to be two spaces for
>   PRE. Or hand-edit pages to implement the new one-space markup
> feature.  It
> is possible to create a script that will go through *all* the wiki.d
> files to automatically change markup, but what if it messes up?
>

This is pretty true. I fear backwards compatibility will one of
these days terminate the further development of PmWiki. The markup
strategy is not scaleable enough. There is also no safely separation
between "native PmWiki" and "customized markup"...

>> * _exactly one space_ at the beginning of the line creates a
>>   line break (not a new paragraph). This works very fine for lyrics
>> etc.
>>   So if one wants PRE, there must be two or more spaces at the
>> beginning
>>   of a line.
>
> This change would break backwards compatibility.
>
>> * ending the previous line with "\" suppresses the line break
>>   in the source. This allows to maintain a good looking source.
>
> 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!

>
>> In a paragraph, a linebreak in the source is like a space. In a list
>> the linebreak in the source ends the list resp. the list item.
>> By this a list item cannot comprise of multiple paragraphs.
>
> Ok, for the record I hate the [[<<]] convention to induce line breaks.
> It takes more wiki markup to use a linebreak than to do the HTML
> markup for a line break :)  the keys are awkwardly spaced from one
> another, as well...so it's difficult to type on the fly.  If it
> weren't for it
> being at the bottom of the edit page so I could cut & paste it, I
> would be fuming. :P
>

If we want it inline, then I fear [[<<]] cannot really improve.
Any new markup like :p also potentially smashes backwards compatibility.
so it must be something in [ ] ...

> 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.
> Because of this, I'd say we should keep the current convention of
> single-return=continue the paragraph. i.e. unless marked up otherwise,
> a single linefeed or return should be translated into a single space.
>

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.

> Why not add the final slash as an alternative to the [[<<]]
> awkwardness?  i.e.
>
> Hi there \
> How are you
>
> will render in HTML as:
>
> <p>Hi there<br />
> How are you</p>
>

this would break backward compatibility, since \ already escapes
the line break. so the only thing we would have is "/" which I would
like. But again it potentially breaks backwards compatibility ;-), and
more serious would not really work in lists.

> and
>
> Hi there
> How are you
>
> will continue to render as:
>
> <p>Hi there How are you</p>
>
> and (any number of leading spaces on each line)
>
>   Hi there
>   How are you
>
> will render as:
>
> <pre>Hi there</pre>
> <pre>How are you</pre>
>
> or (note the exception to the linefeed = single space rule, and that
> I'm proposing that a single space for the first line will render the
> entire block element in the <pre> tags...and initial spaces for each
> line should be eliminated within the pre tags if they exist -- making
> this a good alternative for poetry since you'd only have to put a
> single space at the beginning of each stanza, but it won't change the
> look of indented code, since it will only eliminate one space per line
> throughout.)
>
> <pre>Hi there
> How are you</pre>
>
I fear this is very complicated to understand and to teach the authors.
And it should *not* make <pre> since the poem should still be rendered
in the default font.

I was using the single space approach, since I wanted to follow wiki
style. The other option would be an explicit markup

.poem
hi there
how are youe
.poemend


>
> This should maintain backwards compatibility unless lots of people use
> final \ in a line for some strange reason.
>
> Also, I can see one reason to keep the [[<<]] (other than backwards
> compatibility) -- for line breaks within elements:
>
> !This is the really awfully[[<<]]long title of my page.
>
> should render in HTML as:
> <h1>This is the really awfully<br />
> long title of my page.</h1>
>
This works today.

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

>
>
> Next issue:
>
>> 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.
>
> I like that.  That seems very natural.  I used this idea in the
> examples above, where the space at the beginning of the paragraph
> renders the entire paragraph in <pre> because it's all a part of the
> block.  In bulleted lists, it would mean all elements were nested in
> the same list, etc.  I like this.
>
> 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.  This is one of those
> "there must be a better/neater way!" things...looking at the source
> code on a page with many bulleted lists on it, and paragraph spaces,
> etc. -- it's sloppy HTML or XHTML.  Hrm.
>
> The change to blank lines ending elements may create some
> backwards-compatibility issues.
>

Yes, we are already in a situation where backwards-compatibility
evolves to a real problem.


>> * [/ ... /] marks a block the contents of which safely produces
>> balanced
>>   HTML tags. This could serve as something like a "minipage" which
>> can always
>>   be embedded without side effects. It should be possible to nest it.
>
> Possible...but the problem then is whether or not the balanced HTML
> tags will REQUIRE this markup, in other words, a new user would *have
> to* use this or it would break the XHTML...?  This breaks how natural
> the wiki is to use, requiring more markup from new users: I like that
> a user can open a new page, edit it with just a normal paragraph of
> text, and it will render!  They don't need to markup ANYTHING.  If
> their new paragraph doesn't come complete in <p>...</p> tags, that
> breaks XHTML standards.  If it requires tags like *[/.../] to create
> proper wiki code, it breaks the wiki principles.
>

My proposal was not that the user *has* to use [/ .../] for ordinary
paragraphs. I think PmWiki should render ordinary paragraphs in <p> ..</p>.

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.

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.

> 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.  They'll have to
> learn the web standards for doublespace between paragraphs, that's
> all...and that leading spaces/tabs don't work well....and that's a
> small learning curve).
>
>> * 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.

Misunderstanding ... The advanced table markup is such that the user
does not have to enter ending tags. But the markup is also such that
block ending is not ambiguous. SGML, the basis of XML also had the
approach of Markup Minimization which was added in a formal way
to make the code easy to type *and* easy to process.

On the other hand, they won't forget if the page does not look like
they want. So if you turn on John Rankin's Page Preview, the
problem is at least reduced. And advanced table markup can be wrong
anyhow. So the author will make sure that his page looks fine. And this
could be the way we make him to enter proper markup. If improper markup
is not punished, the he will leave it to be the root of another "backward
compatibility".

perhaps we could add a "strict" mode ...

>
> 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 ;) )
>
> Crisses
> ----
> I'm just a wandering on the face of this earth
> Meeting so many people  who are trying to be free.
> And while I'm traveling I hear so many words
> Language barriers broken, now we've found the key.
> And if you want the wind of change to blow about you
> And you're the only other person to know, don't tell me
> I'm just a singer in a rock and roll band.
> -- Moody Blues, I'm Just a Singer (in a Rock-n-Roll Band)