phpwiki-talk

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

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

I hit reply to the wrong email... for those following this thread...

---
                  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
---------- Forwarded message ----------
Date: Fri, 7 Dec 2001 00:14:53 -0500 (EST)
From: Steve Wainstead <sw...@pa...>
To: Jeff Dairiki <da...@da...>
Cc: car...@ma..., php...@li...
Subject: Re: [Phpwiki-talk]
    =?iso-8859-1?Q?Re:_[Phpwiki-talk]_3-single_quotes_and_5-single_quotes_broken
    =3F?=


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 think are two examples. Ali's reasoning was the marked up page language
should be as easy to read/understand as the rendered page.

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'd like to see some proposals that are consistent with our current
syntax, or some way that would be compatible with NBTSC syntax.

~swain

On Thu, 6 Dec 2001, Jeff Dairiki wrote:

> Carsten Klapp said:
> >
> > 3-single-quotes (bold) and 5-single-quotes (bold-italic) seems
> > completely  broken now. Is this a known problem or is it just me?
>
> I think that's been broken (or rather "never implemented") since Arno's new
> transform code last winter/spring...
>
> I don't suspect it would be hard to add.  Is there really a need?
> (Leading-tab-delimited lists, I think, are also not currently working in
> 1.3.)
>
>
>
>
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

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


_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

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.

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.

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

[Phpwiki-talk] New formatting engine (was <code></code>)

[Carsten K. <car...@ma...>]

I don't see a need to bring back tabs or the quotes, I just noticed that 
some text copied from c2 didn't format correctly when I pasted it into my 
own Wiki. Besides it's too difficult to figure out what combination of 
multiple nested quotes will give the formatting I want.

There are some notes somewhere that imply PhpWiki syntax is fully 
compatible with other Wiki syntax, either in the docs or somewhere on the 
web site. I'll look for it again and see if it needs rewording. The 
TextFormattingRules page and TestPage should be updated too. It does say 
the quotes are buggy but if they're not going to be reimplemented it might 
as well say that all of the old quote syntax isn't supported anymore.


I like the *bold text* and _italic text_ email tags.
  - Underscores have also long been used to represent italicized text in 
traditional type-written text for book manuscripts and movie scripts, they 
are later converted to italics when typeset and published.
  - I've seen emails using slashes for italics but not many (maybe 2), and 
then there is also ~italics~.
  - Slashes are too common in filename paths and URLs nowadays.
  - Now that we've moved away from typewriters, bold and italic text are 
readily available to everyone. So underlined text is used mainly to 
indicate link-text and sometimes for headings.

I agree with Jeff on the %%%. Personally I think it was a bad choice, even 
if it was arbitrarily chosen for lack of something better which didn't 
conflict with existing code. I don't have a better suggestion, and I'm 
reluctant to use or encourage use of too many html <tags> in WikiMarkup. 
HTML is very anglo-centric, and too distracting to read and edit when 
there is a lot of it.

Another bad choice I think is the use of !, both for headings and for 
!DontLink. One limitation I've run into is only 3 levels of headings. 
While heading levels 4, 5 and 6 are not frequently used outside of 
documentation or other published material, they are supported by html. Is 
anyone else here interested in seeing 4 (or more) heading levels?


Setext uses a very similar and intuitive text-only markup. Many mailing 
lists and faqs use(d) the setext format, mostly prior to the advent of 
html, and there are still digest viewing software available for parsing 
this format.

I do really like the setext format, and I'm not necessarily proposing to 
fully implement setext markup in PhpWiki. A lot of thought has been put 
into the format and there might be some ideas or markup rules we can take 
from it.


If you want to read more about setext send a blank email to setext@tidbits.
com for an automated reply. It's a bit dated but still interesting.

Some excerpts from the document you'll get:

   Setext, on the other hand, has been _optimized_
   for reading directly by human eyes on what probably is still the
   lowest common denominator of today's computer hardware, an 80-
   character by 24-line terminal screen.

   the setext format relies
   solely on the presence of _implicit_ typotags, carefully chosen
   to be as visually unobtrusive as possible.  The underlined word
   above is one such instance of the defacto "invisible" coding.
   Inserted typotags will at worst appear as mere "typos" in the text.

Some markup examples:
**bold words**
_underlined words_
hotword_ (sparingly used, can be indicated by shadow text, colored etc.)
some_hot_words_
~italic words~
(C) copyright
(R) registered trademark
(TM) trademark
' -- ' emdash (no quotes)

   Heading
=========

   Heading
---------

<urls and emails>

..comment lines are suppressed by
..lines starting with twodot tags
..

Unix setext viewer (source code, with a **man page in setext format 
showing some tables**)
http://www.etext.org/Zines/ASCII/InterText/ascii/setext-
viewers/setext-viewer-05-unix.uu

Other setext software and examples: <http://hospex.org.pl/setext-
clients.html> (some links here are broken)
Another setext example: <http://hospex.icm.edu.pl/which-spec.html>

Carsten


On Friday, December 7, 2001, at 10:37  am, Jeff Dairiki wrote:

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

Re: [Phpwiki-talk] New formatting engine (was <code></code>)

[Sergio A. K. <ser...@ho...>]

[snip]

in my wiki I use:

**bold text**
//italic text//
__underlined text__

I think is the more intuitive way, and the more known
to those people who use text/plain email...

/sergio

Re: [Phpwiki-talk] New formatting engine (was <code></code>)

[Gary B. <ga...@in...>]

On Fri, 7 Dec 2001, Carsten Klapp wrote:

> One limitation I've run into is only 3 levels of headings.  While
> heading levels 4, 5 and 6 are not frequently used outside of
> documentation or other published material, they are supported by html.
> Is anyone else here interested in seeing 4 (or more) heading levels?

A nice way to do this is without breaking everything is to `normalise' the
headings during parsing. The biggest heading (ie the most !'s) you use
should be h1, the next biggest h2 and so on; if you use more than 6
different sizes then the smallest ones all get set to h6.

A variation would have the biggest heading set to h2, since h1 would 
generally be used in the template for the page's title...

Cheers,
Gary

[ ga...@in... ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]

Re: [Phpwiki-talk] New formatting engine (was <code></code>)

[Carsten K. <car...@ma...>]

Normalizing the headings sounds awesome! My vote goes to the second 
variation.

Carsten

On Saturday, December 8, 2001, at 09:55  am, Gary Benson wrote:

>
> On Fri, 7 Dec 2001, Carsten Klapp wrote:
>
>> One limitation I've run into is only 3 levels of headings.  While
>> heading levels 4, 5 and 6 are not frequently used outside of
>> documentation or other published material, they are supported by html.
>> Is anyone else here interested in seeing 4 (or more) heading levels?
>
> A nice way to do this is without breaking everything is to `normalise' the
> headings during parsing. The biggest heading (ie the most !'s) you use
> should be h1, the next biggest h2 and so on; if you use more than 6
> different sizes then the smallest ones all get set to h6.
>
> A variation would have the biggest heading set to h2, since h1 would
> generally be used in the template for the page's title...
>
> Cheers,
> Gary
>
> [ ga...@in... ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
>