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

[Jo Rhett]

On Thu, May 25, 2006 at 06:23:54PM -0500, Patrick R. Michaud wrote:
> 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>
 
Yep.

> 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.
 
Not so much.  I've already rewritten most of the site to use the new
syntax, and have the added advantage of different background and borders
for the textblock areas.

Er... rather, yes.  Most of what you wrote it true, but I'm already kindof
past that.

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

I totally agree on special-case fixes, but I can't image that extra newline
being useful to anybody.  Clue me in if you can think of a reason why.

For a general case, do you have a syntax that disables putting <p> around
things?  Besides (:linebreaks:)?

> Those leading #'s shouldn't be treated as instances of the
> ordered list markup.

I've already fought that and found that a leading space can be internally
documented well enough for those.

> 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.
 
I'm willing to help, but already beyond it I think :-(  I'd rather focus on
removing those <p> tags if we can ;-)

-- 
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation