Re: [Phpwiki-talk] was <code></code>

[Steve W. <sw...@pa...>]

On Fri, 7 Dec 2001, Jeff Dairiki wrote:

> > *bold*
> > /italic/
>
> I'm becoming convinced, too.  That this syntax should be supported.  It
> certainly makes more sense than ''this'' (or '''''this''''').
>
> I'm a bit leary of the /italic/ syntax.  For one, I think the fact that
> slashes are common in file names and URLs might lead to more syntactic
> miscombooboos and ambiguities.  Also, I've never noticed that particular
> convention to be commonly used (in e-mails).  I always thought _this was
> italic_.

It has the unfortunate plus that it kinda /looks/ like italics right off
the bat. I just checked Ari's site and they use -bold- and /italic/.

> An inline markup for monospace would be nice, too, I think.

Hmm. Didn't we used to have this? Maybe I'm thinking of hacks I did at the
NYT.

> My vote goes with: *bold*, _italic_, =monospace=.

I like =monospace=, but I really like /italic/ and I know that means a lot
of trouble. When I was making PhpWikiSites two days ago, I found that
putting __ at the end of a URI caused a bug, since __ is valid in a URI.n

> To avoid many problems, I think these delimiters need to be snuggled up to
> words which they delimit.  This completely eliminates the ambiguity
> between opening and closing delimiters.  Opening delimiters are preceded
> by a space (or beginning-of-line, or certain punctuation), and followed by
> a word character.  Closing delimiters are preceded by a word characters,
> and followed by space, end-of-line, or punctuation.

Agreed, and that's how we've always done it, afaik..

> On the other hand, I also really like sticking with the standard HTML tags
> <b>bold</b>, <i>italic</i>, <tt>monospace</tt>.  (Even <em>, <strong>,
> <code>, etc... might be nice.)  I see no reason not to support (at least
> the first three of) these as well.  Many/most people already know them, so
> they're easy to remember.  They're easy to parse.

<b>it's</b> <i>not</i> <tt>quite</tt> <b><i>as</i></b> easy on the eyes,
but we do get the benefit of a large user base who already know html. (Oh,
if you have an HTML-reading mail client you might not see that. Sorry).

> Block-level markup is more of a problem, especially with our current
> line-oriented parser.  On the other hand lots of good ideas have been
> proposed:
>   o This should be recognized as a list.
>      o And this should be a nested list item.
>        This should be part of the same item.
>     And this should be part of the same level-one item.
>
> A definition list should looks like:
>    Term:
>        Definition.
>
> The problem with these: parsing is tricky (but certainly doable).  They
> clash with the current leading space means monospace, non-flowed markup.

In a sense the list syntax is block oriented. Couldn't <pre> use the stack
in the same fashion? i.e. it would need to see <pre> and then </pre> to
clear the stack.

> Speaking of which: who was it who recently said they were working on a new
> transform engine?  Is that still in progress?  I keep meaning to write a
> new transform engine myself, but whenever I start thinking about it, I get
> stuck when I can't find a PHP-ized version of yacc.

I don't recall anyone working on this... but line-oriented parsing is a
pain. It would make life easier if we did recursive descent parsing; it
would be even better if we stored the pages as xhtml, with only the links
dynamically added at serve time, which would reduce a lot of overhead.

> I'm not entirely happy with the plugin syntax, but haven't yet thought of
> a better alternative.

[plugin:foo param1 param2 param3... paramN] maybe? This would be a lot
like the other link schemes.

> Introducing new block-level constructs without using the eqivalent of
> <pre></pre> is really tricky.  (As demonstrated above, our current
> leading-space-means-non-flowed-monospace conflicts with pretty much any
> intuitive list markup.)
>
> In general (and I think you yourself may have said this some time ago)
> there's no point in reinventing HTML.  SGML/HTML/XML-like syntax is a bit
> verbose, but it's cleanly extensible, and it mixes fairly well with plain
> text.  As you say, the more features we add, the harder a clean syntax
> becomes.  I think there's nothing wrong with supporting some clean
> "e-mail-like" markup, as well as some HTML-like alternatives.  The fancier
> features, perhaps only need to be HTML-style.
>
> For example, I would say the introduction of '%%%' to mean '<br>' was a
> bad choice.  What's wrong with using '<br>'?  It seems much less likely to
> cause confusion.

At this point, where I am interested in evolving and extending PhpWiki, I
have no trouble with adding HTML tags. To this I will say: we need utterly
simple markup to make the Wiki super easy to use:

[snip]
I am making a *bold* link to my name: *SteveWainstead*. You can see my
project page [here | http://phpwiki.sf.net/]. Send me some email:
mailto:sw...@pa....
[snip]

I think that's about as basic as it gets: write plain text, make some
links, and a little emphasis. This will cover 99% of what users will do.
I'm bothered by /* this */ becoming italic bold though...

~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa