Plim doesn't respect mako's ## comments properly.

[mfeif]

I know that Plim has it's own comment feature ( / ) but ignoring Mako's commenting symbols ( ## ) means that you have to change the mako files to work with plim. Normally, that's no big deal, since plim supports its own versions of what mako does, and in your documents, you can just use plim's /

But it means that we can't put comments in inherited or namespaced files, which may NOT be plim files, but are "pure" mako files.

For example, I have a helpers.mako file that contains some things I want to pull into other documents/templates. So far, so good; I can grab these through standard Mako tools, either in pure mako or in plim.

But if I want to put a comment in that PURE mako file, plim doesn't respect it. The below will output both sets of text if plim is used as a pre-processor on documents that inherit this block and use it. It seems to want to make a div with the id "#" which is non-sensical (and perhaps invalid html) but makes sense according to the #myid use case.

<%block name="something_to_use_elsewhere">
<p>This should be here.</p>
## But this should not.
</%block>

renders as

<%block name="something_to_use_elsewhere">
<p>This should be here.</p>
<div id="#">But this should not.</div></%block>

And if I change the ## into a / to suit plim, then I have invalid mako, and other code can't use it. Well, not invalid, but again, it's not interpreted as a comment.

What's weird is that in the docs here http://plim.readthedocs.org/en/latest/en/syntax.html#new-style-blocks it uses a # to make a comment in the generated mako code, but not at the beginning of a line.

I don't see anyplace where ## is already used by plim, can we make it either pass through, or ... something? Losing <div id="#"> doesn't seem so bad ;-)

tl;dr, can we have mako comments back?

[mfeif]

I just noticed that plim also chokes on this valid mako markup:

<%
    a = "this is python"
%>

:-(

The docs say "As all mako tags start with the < char, which indicates a raw HTML line, they all can be written “as is”. The only thing you must remember is to manually close the pair tags." But no: much of mako starts with %, including loops, conditionals, and what I'm finding now: %> Also, ${thing} but those work.

[avanov]

I should have clarified it better in the docs.

When you create a mako template lookup object (or just a Template object) with a plim preprocessor, Mako uses that preprocessor for preparing mako markup from every single template involved in rendering the final output (i.e. parent files, included files etc.) There is no way, as far as I know, to turn off the preprocessor for some specific files we'd like to treat as plain mako markup that do not require preprocessing.

Unfortunately, Plim itself does not provide transparent compatibility with plain Mako markup. It only supports "row-level tolerance", i.e. you are allowed to start a line with a plain HTML tag, or any Mako tag that looks like a html tag (basically, Plim refuses to parse a line that starts with the < character and outputs it "as is").

As for # in new-style python blocks, the reason why the comment appears in mako markup is precisely because it is allowed to put Python code right after the block indicator ---:

--- x = 1

and

-------------
    x = 1

So, if you put # my comment instead of x = 1 right after the ---, it will appear in the resulting mako template.

[mfeif]

I understand, but both:

#

and

%>

and

% for
% if
% endif

etc are row-level mako "tags", not just python tags inside of mako tags (as in the case of #).

The behavior of ignoring anything that starts with < should also be extended to ## and % maybe? Then it would work as you say in the docs, passing through mako like it passes through html.

[avanov]

The primary difficulty with %> is the following case:

<%
a = "this is python"
%>

In order to parse the line a = "this is python", Plim would have to use Python AST, because it would have to find %> somewhere after <% and omit cases like:

<%
a = "%>"
%>

and (incorrect case for Python AST):

<%
a = "%>"%><%
b = "another block"
%>

I don't remember exactly where I had stopped last time trying to implement it properly (it was quite a long time ago), but there was something else not clear to me.

[avanov]

As for ## sequence, I think there's no harm in adding it. It's just that I've never needed it.

If you can make a PR, feel free to do it. Or wait for me - I may have some spare time later this week.

[mfeif]

I'm afraid I've never written a parser, so I don't know the full implications of adding these exceptions, but I think I grok what you are saying; hard to find the close tag, since it could be inside of python or inside of strings.

Can the fact that the mako closing tags have to appear at the beginning of the line help?

It just seems that your intention was to allow full mako pass-through, but not having either python blocks or control/looping structures is a biggie. To have to change all existing mako into Plim is not trivial, but not hard, of course.

Both of these perfectly valid and not-edge-case mako constructs crash plim:

% if True:
    Say this thing.
% else:
    Say this other thing.
% endif

<%
    # this is some python
    a = "this is some python"
%>

I know, at this point, I should put up or shut up, but I suppose I'm exploring whether you are philosophically opposed to this. And as I said, I don't know how to write a parser, though I gather that plim is very smart in that it worries primarily about what happens at the beginning of a line and on indentation to determine what to do.

What if plim recognized these few more cases when it should bail and pass through the text un-changed? All of these only when at the beginning of a (perhaps indented) line:

%> %

(these two are necessary, but already work) <% <%!

I think that would get us pretty much to "full mako pass through".

[mfeif]

I realize I didn't answer your point about the python parsing... There would be no need to search within the body of a python construct for "%>" because this is not valid mako:

<%
    # this is some python code, and I want it to end weirdly in the middle of a line, so...
    a = "My favorite string"
    b = a * 3  %>

Similarly, this is invalid:

% if a > 5:
    b = a * 5   % else:
    b = a
% endif

So once a parser saw a line beginning with those things, it can skip lines till it sees the closing thing. Right?

[avanov]

Let's keep it open for a while.

[mfeif]

Hey there. It's been a while, wondering if there is any news, or interest in discussing my proposed solutions above.

Thanks!

[avanov]

Hi @mfeif ,

to be honest, I totally forgot about it due to my move to another country last year. I don't object to have those features in Plim. Unfortunately, it's again not the best time for me to handle it - right now I'm in the middle of changing my job. I'm really sorry for such inconvenience.

Sometimes open source maintenance policy is that bad :)

[mfeif]

I totally understand! :-)