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

[Adam S. <ad...@pe...>]

warning: lots of opinions from someone that doesn't program follow ...

> 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).

for files so long as it's <whitespace>/italic text/<whitespace> it should
be okay shouldn't it?  files/directories might have a space in them but
they shouldn't start or end with a space.

> I always thought _this was italic_.

i always thought that was underline ;)

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

yes please, though i still think monospace should turn off wiki words (but
i can use <pre> for that now.

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

that'll work well i think, i think /italic/ is clearor to someone that
hasn't seen it before but i don't think it really matters that much.

> 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.

i'm not sure allowing the opening tag should allow anything but whitespace
or a new line immediately before it.  i think this sorta thing is asking
for trouble.  or am i misunderstanding?

blah.*bold* text.
/*fake comment*/

but i do think the closing one needs to allow end of line or punctuation
)]!?.,"'`} is all i can think o f that might be valid.  this allows:

*bold text*!
test (stuff *in bold*)
stuff "*in bold*".

> 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.

i would like it if this was configurable, i'd enable it on my personal
wiki cause it makes cut'n'paste easy, but on public/community wiki's i
think it would be a bad thing cause now you have mixed syntax and the
"wiki way" is simpler and faster for everyone but you're always gonna have
someone that uses html tags cause they know them.

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

yah, again it would be nice if eventually this was a legacy option which
was disabled by default but could be enabled if needed.

> 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.

this is how moin does it.  lists must start with a leading space, and
instead of multiple *'s for nested list item's you use multiple spaces.

it works great but it's very confusing to new comers.

* this
** seems to make
*** more sense to people.

> The problem with these: parsing is tricky (but certainly doable).
> They clash with the current leading space means monospace, non-flowed
> markup.

i would love to see the leading space meaning monospace die.  lets use
<pre> instead.  the leading space meaning monospace makes cut'n'paste
hell.  i also think it's really unintuitive to newbies.

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

fwiw, moin's syntax for plugins (macros) is [[plugin(options]] and twiki
uses %PLUGIN{options}%.

which reminds me, i'd really like it if [this is a link] went a way.  i
use that all the time in text.  maybe have a link be [[this is a link]] or
["this is a link"].

> The fancier features, perhaps only need to be HTML-style.

i think that probably makes sense so long as we can avoid security issues
like cross site scripting.

> 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.

that makes sense, when i started using moin they used [[BR]] and it took
me forever to figure out that was they way to put in a line break.  where
there isn't a good wiki alternative, why re-invent html?

adam.