phpwiki-talk

[Phpwiki-talk] NewTextFormattingRules, DynamicTextFormattingHelp

[Matti A. <ma...@ik...>]

Hi all,

After getting frustrated with the lack of integrated help page on new 
markup rules, I created a tentative help page for it. Please get it 
from http://mairas.net/wiki/NewTextFormattingRules.

I don't know if it's considered kosher for PhpWiki, but to go with the 
new help page, I also created a DHTML thingy, which automatically 
changes the shown instructions according to the selected markup 
version. The patch and compatibility notes are available at 
http://mairas.net/wiki/DynamicTextFormattingHelp.

Best regards,

m.

Re: [Phpwiki-talk] NewTextFormattingRules, DynamicTextFormattingHelp

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

Hi Matti,

The NewTextFormattingRules you made looks super, I'd like to see it 
just replace the current TextFormattingRules page.

The dynamic switching of the help at the bottom of the edit page is 
very neat! :) I believe many old rules are probably being phased out 
completely so a dynamic help blurb won't be necessary in the end.

Comments from anyone else on the list?

Cheers,
Carsten

On Wednesday, November 6, 2002, at 08:27  pm, Matti Airas wrote:

> Hi all,
>
> After getting frustrated with the lack of integrated help page on new
> markup rules, I created a tentative help page for it. Please get it
> from http://mairas.net/wiki/NewTextFormattingRules.
>
> I don't know if it's considered kosher for PhpWiki, but to go with the
> new help page, I also created a DHTML thingy, which automatically
> changes the shown instructions according to the selected markup
> version. The patch and compatibility notes are available at
> http://mairas.net/wiki/DynamicTextFormattingHelp.
>
> Best regards,
>
> m.

Re: [Phpwiki-talk] NewTextFormattingRules, DynamicTextFormattingHelp

[Reini U. <ru...@x-...>]

Carsten Klapp schrieb:
> The NewTextFormattingRules you made looks super, I'd like to see it just 
> replace the current TextFormattingRules page.
> 
> The dynamic switching of the help at the bottom of the edit page is very 
> neat! :) I believe many old rules are probably being phased out 
> completely so a dynamic help blurb won't be necessary in the end.
> 
> Comments from anyone else on the list?

I like DynamicTextFormattingHelp a lot!
Just a note on the text:
Tables in new markup can be formatted with the new OldStyleTablePlugin.

> On Wednesday, November 6, 2002, at 08:27  pm, Matti Airas wrote:
>> After getting frustrated with the lack of integrated help page on new
>> markup rules, I created a tentative help page for it. Please get it
>> from http://mairas.net/wiki/NewTextFormattingRules.
>>
>> I don't know if it's considered kosher for PhpWiki, but to go with the
>> new help page, I also created a DHTML thingy, which automatically
>> changes the shown instructions according to the selected markup
>> version. The patch and compatibility notes are available at
>> http://mairas.net/wiki/DynamicTextFormattingHelp.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] NewTextFormattingRules, DynamicTextFormattingHelp

[Matti A. <ma...@ik...>]

On Thursday 07 November 2002 12:42, Reini Urban wrote:

> I like DynamicTextFormattingHelp a lot!
> Just a note on the text:
> Tables in new markup can be formatted with the new
> OldStyleTablePlugin.

Thanks for the compliments! NewTextFormattingRules page was locked for 
no good reason, so now you can make changes yourself as well. Of 
course, I'll refine the page according to your suggestions, just not 
right now. Must... write... thesis...

m.

Re: [Phpwiki-talk] NewTextFormattingRules, DynamicTextFormattingHelp

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

> http://mairas.net/wiki/NewTextFormattingRules.

Very good.

