[pmwiki] Re: [Pmwiki-users] Whitepaper about markup strategy

[Bernhard.Weichel at t-online.de]

kinhost, please note:
I do not propose to remove existing markup. Therefore the
discussion should focus the more complex things. Therefore
I do not answer for topics like ----

kinhost wrote:
>
> Also where [= turns a feature on and =] turns it off...that's very
> XML like. It's less flexible than XML for a reason: some people can't
> THINK within rules, they have to be handed the precise answers to
> their problems.  They don't want to have to think.  They know what
> they want the outcome to be and they want to be handed a method for
> doing it...instant gratification.

This is interesting. I personally like more to think than to remember.
Therefore everything starting with < is markup. No need to remember all
the special characters.

And wiki works because the authors look how others did it. If markup
is easy to recognize, then it is also easy to learn from others.

> Are you suggesting partial reworking?

Maybe of the implementation, not of the markup (perhapx except "abuse")

>
>>
>> Yes, so it should be /italic/ *bold* _underline_ */bolditalic/*
>
> However, this loses those symbols for other features.  The apostrophe
> is right under my pinky at all times.  I agree that when I type, I
> often

This *is* the problem. there are not enough rarely used characters
for the amount of features we want.

>
>> indented paragraph
>> which is simply indented
>
> Is that <space>Text
> Do you use two spaces before the text to indent twice?

no, I won't. If nested indented paragraphs are desired, then again

.b_indent
  bla bla
.e_indent

appears more handsome to me.
BTW, markup in lines of its own makes it easier to add it later to
existing text.

> I think this is bad...people have a habit of hitting the spacebar.
> Did I mention monkeys writing Shakespeare?  I guess the monkeys can be
> trained...but I don't know...
>

Agree


>> would be easier to recognize than
>>
>>>> indented paragraph which is simply indented

>> is not more difficult to read as it is now
>>
>> .b_pre
>> this is program code
>>   and this is also program code
>> .e_pre
>
> This one makes some sense, but I don't care for your particular
> method of coding it with the period in front.

I don't care of *period* either, but of an explicit markup syntax.

>> would help out for advanced list requirements.
>
> I would only want this --if it were to be implimented at all -- for
> advanced list requirements.  I think the * should remain.  This is
> already too
> complex for most folks.  Bullet lists are far too common, especially
> with WikiTrails being mixed in with them...keeping them exceptionally,
> idiotically, simple is important.

I agree and I have really problems with the *. For me it is not powerful
enoguh.
Ofcourse it should remain but complemented.

>> eg. I never know is it one [ or is it two [

> Then perhaps the documentation needs to be clarified, and a condensed
> cheat sheet developed that makes these more advanced features
> absolutely bluntly clear.  It doesn't mean there's a flaw in the
> markup, it means there's a
> flaw in the documentation or in someone's understanding of the markup.

As we all know, users do not tend to read documentation either. So if
markup comes to a few principles ...

> to explain intermediate-to-advanced features to users, or the users
> simply wouldn't USE this markup -- which means it's a waste of
> programmer's time/efforts to install the features.  At least for *my*
> wikis.

Those who want to do more amitious stuff, they come either and ask ...

>
>> So for medium complex web sites, IMHO PmWiki is a much better
>> approach than full blown CMS.
>
> But does PmWiki need to become a fully featured CMS, or is it
> customizable that you can do the additional programming for the
> features you need as a CMS?
>

Correct, but as of now, I cannot add e.g. XML style markup without
hacking pmwiki.php.

And also If I customize special markup, how can I be sure, that
future development of PmWiki uses the same markup for other features.

--b