[pmwiki-users] Unwanted carriage return with pagelist template

[Patrick R. Michaud]

On Tue, Mar 27, 2007 at 11:00:25AM -0700, Martin Fick wrote:
> --- "Patrick R. Michaud" <pmichaud at pobox.com> wrote:
> 
> I can see how the (:if:) would seem daunting to
> anyone, but couldn't that be solved by simply
> appending an (:if:)\ to any PLT output?  

Do you mean manually or automatically?  If manually, then
it really needs to be  (:template each:)(:if:)  or
(:template last:)(:if:), and when it doesn't work the
answer isn't obvious to the pagelist template author.
If we do it automatically, then what do we do when
someone wants the pagelist to perform the condition?

> As we have seen, I think that users expect to be able
> to make things like a table span a PLT and seem more
> confused when they don't.  

Actually, I'm not sure we can draw this conclusion, at
least not for a majority of users.  We may be seeing that
(:pagelist:) is working the way most expect it to, and
thus we don't get questions about the things that would
stop working if we switched to this other interpretation.

> Are there other such known issues that would not work
> the way users would expect it?

I know that in the first couple of designs for pagelist
templates I had it return the markup to the original page,
but then I quickly switched it to avoid the (:if:) issues,
as well as to allow nested divs and tables (based on feedback
from others on the list).

> > The vast majority of uses for pagelists produce
> > block  markup, not inline markup.  So I take the
> > position that inline is the special case (and will be
> > for the foreseeable future), and therefore this 
> > special case should have the special tags.
> 
> Could you explain that to me, maybe I don't understand
> why block markup would specifically be wanted in most
> cases?  As an author, I just want the PLT text to be
> inserted in place of the (:pagelist:) directive. 

A lot of people will expect any divs, tables, conditional
blocks, or other structures inside of a pagelist to be
automatically closed by PmWiki, as opposed to requiring
an explicit close.

> Would all of the current default templates not work if
> the surrounding <block> were removed?  

I don't know if you mean "removed" or "stripped" here.
When I refer to eliminating the other block from the output, 
I simply mean providing an option such that it isn't automatically
added by the plt code.

Also, we have two separate issues at play here:  (1) whether
the result of a pagelist template gets a surrounding tag
such as <div> or <span>, and (2) whether the markups inside
of a pagelist template are automatically "closed" at the
end of the template.

But to answer your question -- yes, some templates
(including current default) templates would break if
the surrounding <div> tags are removed, because there
would then be no place to hang the class= attribute.

> Also, where do
> the surrounding <p> </p>s come from? I figured it was
> just from the fact that the template creates new
> lines, or is it an artifact of the "inlcude"?  

Neither.  Any line of markup text that doesn't have
any other form of block markup is automatically treated
a paragraph.  Thus, if the markup resulting from
a pagelist template is a simple string (such as "4"),
PmWiki's markup engine treats it as a paragraph
and adds <p>...</p> tags around it.

> Could you also help me understand why they can't be removed
> along with the surrounding <block>, is it because it
> would break all the current templates? 

It's because we don't yet have a markup that can be used
to indicate that a line of otherwise unmarked text isn't
to be rendered as a paragraph.  (Paragraphs in PmWiki
aren't defined by carriage returns -- they are simply
consecutive lines of text without any markup that turns
them into something else.)

Pm