[pmwiki-users] Would you accept a patch to ignore linefeeds after << ?

[Patrick R. Michaud]

On Thu, May 25, 2006 at 03:32:58PM -0700, Jo Rhett wrote:
> The problem is that the parser reads a leading blank line there.  To get it
> to display properly you need to do this
> 
> >>pre<<$ ls -la
> $ rm -rf /
> >><<

Ah, the problem is that *HTML* is seeing a leading blank line there
(by the time the parser gets to this line, the newlines have already
been stripped).  So, what's happening is that

   >>pre<<
   $ ls -la
   $ rm -rf /
   >><<

becomes in HTML

   <div class='pre'>
   <p>$ ls -la</p>
   <p>$ rm -rf /</p>
   </div>

and it's that first newline after the <div class='pre'> that
is generating your unwanted blank line.

And I agree with you that the <p>...</p>'s aren't really what we
want here, either.  What we *really* want to have here is <pre>...</pre>
instead of <div> and the <p>'s.

> If I made a patch which looked for and removed/ignored whitespace*linefeed{1}
> after a >><< tag, would you accept it?
> I can't imagine that it would break anything, and it would work as expected
> for most people.

I probably wouldn't accept it as you describe here, for a couple of
reasons.  First, I think it could break some things, if anyone else
is using a similar trick and expects the newline to be there.  Secondly,
tying this particular behavior explicitly to the ">><<" markup sounds
too much like a workaround for a specific case, where we really ought
to look at the problem more globally and find a more generic solution.
Special-case fixes tend to add complexity and limit options later on.

FWIW, I really liked your suggestion of using something like
[@=...=@] to mean monospace and escaped markup, leaving [@...@]
to potentially mean "preformatted block" but still honor wiki
markups inside.  I wish I had thought of it.  :-)  Unfortunately,
the existing [@...@] has been with us for 3+ years (and just received
an overhaul for 2.1), so it's probably too entrenched in the community
for us to reasonably consider changing it now.

However, even if [@...@] were available to mean simply "monospace
block" without escapes, we'd still have some inconsistencies.
To avoid confusion, let's leave the existing [@...@] alone and posit
a [@@...@@] markup that means "monospaced/preformatted block *with*
wiki markup".  (I don't think we'll actually use [@@...@@], I'm
just using it as a convenient placeholder for purposes of this
discussion.)

Unfortunately, unlike [=...=] and [@...@], which suppress *all*
internal wiki markup, something like [@@...@@] has to be a bit
more selective -- allowing *some* wiki markups to be processed
while suppressing others.  Consider something like:

    [@@
    $ ls -l
    ''emphasized output''             # rendered emphasized
    $ cat file.txt
    http://www.example.com            # rendered as a link
    @@]

We'd want this to produce

    <pre>
    $ ls -l
    <em>italic output</em>
    $ cat file.txt
    <a href='http://www.example.com'>http://www.example.com</a>
    </pre>

and not

    <pre>
    <p>$ ls -l
    </p><p><em>italic output</em>
    </p><p>$ cat file.txt
    </p><p><a href='http://www.example.com'>http://www.example.com</a>
    </p></pre>

In other words, we want the emphasized and link tags to be produced,
but not the paragraph tags.  Or continuing with a unix script
example, consider a markup of:

    [@@
    # whoami
    ''root''
    # rm -rf /
    '''You just did a bad thing'''
    @@]

Those leading #'s shouldn't be treated as instances of the
ordered list markup.  So, these examples illustrate that the
[@@...@@] markup acts quite differently from the other markups
we use, and this difference ought to be made more distinct
from [=...=] and [@...@].  

Also, unlike the existing [=...=] and [@...@], I think that
any escape sequences within [@@...@@] ought to be honored as well,
which means that [@@...@@] probably *shouldn't* look line one
of our existing escapes:

    [@@
    $ ./a.out
    ''this is emphasized''
    [=''this isn't''=]
    @@]

So, we have to think about it a bit.  I think I have an idea of
how we can implement a "preformatted text with inline markup"
capability, but we really need a good markup sequence for it.

Pm