Talk.Proportional Font Nowiki Proposal

Being aware that Creole currently has a weak position about nested formatting: I would vote for being able to have emphasized parts within monospace programming code! It does help discussions to be able to highlight within a bigger, emphasized part.

Not sure if that's what Gregor means, but I wouldn't like markup in preformatted blocks. Or it should be a second kind of preformatted blocks. Otherwise, normal program listings would require way too much escaping.

This is normal text ##this is monospaced with a [[link]] and **emphasis**##.
This is {{{[[not a link]]}}}, ##{{{this is monospaced nowiki}}}##, but:
{{{
/** this is a normal comment, without any emphasis **/
# this is a comment
int main() {{{
z = "//this is not italic text//"
}}}
}}}

So, a preformated block is something different than ##monospace## font. To have formatting within a monospaced block of text, one has to use normal text:

Radomir, I'm affraid some of your examples aren't processed correctly by the current
engine of wikicreole. I could try to fix what I can, but I don't want to interfer with your
signed edits... Feel free to remove this paragraph if it becomes obsolete. -- YvesPiguet,
2007-Mar-16

I'd suggest to move suggestions on auto-enhancing to a page of suggestions for
implementers. This would include syntax coloring of preformatted blocks based
on heuristics similar to what the unix file command does, conversion of smileys
into images, copyright or TM symbols, and - dare I say - URL outside link markup. All
these features share a common characteristic: not implementing them doesn't hurt,
contrary to all other markup which looks like markup and has a larger effect on the
result.

Sorry for that, it should render ok now (if I got the escaping rules right :) ). There are several problems with using "normal", unix-like hashbangs: the path is not standard, some scripts use things like "#!/usr/bin/env python". Jus taking the last word is not an option too, as some programs will take more paramters. The scond problem is that not all languages use "#" for comments.

In case of MoinMoin the hashbang is completely artifical and is discarded when displaying -- it is part of the markup.

Not implementing the stand-alone urls has catastrophic effects: the "" in the urls gets parsed as italic text.

I like the escape character, because it is quick. If Wikis were not about being quick and comfortable, we should use decent xhtml and forget about this discussion. So I personally believe that having triple brace for preformatted block, double brace for neutral no-wiki span, and tilde for single character escape is not a clean design, but convenient and reasonable. I have worked for years on a TWiki where CamelCase cannot be turned off (as JSPWiki allows), discussing XML Schemata for biodiversity (i.e. tons of unintended CamelCase). With a single character escape it was hard enough, but with braces around every 10th Word or so I probably would have walked away.

Gregor, I moved your comment here, because it touches some things I'd like to discuss that I think better fit here.

Your proposal does have a certain appeal. It is easier to type in the most common case (nowiki text), has certain kind of internal consistency ("more" escaping markup to also retain spacing), plays nicely with block pre's. I like it, even when there are two problems:

we would have to change the markup for images

we would have no way of making monospaced and wiki-formatted text (unless we keep the "##" just for this purpose)

no-wiki-character = "the following character (including punctation) is not interpreted as markup"

pre = a no-wiki span where blanks and new lines are significant, rendered in non-proportional font

My priorities would be:

we need a pre-element (currently triple brace)

we need a no-wiki-span not affecting any formatting; fixed font in the middle of text looks stupid and creates undesired emphasis; also future creole versions may allow nested formatting! (I accidentially proposed double brace for this)

we need a no-wiki-character for convenience (currently tilde)

As to formatting non-pre text in non-proportional font, the most logical approach would be to have some markup for this. In my mind, the best approach for this would be to define some basic markup that then can be extended to cover a lot such special cases (including superscript, subscript, underline, fixed font, etc., see Extensible Formatting Element Proposal). However, at the moment, triple brace has two modes: on line of its own it is a proper PRE element, whereas when used inline, it acts as "no-wiki-plus-non-proportional font". Although making Creole slightly more complicated, this behaviour is fully logical and I see no reason to abandon it. I believe this addresses the second problem Radomir was mentioning. Is this correct?

Is this NotNew? Has anyone of you ever checked if other wikis are using a similar concepts, and how they do it? It makes no sense to introduce new markup into the spec before this has been checked. I therefore reject any changes until you give me figures...

