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

[Jeff D. <da...@da...>]

On Fri, 7 Dec 2001 00:17:57 -0500 (EST)
"Steve Wainstead" <sw...@pa...> wrote:

> I'd like to move (again) to a syntax like the NBTSC Wiki, which is in
line
> with suggestions by many users over the last two years. Ali went for
> syntax that is a lot like how people do things in plain text elsewhere:
> 
> *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_.

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

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

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.

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.

(In addition, we could support the current ''italic'' and __bold__ (at
least for awhile), since none of these syntaxes clash.)



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.


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.


> Now, the one thing that has troubled me about both the plugin syntax and
> the proposed plain text tags is they are not consistent with the markup
to
> date... and inconsistency is not good for the user. As PhpWiki grows in
> features, though, I understand it gets harder to maintain consistency.

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

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.