Some things which might be worth adding:
  
  Named anchors:
     #[foo]       An anchor around the text "foo" with id "foo".
     #[|foo]      An empty anchor with id "foo". 
     #[howdy|foo] An anchor around the text "howdy" with id "foo".
  References to name anchors are made thusly:
     [#foo], [OtherPage#foo], [named|OtherPage#foo] ...

  The new "nestled" emphasis:  *bold*, _italic_, and =monospace=.
  (I think ''emph'' and __strong__ are quasi-deprecated.)

  The old-style list markup works (more or less) as before.
  I'm not sure whether this is worth mentioning on the page or not...

 
> http://mairas.net/wiki/DynamicTextFormattingHelp.

Also very cool!  I see no problem with DHTML (we already use javascript
other places as well) as long as it degrades reasonably for people with
older browsers (or with javascript disabled).

Currently, in older browsers, I think your patch shows both old and new
help messages.  I'm not sure whether that's the best thing to do in this
case...  (pros: all the info is there; cons: cluttered, confusing...)
Comments?

Re: [Phpwiki-talk] NewTextFormattingRules, DynamicTextFormattingHelp

[Reini U. <ru...@x-...>]

Jeff Dairiki schrieb:
>>http://mairas.net/wiki/DynamicTextFormattingHelp.
> 
> Also very cool!  I see no problem with DHTML (we already use javascript
> other places as well) as long as it degrades reasonably for people with
> older browsers (or with javascript disabled).
> 
> Currently, in older browsers, I think your patch shows both old and new
> help messages.  I'm not sure whether that's the best thing to do in this
> case...  (pros: all the info is there; cons: cluttered, confusing...)
> Comments?

Add it to CVS.
-- 
Reini Urban

Re: [Phpwiki-talk] NewTextFormattingRules, DynamicTextFormattingHelp

[Martin G. <gim...@gi...>]

Jeff Dairiki <da...@da...> writes:

>   The new "nestled" emphasis: *bold*, _italic_, and =monospace=. (I
>   think ''emph'' and __strong__ are quasi-deprecated.)

There's a problem with this markup: it only works when there's a space
after the closing *, _ or =. So your example doesn't work as you typed
it - you have to type it like this:

  *bold* , _italic_ , and =monospace= .

Which, of course, looks awful because of the spaces before ','...

Also, why is the underscore used for italic? I've always thought that
one used /slashes/ for italic and _underscore_ for underlining. At
least that's how Gnus pretty-prints my mails, and it also seams more
logical to me.

I changed the Markup_nestled_emphasis class so do the markup like
this, but I'm afraid that it will change something else, because I
changed the huge regular expressions (which I didn't understand fully)
to much simpler versions... Perhaps someone could explain, what all
the look-ahead and look-behind does?

The changed class is this:

class Markup_nestled_emphasis extends BalancedMarkup
{
    var $_start_regexp = '[*_=\/]';

    function getEndRegexp ($match) {
        return "\\" . $match;
    }
    
    function markup ($match, $body) {
        switch ($match) {
        case '*': return new HtmlElement('b', $body);
        case '_': return new HtmlElement('u', $body);
        case '=': return new HtmlElement('tt', $body);
        default:  return new HtmlElement('i', $body);
        }
    }
}


-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

Re: [Phpwiki-talk] NewTextFormattingRules, DynamicTextFormattingHelp

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

On Thu, 07 Nov 2002 21:30:45 +0100
Martin Geisler <gim...@gi...> wrote:

> There's a problem with this markup: it only works when there's a space
> after the closing *, _ or =. So your example doesn't work as you typed
> it - you have to type it like this:
> 
>   *bold* , _italic_ , and =monospace= .

Okay, that's a bug.  I'll look at it.  As you point out, the regexps
are hairy.
 
> Also, why is the underscore used for italic? I've always thought that
> one used /slashes/ for italic and _underscore_ for underlining. At
> least that's how Gnus pretty-prints my mails, and it also seams more
> logical to me.

This was discussed at length awhile ago.  It seems everyone has their
own ideas on the precise meaning of the the possible emphasis characters.

A problem with slashes as delimeters is that slashes commonly occur
as parts of filenames.  (E.g. on unix systems, config files are kept
in /etc/.)

When used in ascii email, it's easy for all to agree that all these
things are some form of emphasis --- exactly what sort of emphasis 
each corresponds to is subject to disagreement...

I think it's fairly non-controversial to assert that *this* and _this_
are (by far) the most commonly used forms of emphasis in e-mail.
Therefore, my feeling is that these should correspond to bold and italic
emphasis, or vice versa...

> The changed class is this:
> 
> class Markup_nestled_emphasis extends BalancedMarkup
> {
>     var $_start_regexp = '[*_=\/]';
> 
>     function getEndRegexp ($match) {
>         return "\\" . $match;
>     }
> }

The "nestled" in nestled emphasis means that the delimiters have
to be properly nestled at (some sort of) word boundaries.
The opening delimiter must have no space between it and the
beginning of the first delimited word, and correspondingly
there must be no space between the last delimited word
and the trailing delimiter.

Re: [Phpwiki-talk] NewTextFormattingRules, DynamicTextFormattingHelp

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

On Fri, 8 Nov 2002 12:46:23 +0200
Matti Airas <ma...@ik...> wrote:

> >   Named anchors:
> >      #[foo]       An anchor around the text "foo" with id "foo".
> >      #[|foo]      An empty anchor with id "foo".
> >      #[howdy|foo] An anchor around the text "howdy" with id "foo".
> >   References to name anchors are made thusly:
> >      [#foo], [OtherPage#foo], [named|OtherPage#foo] ...
> 
> OK, added. I actually tried to get them work already while writing the 
> documentation in the first place, but couldn't figure out how they 
> work. :-)
> 
> I'm still wondering about the anchor generation, however. Shouldn't it 
> be automatic, so that headings and maybe some other special markup (or 
> maybe three first words of each paragraph) would be automatically 
> anchored? That would make it easier to refer to some arbitrary text 
> passages such as 
> http://mairas.net/wiki/NewTextFormattingRules#References (doesn't work 
> yet).

Either of those suggestions is certainly doable, but my concerns are:
  1. They can lead to very unnecessarily long anchor names.
  2. Duplicate anchor names are possible.
  3. It might be too much magic.

Example:

!! #[References]

is explicit.  Everyone can see that there's something special
about "References" (even if they're not sure what it is.)

> >   The new "nestled" emphasis:  *bold*, _italic_, and =monospace=.
> >   (I think ''emph'' and __strong__ are quasi-deprecated.)
> >
> >   The old-style list markup works (more or less) as before.
> >   I'm not sure whether this is worth mentioning on the page or not...
> 
> OK, I removed traces of old-style markup and made the page use new 
> markup only. At the moment the page is quite badly broken, but it can 
> be thought of as a test case. :-)

Upon second thought, maybe the old-style ''emphasis'' __isn't__
deprecated.

> > Currently, in older browsers, I think your [DynamicTextFormattingHelp]
> > 
> > patch shows both old and new help messages.  I'm not sure whether 
> > that's the best thing to do in this case...  (pros: all the info is 
> > there; cons: cluttered, confusing...) Comments?
> 
> This was my intention, although I agree it might not be ideal behaviour.
> 
> However, at least for some time the majority of existing pages are 
> written using OldMarkup, and it would be very confusing to edit them 
> without any kind of reference. Maybe it would be safe to assume that 
> people using browsers with Javascript disabled or without proper DHTML 
> support would be advanced enough to be able to handle the UI 
> degradation? Or is there still a significant amount of corporate 
> Netscape 4 users to worry about?

Other concerns are: lynx, links, emacs-w3, etc...
Not a big deal
> Given an unlimited amount of headache pills, I could try to implement 
> support for IE 4 and Netscape 4, but I'd rather not (those proprietary 
> DOM implementation deserve to die).

I agree completely.  It's not worth the effort or code clutter to fix
those cases.