This is about users being able to use and remember this particular creole language. Mixing elements from different languages in a creole language will not normally lead to illogical grammar, but the choice will be guided, and - typical for a creole language as opposed to a pidgin language - new concepts will be added that make the language internally consistent.

The current (0.5) inline nowiki seems to have a big problem, at least as it works in WikiCreole:
it prevents wordwrap. I can't find any reason why one would like a line with nowiki to overflow
in the right margin, be it with monospace or proportional font. Nonbreaking spaces might be
desirable, but their effect would be to cause a line break before the sequence, not after it.

This is really not the responsibility of the parser -- it depends on the client that actually displays the text -- in this case, it's defined in
the style sheets. The wiki parser cannot do anything with it -- it doesn't even know the width of the lines, you know.

Moreover, its purely presentational issue and doesn't affect semantics in any way -- I'd say it's definitely out of the scope.

By the way, you can see that line wrapping can be easily enabled in html pre blocks -- see the MoinMoin Creole Sandbox for instance.

Can you explain? I looked again, but I can't see anything special about line breaking or handling whitespace in the spec for nowiki. It's normal flowing text, just with markup ignored... or would you like it to be specified otherwise?

As you know I voted against this proposal in the Creole 0.6 poll. My problem might be that I don't see the use case other than adding code. I hardly (never) used the monospaced markup of JSPWiki because when I need it I do it for pasting in code, that also needs to be "nowikied", so I use the nowiki markup. Since it is almost my single use of it I don't like the idea of having to use 5 characters to achieve this. Maybe if you convince me that certain areas need monospaced font and at the same time need to have other markup trigger formatting quite frequently, then I could change my mind.

In most cases, you don't need nowiki, monospace is enough. Merging both makes a
special case authors must remember; if they need bold monospace, or a monospace link,
they must respect a special nesting order if monospace and nowiki are the same. Separate
markup provides a clean list of double-character sequences for style, easy to remember;
with a little effort for the implementation, strict nesting can even be relaxed, making styling
much easier for many authors.

There's another problem we have with the CreolePageFilter: Since the underlying markup does not separate monospaced and nowiki (nowiki will always be monospaced in JSPWiki), we cannot implement a nowiki that is not monospaced without changing the native engine parser. I wonder how many other engines/implementations would have this problem. JSPWiki however has a markup for monospaced, therefore a compromise would be to not specify if nowiki is monospaced or not, then it would be no problem for us to implement it like this: ##only monospaced with a link ABC##. Janne, what do you think? But that is just JSPWiki of course...

You can output just plain text without any markup, except for special characters which must
be escaped with a tilde if my understanding of JSPWiki is correct. That's where a robust escape
mechanism is useful: you implement the converter once and for all (escaping all characters
which might end up in markup), you don't have to track future changes in the list of markup.

Oh, I don't really care. Monospaced is really presentation, and nowiki is functional - in fact, the JSPWiki nowiki just happens to render monospaced 'cos that's what people expect, and there's separate markup for monospaced-but-not-nowiki. It's just a matter of small tweaking of the HTML and the CSS that the engine outputs...

Just to confuse things a bit further: JSPWiki does three kinds of markup: (block, nowiki), (inline, nowiki), (inline, wiki). Look at the source code of the following examples:

This is block, nowiki. __foo__ //bar//, rendered with a <pre>

This is inline, nowiki. __foo__ //bar//, rendered with a <span>

And, if there was a regular rendering engine, the following example would appear as (inline, wiki):

{{ This is inline, wiki. __foo__ //bar//, rendered with a <tt> }}

Maybe it would be useful to really distinguish between these four cases (and maybe add support for (block, wiki), something typically done with a <blockquote>).

Ok, just spoke with an enduser and they don't know what monospaced means, and they don't care because they don't know what ascii art is either. It would make life easier when writing addresses for them: You don't need the akward linebreak syntax all the time, I just fear that they will then put a nowikiblock over the whole article, just for the sake of linebreak as linebreak ;-). So having a separate markup for nowiki, and one for monospaced would make sense, as long as one can combine the both. Hope everyone will help me to convert the creole markup examples in the over 400 pages in this wiki from {{{XXX}}} to ##{{{XXX}}}## then ;-) -- The question is indeed how people can convert their pages in wikis where there was no separation so far?