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