Revision history for WantedFormatters


Revision [19735]

Last edited on 2008-03-25 14:03:21 by RobertLeckie
Additions:
~& I needed this on my site so I made this [[InlineDivFormatting little hack.]] It allows some basic controls, but is inline so you get to use all the other parts of the wikka markups

Revision [19241]

Edited on 2008-01-28 00:14:44 by NilsLindenberg [Modified links pointing to docs server]
Additions:
I created this page to list proposals about [[Docs:FormatterInfo formatters]] that might be implemented in future Wikka releases.
Deletions:
I created this page to list proposals about [[FormatterInfo formatters]] that might be implemented in future Wikka releases.

Revision [17036]

Edited on 2007-05-31 23:27:49 by NilsLindenberg [Reverted]
Additions:
~&While I agree on "preformatting" things like signatures and possibly "typographical sharpness", escaping ampersands before test is stored will make source harder to edit for people who don't know HTML - unless you also are going to 'unescape' each time the edit form is displayed. It's simpler and more logical to 'educate' the formatter to escape this special character as it's //already// doing for < and >. ''I've already written (and tested) the code to do this (excluding entities); this will probably become part of the next (1.1.6.1) release.'' -- JavaWoman
===Inline comments formatting ===
See InlineCommentFormatter
-- DarTar
===User-oriented formatters===
Beside better formatters for tabular data (see below) I think it's time to consider implementing some features that are largely requested by wiki users: //footnotes// and //tables of content//. (see below the discussion on named anchors)
~&See also the TableofcontentsAction page (work-in-progress!). --JavaWoman
===Table formatters===
A good wikka syntax for tabular data is IMO one of the top priorities for future Wikka development. Some [[WikkaTables ideas]] have already been suggested.
===More ##<div>## formatters===
I find quite limiting that Wikka only includes formatters for flush-left and flush-right divs. I would like to see a larger set of formatters, that - in association with CSS selectors - might be used to output //absolute-positioned// divs, //bordered// divs, divs with different degrees of //padding/margin// etc.
===System formatters===
<<See: WikkaMenulets<<::c::
It might be interesting - in the spirit of the ##""{{lastedit}}""## and ##""{{version}}""## action - to have a set of formatters for printing specific system-related information (GmBowen has also recently suggested something in this lines). I am not sure, though, whether this function should be implemented as a set formatters or as an action.
~&In the same spirit, I just created a ##[[HighlighterAction {{highlighter}}]]## action that creates a nice overview of available syntax highlighters. More system-related actions are in the pipeline (such as one that will display documentation for all available actions, provided the actions have a standardized documentation block at the start: self-documenting code!). --JavaWoman
===In page links===
It would be nice to have in page linking so you can jump directly to a section of a page in the format ""PageName#Section"" you could then reuse the Wacko ""{{ancher}}"" action to inset the ""<a name="Section"></a>"" code.
~&Dave, I cut and paste here a related discussion that was going on on ValidPageNames -- DarTar
~~&We could simply have the Formatter generate an ID for every heading (based on the heading's text) - no need for any action - you'd automatically have your anchor targets, in every page, and they'd remain consistent even if you re-arrange sections. All you need then is a link syntax that allows fragment identifiers (I'm not sure that works now). --JavaWoman
~~~&See also the TableofcontentsAction page (work-in-progress!) - indeed, no need for an action to create section link targets at all. ;). --JavaWoman
==A better formatter for forced internal links==
I think that the current forced link formatter should be improved to allow //GET parameters//, //anchors// and //titles// to be parsed as part of valid internal links.
For example it would be nice if we could not only use forced links like:
~##""[[HomePage Internal forced link]]""##
or
~##""[[http://www.google.com External forced link]]""##
but also the following:
~-Forced internal link with URL parameter
~~##""[[HomePage (? "par1=ba,par2=bo") Internal forced link]]""##
~~=> http://wikka.jsnx.com/HomePage?par1=ba&par2=bo
~-Forced internal link with anchor
~~##""[[HomePage (# "this") Internal forced link]]""##
~~=> http://wikka.jsnx.com/HomePage#this
~-Forced internal link with Title
~~##""[[HomePage (§ "This is a link to the HomePage") Internal forced link]]""##
But I don't have a clue on how to modify the current formatter to send to the ##Link()## function all this stuff.
~&I like this idea very much, especially being able to add a title. A few remarks, no particular order:
~~-The paragraph sign § is not present on many keyboards (though probably on yours); I propose to use an exclamation mark instead.
~~~&Good point --DarTar
~~-Adding a title would also be useful for (forced) external links, not just internal ones; could use the same syntax, of course.
~~~&Good point as well --DarTar
~~-How to combine these various options? Each in a separate pair of brackets, all in a single pair of brackets together? I have a preference for the latter but haven't looked at any implications for the Formatter yet.
~~&To combine query parameters they should be separated with ##&##, not a single ##&## which is invalid in HTML
~~~&This has to be done by the formatter, not by the user. -- DarTar
~~~~&Ah, but when you give an example of what it //should// result in, that example should show what this responsibe formatter would do. ;-) Currently it has a single ##&## which is clearly incorrect. --JW
~~~~~&Just a small point ##&## is invalid here because your using XHTML, it is valid in HTML. --DaveBradshaw.
~~~~~~&Sorry, but no: A 'bare' ##&## is just as invalid in HTML as it is in XHTML: the (unescaped) ##&## is seen as the start of an entity reference in **all** versions of HTML. --JavaWoman
~&--JavaWoman
~&My one small concern with this appoach is that it might be a bit complex for a non programmer. My understanding is that a wiki is meant to be simple so anyone can use it. A more simple format might be //""WikiName#link!"title text"""//. I don't see why you would want/need to pass params to another Wiki page. Wouldn't it be better to create a new page and pass the param into the action there? i.e. ""{{action foo="bar"}}"". Again so that a noncoder has a better idea of want is going on. --DaveBradshaw.
Might be relevant for the present discussion: [[MeatBall:CleanLinking]]
-- DarTar
==Superscript annd subscript (<sup>/<sub>)==
[[Ticket:160]] //(text higher or lower in the line than normal)//
There are only simple changes needed to add wikka-formatters for superscript and subscript text; the bigger problem are the markup-formatters:
- for superscript: ^^ (seems most logical)
- for subscript: vv (would be logical, but perhaps problematic?) ?? and ?? are unused, but are no logical choice.
~&Ok, my markup suggestions above aren't the best choice. We will find better ones. Suggestions are welcome :)
Anyway, changes necessary to ##formatters/wakka.php## (with ^^ and vv):
add to the list of static variables (after trigger_center = 0;)
%%(php)
static $trigger_sup = 0;
static $trigger_sub = 0;
%%
add after if ($trigger_bold % 2) echo('</strong>');
%%(php)
if ($trigger_sup % 2) echo '</sup>';
if ($trigger_sub % 2) echo '</sub>';
%%
change the long line a little below to:
%%(php)
$trigger_bold = $trigger_center = $trigger_floatl = $trigger_inserted = $trigger_deleted = $trigger_italic = $trigger_keys = $trigger_sup = $trigger_sub = 0;
%%
add after the ""//center"" block:
%%(php)
// higher text
else if ($thing == "^^")
{
return (++$trigger_sup % 2 ? "<sup>" : "</sup>");
}
// lowered text
else if ($thing == "vv")
{
return (++$trigger_sub % 2 ? "<sub>" : "</sub>");
}
%%
~&I think putting in the line feeds here isn't such a good idea - super- and subscripts are simple in-line tags so they should logically remain in the text flow. -- JavaWoman
~~&Agreed and changed. --NilsLindenberg
and finally change the line with #Wiki Markup (near the end) to:
%%(php)
"\*\*|\'\'|\#\#|\#\%|@@|::c::|\>\>|\<\<|££|¥¥|\v\v|\^\^|\+\+|__|<|>|\/\/|". # Wiki markup
%%
----
CategoryDevelopmentFormatters
Deletions:
~

Revision [16835]

Edited on 2007-05-31 10:54:35 by BufDds [Reverted]
Additions:
~
Deletions:
~&While I agree on "preformatting" things like signatures and possibly "typographical sharpness", escaping ampersands before test is stored will make source harder to edit for people who don't know HTML - unless you also are going to 'unescape' each time the edit form is displayed. It's simpler and more logical to 'educate' the formatter to escape this special character as it's //already// doing for < and >. ''I've already written (and tested) the code to do this (excluding entities); this will probably become part of the next (1.1.6.1) release.'' -- JavaWoman
===Inline comments formatting ===
See InlineCommentFormatter
-- DarTar
===User-oriented formatters===
Beside better formatters for tabular data (see below) I think it's time to consider implementing some features that are largely requested by wiki users: //footnotes// and //tables of content//. (see below the discussion on named anchors)
~&See also the TableofcontentsAction page (work-in-progress!). --JavaWoman
===Table formatters===
A good wikka syntax for tabular data is IMO one of the top priorities for future Wikka development. Some [[WikkaTables ideas]] have already been suggested.
===More ##<div>## formatters===
I find quite limiting that Wikka only includes formatters for flush-left and flush-right divs. I would like to see a larger set of formatters, that - in association with CSS selectors - might be used to output //absolute-positioned// divs, //bordered// divs, divs with different degrees of //padding/margin// etc.
===System formatters===
<<See: WikkaMenulets<<::c::
It might be interesting - in the spirit of the ##""{{lastedit}}""## and ##""{{version}}""## action - to have a set of formatters for printing specific system-related information (GmBowen has also recently suggested something in this lines). I am not sure, though, whether this function should be implemented as a set formatters or as an action.
~&In the same spirit, I just created a ##[[HighlighterAction {{highlighter}}]]## action that creates a nice overview of available syntax highlighters. More system-related actions are in the pipeline (such as one that will display documentation for all available actions, provided the actions have a standardized documentation block at the start: self-documenting code!). --JavaWoman
===In page links===
It would be nice to have in page linking so you can jump directly to a section of a page in the format ""PageName#Section"" you could then reuse the Wacko ""{{ancher}}"" action to inset the ""<a name="Section"></a>"" code.
~&Dave, I cut and paste here a related discussion that was going on on ValidPageNames -- DarTar
~~&We could simply have the Formatter generate an ID for every heading (based on the heading's text) - no need for any action - you'd automatically have your anchor targets, in every page, and they'd remain consistent even if you re-arrange sections. All you need then is a link syntax that allows fragment identifiers (I'm not sure that works now). --JavaWoman
~~~&See also the TableofcontentsAction page (work-in-progress!) - indeed, no need for an action to create section link targets at all. ;). --JavaWoman
==A better formatter for forced internal links==
I think that the current forced link formatter should be improved to allow //GET parameters//, //anchors// and //titles// to be parsed as part of valid internal links.
For example it would be nice if we could not only use forced links like:
~##""[[HomePage Internal forced link]]""##
or
~##""[[http://www.google.com External forced link]]""##
but also the following:
~-Forced internal link with URL parameter
~~##""[[HomePage (? "par1=ba,par2=bo") Internal forced link]]""##
~~=> http://wikka.jsnx.com/HomePage?par1=ba&par2=bo
~-Forced internal link with anchor
~~##""[[HomePage (# "this") Internal forced link]]""##
~~=> http://wikka.jsnx.com/HomePage#this
~-Forced internal link with Title
~~##""[[HomePage (§ "This is a link to the HomePage") Internal forced link]]""##
But I don't have a clue on how to modify the current formatter to send to the ##Link()## function all this stuff.
~&I like this idea very much, especially being able to add a title. A few remarks, no particular order:
~~-The paragraph sign § is not present on many keyboards (though probably on yours); I propose to use an exclamation mark instead.
~~~&Good point --DarTar
~~-Adding a title would also be useful for (forced) external links, not just internal ones; could use the same syntax, of course.
~~~&Good point as well --DarTar
~~-How to combine these various options? Each in a separate pair of brackets, all in a single pair of brackets together? I have a preference for the latter but haven't looked at any implications for the Formatter yet.
~~&To combine query parameters they should be separated with ##&##, not a single ##&## which is invalid in HTML
~~~&This has to be done by the formatter, not by the user. -- DarTar
~~~~&Ah, but when you give an example of what it //should// result in, that example should show what this responsibe formatter would do. ;-) Currently it has a single ##&## which is clearly incorrect. --JW
~~~~~&Just a small point ##&## is invalid here because your using XHTML, it is valid in HTML. --DaveBradshaw.
~~~~~~&Sorry, but no: A 'bare' ##&## is just as invalid in HTML as it is in XHTML: the (unescaped) ##&## is seen as the start of an entity reference in **all** versions of HTML. --JavaWoman
~&--JavaWoman
~&My one small concern with this appoach is that it might be a bit complex for a non programmer. My understanding is that a wiki is meant to be simple so anyone can use it. A more simple format might be //""WikiName#link!"title text"""//. I don't see why you would want/need to pass params to another Wiki page. Wouldn't it be better to create a new page and pass the param into the action there? i.e. ""{{action foo="bar"}}"". Again so that a noncoder has a better idea of want is going on. --DaveBradshaw.
Might be relevant for the present discussion: [[MeatBall:CleanLinking]]
-- DarTar
==Superscript annd subscript (<sup>/<sub>)==
[[Ticket:160]] //(text higher or lower in the line than normal)//
There are only simple changes needed to add wikka-formatters for superscript and subscript text; the bigger problem are the markup-formatters:
- for superscript: ^^ (seems most logical)
- for subscript: vv (would be logical, but perhaps problematic?) ?? and ?? are unused, but are no logical choice.
~&Ok, my markup suggestions above aren't the best choice. We will find better ones. Suggestions are welcome :)
Anyway, changes necessary to ##formatters/wakka.php## (with ^^ and vv):
add to the list of static variables (after trigger_center = 0;)
%%(php)
static $trigger_sup = 0;
static $trigger_sub = 0;
%%
add after if ($trigger_bold % 2) echo('</strong>');
%%(php)
if ($trigger_sup % 2) echo '</sup>';
if ($trigger_sub % 2) echo '</sub>';
%%
change the long line a little below to:
%%(php)
$trigger_bold = $trigger_center = $trigger_floatl = $trigger_inserted = $trigger_deleted = $trigger_italic = $trigger_keys = $trigger_sup = $trigger_sub = 0;
%%
add after the ""//center"" block:
%%(php)
// higher text
else if ($thing == "^^")
{
return (++$trigger_sup % 2 ? "<sup>" : "</sup>");
}
// lowered text
else if ($thing == "vv")
{
return (++$trigger_sub % 2 ? "<sub>" : "</sub>");
}
%%
~&I think putting in the line feeds here isn't such a good idea - super- and subscripts are simple in-line tags so they should logically remain in the text flow. -- JavaWoman
~~&Agreed and changed. --NilsLindenberg
and finally change the line with #Wiki Markup (near the end) to:
%%(php)
"\*\*|\'\'|\#\#|\#\%|@@|::c::|\>\>|\<\<|££|¥¥|\v\v|\^\^|\+\+|__|<|>|\/\/|". # Wiki markup
%%
----
CategoryDevelopmentFormatters

Revision [13886]

Edited on 2006-04-21 16:18:53 by NilsLindenberg [link to tracker added]
Additions:
[[Ticket:160]] //(text higher or lower in the line than normal)//
Deletions:
//(text higher or lower in the line than normal)//

Revision [8627]

Edited on 2005-05-28 18:28:51 by JavaWoman [move to subcategory, layout]
Additions:
{{lastedit show="3"}}>>See also:
CategoryDevelopmentFormatters
Deletions:
{{lastedit show="3"}}
>>See also:
CategoryDevelopment

Revision [8488]

Edited on 2005-05-26 08:04:58 by DarTar [adding link]
Additions:
~-AdvancedFormatter

Revision [8436]

Edited on 2005-05-24 16:12:49 by JavaWoman [adding comment about escaping ampersands]
Additions:
~&While I agree on "preformatting" things like signatures and possibly "typographical sharpness", escaping ampersands before test is stored will make source harder to edit for people who don't know HTML - unless you also are going to 'unescape' each time the edit form is displayed. It's simpler and more logical to 'educate' the formatter to escape this special character as it's //already// doing for < and >. ''I've already written (and tested) the code to do this (excluding entities); this will probably become part of the next (1.1.6.1) release.'' -- JavaWoman

Revision [8122]

Edited on 2005-05-14 10:11:39 by DarTar [Adding link]
Additions:
~-AcronymFormatter

Revision [7358]

Edited on 2005-04-18 10:22:08 by DarTar [Adding link to see also box]
Additions:
~-LinkTails

Revision [6448]

Edited on 2005-03-03 23:49:12 by IanAndolina [added preformatter]
Additions:
===Preformatter===
Modifies data before it goes into the database, adding signatures, typographical sharpness and ensuring all ampersands are properly escaped.
See PreFormatter
-- IanAndolina

Revision [6382]

Edited on 2005-02-28 11:22:44 by DarTar [Adding links]
Additions:
===== Wanted Wikka formatters =====
{{lastedit show="3"}}

>>See also:
~-WikkaExtensibleMarkup
~-PseudoFormatters
>>::c::

I created this page to list proposals about [[FormatterInfo formatters]] that might be implemented in future Wikka releases.
Feel free to add your ideas/comments.

===Inline comments formatting ===
See InlineCommentFormatter
-- DarTar

===User-oriented formatters===
Beside better formatters for tabular data (see below) I think it's time to consider implementing some features that are largely requested by wiki users: //footnotes// and //tables of content//. (see below the discussion on named anchors)
~&See also the TableofcontentsAction page (work-in-progress!). --JavaWoman

===Table formatters===
A good wikka syntax for tabular data is IMO one of the top priorities for future Wikka development. Some [[WikkaTables ideas]] have already been suggested.

===More ##<div>## formatters===
I find quite limiting that Wikka only includes formatters for flush-left and flush-right divs. I would like to see a larger set of formatters, that - in association with CSS selectors - might be used to output //absolute-positioned// divs, //bordered// divs, divs with different degrees of //padding/margin// etc.

===System formatters===
<<See: WikkaMenulets<<::c::
It might be interesting - in the spirit of the ##""{{lastedit}}""## and ##""{{version}}""## action - to have a set of formatters for printing specific system-related information (GmBowen has also recently suggested something in this lines). I am not sure, though, whether this function should be implemented as a set formatters or as an action.
~&In the same spirit, I just created a ##[[HighlighterAction {{highlighter}}]]## action that creates a nice overview of available syntax highlighters. More system-related actions are in the pipeline (such as one that will display documentation for all available actions, provided the actions have a standardized documentation block at the start: self-documenting code!). --JavaWoman

===In page links===
It would be nice to have in page linking so you can jump directly to a section of a page in the format ""PageName#Section"" you could then reuse the Wacko ""{{ancher}}"" action to inset the ""<a name="Section"></a>"" code.
~&Dave, I cut and paste here a related discussion that was going on on ValidPageNames -- DarTar
~~&We could simply have the Formatter generate an ID for every heading (based on the heading's text) - no need for any action - you'd automatically have your anchor targets, in every page, and they'd remain consistent even if you re-arrange sections. All you need then is a link syntax that allows fragment identifiers (I'm not sure that works now). --JavaWoman
~~~&See also the TableofcontentsAction page (work-in-progress!) - indeed, no need for an action to create section link targets at all. ;). --JavaWoman

==A better formatter for forced internal links==

I think that the current forced link formatter should be improved to allow //GET parameters//, //anchors// and //titles// to be parsed as part of valid internal links.

For example it would be nice if we could not only use forced links like:
~##""[[HomePage Internal forced link]]""##
or
~##""[[http://www.google.com External forced link]]""##
but also the following:

~-Forced internal link with URL parameter
~~##""[[HomePage (? "par1=ba,par2=bo") Internal forced link]]""##
~~=> http://wikka.jsnx.com/HomePage?par1=ba&par2=bo
~-Forced internal link with anchor
~~##""[[HomePage (# "this") Internal forced link]]""##
~~=> http://wikka.jsnx.com/HomePage#this
~-Forced internal link with Title
~~##""[[HomePage (§ "This is a link to the HomePage") Internal forced link]]""##

But I don't have a clue on how to modify the current formatter to send to the ##Link()## function all this stuff.

~&I like this idea very much, especially being able to add a title. A few remarks, no particular order:
~~-The paragraph sign § is not present on many keyboards (though probably on yours); I propose to use an exclamation mark instead.
~~~&Good point --DarTar
~~-Adding a title would also be useful for (forced) external links, not just internal ones; could use the same syntax, of course.
~~~&Good point as well --DarTar
~~-How to combine these various options? Each in a separate pair of brackets, all in a single pair of brackets together? I have a preference for the latter but haven't looked at any implications for the Formatter yet.
~~&To combine query parameters they should be separated with ##&##, not a single ##&## which is invalid in HTML
~~~&This has to be done by the formatter, not by the user. -- DarTar
~~~~&Ah, but when you give an example of what it //should// result in, that example should show what this responsibe formatter would do. ;-) Currently it has a single ##&## which is clearly incorrect. --JW
~~~~~&Just a small point ##&## is invalid here because your using XHTML, it is valid in HTML. --DaveBradshaw.
~~~~~~&Sorry, but no: A 'bare' ##&## is just as invalid in HTML as it is in XHTML: the (unescaped) ##&## is seen as the start of an entity reference in **all** versions of HTML. --JavaWoman
~&--JavaWoman
~&My one small concern with this appoach is that it might be a bit complex for a non programmer. My understanding is that a wiki is meant to be simple so anyone can use it. A more simple format might be //""WikiName#link!"title text"""//. I don't see why you would want/need to pass params to another Wiki page. Wouldn't it be better to create a new page and pass the param into the action there? i.e. ""{{action foo="bar"}}"". Again so that a noncoder has a better idea of want is going on. --DaveBradshaw.

Might be relevant for the present discussion: [[MeatBall:CleanLinking]]

-- DarTar

==Superscript annd subscript (<sup>/<sub>)==
//(text higher or lower in the line than normal)//

There are only simple changes needed to add wikka-formatters for superscript and subscript text; the bigger problem are the markup-formatters:
- for superscript: ^^ (seems most logical)
- for subscript: vv (would be logical, but perhaps problematic?) ?? and ?? are unused, but are no logical choice.

~&Ok, my markup suggestions above aren't the best choice. We will find better ones. Suggestions are welcome :)

Anyway, changes necessary to ##formatters/wakka.php## (with ^^ and vv):
add to the list of static variables (after trigger_center = 0;)
%%(php)
static $trigger_sup = 0;
static $trigger_sub = 0;
%%

add after if ($trigger_bold % 2) echo('</strong>');
%%(php)
if ($trigger_sup % 2) echo '</sup>';
if ($trigger_sub % 2) echo '</sub>';
%%

change the long line a little below to:
%%(php)
$trigger_bold = $trigger_center = $trigger_floatl = $trigger_inserted = $trigger_deleted = $trigger_italic = $trigger_keys = $trigger_sup = $trigger_sub = 0;
%%

add after the ""//center"" block:
%%(php)
// higher text
else if ($thing == "^^")
{
return (++$trigger_sup % 2 ? "<sup>" : "</sup>");
}
// lowered text
else if ($thing == "vv")
{
return (++$trigger_sub % 2 ? "<sub>" : "</sub>");
}
%%
~&I think putting in the line feeds here isn't such a good idea - super- and subscripts are simple in-line tags so they should logically remain in the text flow. -- JavaWoman
~~&Agreed and changed. --NilsLindenberg

and finally change the line with #Wiki Markup (near the end) to:
%%(php)
"\*\*|\'\'|\#\#|\#\%|@@|::c::|\>\>|\<\<|££|¥¥|\v\v|\^\^|\+\+|__|<|>|\/\/|". # Wiki markup
%%
----
Deletions:
===== Wanted Wikka formatters =====
{{lastedit show="3"}}

I created this page to list proposals about [[FormatterInfo formatters]] that might be implemented in future Wikka releases.
Feel free to add your ideas/comments.

===Inline comments formatting ===
See InlineCommentFormatter
-- DarTar

===User-oriented formatters===
Beside better formatters for tabular data (see below) I think it's time to consider implementing some features that are largely requested by wiki users: //footnotes// and //tables of content//. (see below the discussion on named anchors)
~&See also the TableofcontentsAction page (work-in-progress!). --JavaWoman

===Table formatters===
A good wikka syntax for tabular data is IMO one of the top priorities for future Wikka development. Some [[WikkaTables ideas]] have already been suggested.

===More ##<div>## formatters===
I find quite limiting that Wikka only includes formatters for flush-left and flush-right divs. I would like to see a larger set of formatters, that - in association with CSS selectors - might be used to output //absolute-positioned// divs, //bordered// divs, divs with different degrees of //padding/margin// etc.

===System formatters===
<<See: WikkaMenulets<<::c::
It might be interesting - in the spirit of the ##""{{lastedit}}""## and ##""{{version}}""## action - to have a set of formatters for printing specific system-related information (GmBowen has also recently suggested something in this lines). I am not sure, though, whether this function should be implemented as a set formatters or as an action.
~&In the same spirit, I just created a ##[[HighlighterAction {{highlighter}}]]## action that creates a nice overview of available syntax highlighters. More system-related actions are in the pipeline (such as one that will display documentation for all available actions, provided the actions have a standardized documentation block at the start: self-documenting code!). --JavaWoman

===In page links===
It would be nice to have in page linking so you can jump directly to a section of a page in the format ""PageName#Section"" you could then reuse the Wacko ""{{ancher}}"" action to inset the ""<a name="Section"></a>"" code.
~&Dave, I cut and paste here a related discussion that was going on on ValidPageNames -- DarTar
~~&We could simply have the Formatter generate an ID for every heading (based on the heading's text) - no need for any action - you'd automatically have your anchor targets, in every page, and they'd remain consistent even if you re-arrange sections. All you need then is a link syntax that allows fragment identifiers (I'm not sure that works now). --JavaWoman
~~~&See also the TableofcontentsAction page (work-in-progress!) - indeed, no need for an action to create section link targets at all. ;). --JavaWoman

==A better formatter for forced internal links==

I think that the current forced link formatter should be improved to allow //GET parameters//, //anchors// and //titles// to be parsed as part of valid internal links.

For example it would be nice if we could not only use forced links like:
~##""[[HomePage Internal forced link]]""##
or
~##""[[http://www.google.com External forced link]]""##
but also the following:

~-Forced internal link with URL parameter
~~##""[[HomePage (? "par1=ba,par2=bo") Internal forced link]]""##
~~=> http://wikka.jsnx.com/HomePage?par1=ba&par2=bo
~-Forced internal link with anchor
~~##""[[HomePage (# "this") Internal forced link]]""##
~~=> http://wikka.jsnx.com/HomePage#this
~-Forced internal link with Title
~~##""[[HomePage (§ "This is a link to the HomePage") Internal forced link]]""##

But I don't have a clue on how to modify the current formatter to send to the ##Link()## function all this stuff.

~&I like this idea very much, especially being able to add a title. A few remarks, no particular order:
~~-The paragraph sign § is not present on many keyboards (though probably on yours); I propose to use an exclamation mark instead.
~~~&Good point --DarTar
~~-Adding a title would also be useful for (forced) external links, not just internal ones; could use the same syntax, of course.
~~~&Good point as well --DarTar
~~-How to combine these various options? Each in a separate pair of brackets, all in a single pair of brackets together? I have a preference for the latter but haven't looked at any implications for the Formatter yet.
~~&To combine query parameters they should be separated with ##&##, not a single ##&## which is invalid in HTML
~~~&This has to be done by the formatter, not by the user. -- DarTar
~~~~&Ah, but when you give an example of what it //should// result in, that example should show what this responsibe formatter would do. ;-) Currently it has a single ##&## which is clearly incorrect. --JW
~~~~~&Just a small point ##&## is invalid here because your using XHTML, it is valid in HTML. --DaveBradshaw.
~~~~~~&Sorry, but no: A 'bare' ##&## is just as invalid in HTML as it is in XHTML: the (unescaped) ##&## is seen as the start of an entity reference in **all** versions of HTML. --JavaWoman
~&--JavaWoman
~&My one small concern with this appoach is that it might be a bit complex for a non programmer. My understanding is that a wiki is meant to be simple so anyone can use it. A more simple format might be //""WikiName#link!"title text"""//. I don't see why you would want/need to pass params to another Wiki page. Wouldn't it be better to create a new page and pass the param into the action there? i.e. ""{{action foo="bar"}}"". Again so that a noncoder has a better idea of want is going on. --DaveBradshaw.

Might be relevant for the present discussion: [[MeatBall:CleanLinking]]

-- DarTar

==Superscript annd subscript (<sup>/<sub>)==
//(text higher or lower in the line than normal)//

There are only simple changes needed to add wikka-formatters for superscript and subscript text; the bigger problem are the markup-formatters:
- for superscript: ^^ (seems most logical)
- for subscript: vv (would be logical, but perhaps problematic?) ?? and ?? are unused, but are no logical choice.

~&Ok, my markup suggestions above aren't the best choice. We will find better ones. Suggestions are welcome :)

Anyway, changes necessary to ##formatters/wakka.php## (with ^^ and vv):
add to the list of static variables (after trigger_center = 0;)
%%(php)
static $trigger_sup = 0;
static $trigger_sub = 0;
%%

add after if ($trigger_bold % 2) echo('</strong>');
%%(php)
if ($trigger_sup % 2) echo '</sup>';
if ($trigger_sub % 2) echo '</sub>';
%%

change the long line a little below to:
%%(php)
$trigger_bold = $trigger_center = $trigger_floatl = $trigger_inserted = $trigger_deleted = $trigger_italic = $trigger_keys = $trigger_sup = $trigger_sub = 0;
%%

add after the ""//center"" block:
%%(php)
// higher text
else if ($thing == "^^")
{
return (++$trigger_sup % 2 ? "<sup>" : "</sup>");
}
// lowered text
else if ($thing == "vv")
{
return (++$trigger_sub % 2 ? "<sub>" : "</sub>");
}
%%
~&I think putting in the line feeds here isn't such a good idea - super- and subscripts are simple in-line tags so they should logically remain in the text flow. -- JavaWoman
~~&Agreed and changed. --NilsLindenberg

and finally change the line with #Wiki Markup (near the end) to:
%%(php)
"\*\*|\'\'|\#\#|\#\%|@@|::c::|\>\>|\<\<|££|¥¥|\v\v|\^\^|\+\+|__|<|>|\/\/|". # Wiki markup
%%
----

Revision [5655]

Edited on 2005-02-05 18:24:07 by NilsLindenberg [reply to jw]
Additions:
return (++$trigger_sup % 2 ? "<sup>" : "</sup>");
return (++$trigger_sub % 2 ? "<sub>" : "</sub>");
~~&Agreed and changed. --NilsLindenberg
Deletions:
return (++$trigger_sup % 2 ? "<sup>\n" : "\n</sup>\n");
return (++$trigger_sub % 2 ? "<sub>\n" : "\n</sub>\n");

Revision [5640]

Edited on 2005-02-04 23:16:46 by JavaWoman [comments and re-wording about sup/sub text]
Additions:
==Superscript annd subscript (<sup>/<sub>)==
//(text higher or lower in the line than normal)//
There are only simple changes needed to add wikka-formatters for superscript and subscript text; the bigger problem are the markup-formatters:
- for superscript: ^^ (seems most logical)
- for subscript: vv (would be logical, but perhaps problematic?) ?? and ?? are unused, but are no logical choice.
~&I think putting in the line feeds here isn't such a good idea - super- and subscripts are simple in-line tags so they should logically remain in the text flow. -- JavaWoman
Deletions:
==Text higher or lower in the line than normal (in html: stub/stup)==
There are only simple changes needed to add wikka-formatters for text higher or lower in the line then normal, the bigger problem are the markup-formatters:
- for higher format: ^^ (seems most logical)
- for lowered text: vv (would be logical, but perhaps problematic?) ?? and ?? are unused, but are no logical-choice.

Revision [5638]

Edited on 2005-02-04 19:56:29 by NilsLindenberg [note at sub/sup]
Additions:
~&Ok, my markup suggestions above aren't the best choice. We will find better ones. Suggestions are welcome :)

Revision [5578]

Edited on 2005-02-04 14:35:06 by NilsLindenberg [thoughts + code for upper/lower text]
Additions:
==Text higher or lower in the line than normal (in html: stub/stup)==
There are only simple changes needed to add wikka-formatters for text higher or lower in the line then normal, the bigger problem are the markup-formatters:
- for higher format: ^^ (seems most logical)
- for lowered text: vv (would be logical, but perhaps problematic?) ?? and ?? are unused, but are no logical-choice.
Anyway, changes necessary to ##formatters/wakka.php## (with ^^ and vv):
add to the list of static variables (after trigger_center = 0;)
%%(php)
static $trigger_sup = 0;
static $trigger_sub = 0;
%%
add after if ($trigger_bold % 2) echo('</strong>');
%%(php)
if ($trigger_sup % 2) echo '</sup>';
if ($trigger_sub % 2) echo '</sub>';
%%
change the long line a little below to:
%%(php)
$trigger_bold = $trigger_center = $trigger_floatl = $trigger_inserted = $trigger_deleted = $trigger_italic = $trigger_keys = $trigger_sup = $trigger_sub = 0;
%%
add after the ""//center"" block:
%%(php)
// higher text
else if ($thing == "^^")
{
return (++$trigger_sup % 2 ? "<sup>\n" : "\n</sup>\n");
}
// lowered text
else if ($thing == "vv")
{
return (++$trigger_sub % 2 ? "<sub>\n" : "\n</sub>\n");
}
%%
and finally change the line with #Wiki Markup (near the end) to:
%%(php)
"\*\*|\'\'|\#\#|\#\%|@@|::c::|\>\>|\<\<|££|¥¥|\v\v|\^\^|\+\+|__|<|>|\/\/|". # Wiki markup
%%

Revision [4527]

Edited on 2005-01-12 15:23:43 by JavaWoman [further comments & reformatting to inline comments]
Additions:
~&I like this idea very much, especially being able to add a title. A few remarks, no particular order:
~~~&Good point --DarTar
~~~&Good point as well --DarTar
~~&To combine query parameters they should be separated with ##&##, not a single ##&## which is invalid in HTML
~~~&This has to be done by the formatter, not by the user. -- DarTar
~~~~&Ah, but when you give an example of what it //should// result in, that example should show what this responsibe formatter would do. ;-) Currently it has a single ##&## which is clearly incorrect. --JW
~~~~~&Just a small point ##&## is invalid here because your using XHTML, it is valid in HTML. --DaveBradshaw.
~~~~~~&Sorry, but no: A 'bare' ##&## is just as invalid in HTML as it is in XHTML: the (unescaped) ##&## is seen as the start of an entity reference in **all** versions of HTML. --JavaWoman
~&--JavaWoman
~&My one small concern with this appoach is that it might be a bit complex for a non programmer. My understanding is that a wiki is meant to be simple so anyone can use it. A more simple format might be //""WikiName#link!"title text"""//. I don't see why you would want/need to pass params to another Wiki page. Wouldn't it be better to create a new page and pass the param into the action there? i.e. ""{{action foo="bar"}}"". Again so that a noncoder has a better idea of want is going on. --DaveBradshaw.
Deletions:
~''I like this idea very much, especially being able to add a title. A few remarks, no particular order:
~~~-Good point --DarTar
~~~-Good point as well --DarTar
~~-To combine query parameters they should be separated with ##&##, not a single ##&## which is invalid in HTML--- --JavaWoman
~~~-This has to be done by the formatter, not by the user. -- DarTar
~~~~-Ah, but when you give an example of what it //should// result in, that example should show what this responsibe formatter would do. ;-) Currently it has a single ##&## which is clearly incorrect. --JW
~~~~~-Just a small point & is invaild here because your using XHTML, it is vaild in HTML. --DaveBradshaw.''
~My one small concern with this appoach is that it might be a bit complex for a non programmer. My understanding is that a wiki is meant to be simple so anyone can use it. A more simple format might be //""WikiName#link!"title text"""//. I don't see why you would want/need to pass params to another Wiki page. Wouldn't it be better to create a new page and pass the param into the action there? i.e. ""{{action foo="bar"}}"". Again so that a noncoder has a better idea of want is going on. --DaveBradshaw.

Revision [4523]

Edited on 2005-01-12 14:54:29 by JavaWoman [references to TableofcontentsAction (+ some layout)]
Additions:
~&See also the TableofcontentsAction page (work-in-progress!). --JavaWoman
~&In the same spirit, I just created a ##[[HighlighterAction {{highlighter}}]]## action that creates a nice overview of available syntax highlighters. More system-related actions are in the pipeline (such as one that will display documentation for all available actions, provided the actions have a standardized documentation block at the start: self-documenting code!). --JavaWoman
~&Dave, I cut and paste here a related discussion that was going on on ValidPageNames -- DarTar
~~&We could simply have the Formatter generate an ID for every heading (based on the heading's text) - no need for any action - you'd automatically have your anchor targets, in every page, and they'd remain consistent even if you re-arrange sections. All you need then is a link syntax that allows fragment identifiers (I'm not sure that works now). --JavaWoman
~~~&See also the TableofcontentsAction page (work-in-progress!) - indeed, no need for an action to create section link targets at all. ;). --JavaWoman
Deletions:
~''In the same spitit, I just created a ##[[HighlighterAction {{highlighter}}]]## action that creates a nice overview of available syntax highlighters. More system-related actions are in the pipeline (such as one that will display documentation for all available actions, provided the actions have a standardized documentation block at the start: self-documenting code!). --JavaWoman''
~''Dave, I cut and paste here a related discussion that was going on on ValidPageNames -- DarTar''
~~''We could simply have the Formatter generate an ID for every heading (based on the heading's text) - no need for any action - you'd automatically have your anchor targets, in every page, and they'd remain consistent even if you re-arrange sections. All you need then is a link syntax that allows fragment identifiers (I'm not sure that works now). --JavaWoman''

Revision [4522]

Edited on 2005-01-12 14:36:35 by KickTheDonkey [grammer correction]
Additions:
I created this page to list proposals about [[FormatterInfo formatters]] that might be implemented in future Wikka releases.
Deletions:
I create this page to list proposals about [[FormatterInfo formatters]] that might be implemented in future Wikka releases.

Revision [4034]

Edited on 2005-01-05 22:39:07 by JavaWoman [ypot in anchor idea]
Additions:
~~''We could simply have the Formatter generate an ID for every heading (based on the heading's text) - no need for any action - you'd automatically have your anchor targets, in every page, and they'd remain consistent even if you re-arrange sections. All you need then is a link syntax that allows fragment identifiers (I'm not sure that works now). --JavaWoman''
Deletions:
~~''We could simply have the Formatter generate an ID for every heading (based on the heading's text) - no need for any action - you'd automatically have your anchor targets, in every page, and they'd remain consistent even if you re-areange sections. All you need then is a link syntax that allows fragment identifiers (I'm not sure that works now). --JavaWoman''

Revision [4033]

Edited on 2005-01-05 22:37:49 by JavaWoman [anchor idea: no action needed]
Additions:
~~''We could simply have the Formatter generate an ID for every heading (based on the heading's text) - no need for any action - you'd automatically have your anchor targets, in every page, and they'd remain consistent even if you re-areange sections. All you need then is a link syntax that allows fragment identifiers (I'm not sure that works now). --JavaWoman''

Revision [4007]

Edited on 2005-01-05 15:41:50 by DarTar [Adding link]
Additions:
See InlineCommentFormatter
Deletions:
We currently use a combination of indentation and ''notes'' highlighting to mark inline comments, which sometimes produces layout inconsistencies and makes the discussion difficult to follow. I'd like to introduce a dedicated syntax for inline comments, on the model of [[http://www.splitbrain.org/dokuwiki/wiki:compare#discussion DocuWiki]] (scroll to the bottom of the page).

Revision [3637]

Edited on 2004-12-24 08:55:23 by DarTar [Adding further ideas]
Additions:
{{lastedit show="3"}}
===Inline comments formatting ===
We currently use a combination of indentation and ''notes'' highlighting to mark inline comments, which sometimes produces layout inconsistencies and makes the discussion difficult to follow. I'd like to introduce a dedicated syntax for inline comments, on the model of [[http://www.splitbrain.org/dokuwiki/wiki:compare#discussion DocuWiki]] (scroll to the bottom of the page).
-- DarTar
===User-oriented formatters===
Beside better formatters for tabular data (see below) I think it's time to consider implementing some features that are largely requested by wiki users: //footnotes// and //tables of content//. (see below the discussion on named anchors)
<<See: WikkaMenulets<<::c::

Revision [3560]

Edited on 2004-12-21 09:50:01 by DarTar [Adding link to CleanLinking]
Additions:
Might be relevant for the present discussion: [[MeatBall:CleanLinking]]

Revision [3278]

Edited on 2004-12-15 23:36:20 by DaveBradshaw [Comments on improving internal linking]
Additions:
~~~~-Ah, but when you give an example of what it //should// result in, that example should show what this responsibe formatter would do. ;-) Currently it has a single ##&## which is clearly incorrect. --JW
~~~~~-Just a small point & is invaild here because your using XHTML, it is vaild in HTML. --DaveBradshaw.''
~My one small concern with this appoach is that it might be a bit complex for a non programmer. My understanding is that a wiki is meant to be simple so anyone can use it. A more simple format might be //""WikiName#link!"title text"""//. I don't see why you would want/need to pass params to another Wiki page. Wouldn't it be better to create a new page and pass the param into the action there? i.e. ""{{action foo="bar"}}"". Again so that a noncoder has a better idea of want is going on. --DaveBradshaw.
Deletions:
~~~~-Ah, but when you give an example of what it //should// result in, that example should show what this responsibe formatter would do. ;-) Currently it has a single ##&## which is clearly incorrect. --JW''

Revision [3273]

Edited on 2004-12-15 22:45:22 by JavaWoman [adding reference to HighlighterAction and more]
Additions:
~''In the same spitit, I just created a ##[[HighlighterAction {{highlighter}}]]## action that creates a nice overview of available syntax highlighters. More system-related actions are in the pipeline (such as one that will display documentation for all available actions, provided the actions have a standardized documentation block at the start: self-documenting code!). --JavaWoman''

Revision [3270]

Edited on 2004-12-15 22:32:05 by DarTar [replying on anchors]
Additions:
~''Dave, I cut and paste here a related discussion that was going on on ValidPageNames -- DarTar''
==A better formatter for forced internal links==
I think that the current forced link formatter should be improved to allow //GET parameters//, //anchors// and //titles// to be parsed as part of valid internal links.
For example it would be nice if we could not only use forced links like:
~##""[[HomePage Internal forced link]]""##
or
~##""[[http://www.google.com External forced link]]""##
but also the following:
~-Forced internal link with URL parameter
~~##""[[HomePage (? "par1=ba,par2=bo") Internal forced link]]""##
~~=> http://wikka.jsnx.com/HomePage?par1=ba&par2=bo
~-Forced internal link with anchor
~~##""[[HomePage (# "this") Internal forced link]]""##
~~=> http://wikka.jsnx.com/HomePage#this
~-Forced internal link with Title
~~##""[[HomePage (§ "This is a link to the HomePage") Internal forced link]]""##
But I don't have a clue on how to modify the current formatter to send to the ##Link()## function all this stuff.
~''I like this idea very much, especially being able to add a title. A few remarks, no particular order:
~~-The paragraph sign § is not present on many keyboards (though probably on yours); I propose to use an exclamation mark instead.
~~~-Good point --DarTar
~~-Adding a title would also be useful for (forced) external links, not just internal ones; could use the same syntax, of course.
~~~-Good point as well --DarTar
~~-How to combine these various options? Each in a separate pair of brackets, all in a single pair of brackets together? I have a preference for the latter but haven't looked at any implications for the Formatter yet.
~~-To combine query parameters they should be separated with ##&##, not a single ##&## which is invalid in HTML--- --JavaWoman
~~~-This has to be done by the formatter, not by the user. -- DarTar
~~~~-Ah, but when you give an example of what it //should// result in, that example should show what this responsibe formatter would do. ;-) Currently it has a single ##&## which is clearly incorrect. --JW''
-- DarTar

Revision [3224]

Edited on 2004-12-15 15:03:23 by DaveBradshaw [In page links]
Additions:
===In page links===
It would be nice to have in page linking so you can jump directly to a section of a page in the format ""PageName#Section"" you could then reuse the Wacko ""{{ancher}}"" action to inset the ""<a name="Section"></a>"" code.

Revision [3162]

The oldest known version of this page was created on 2004-12-14 17:23:19 by DarTar [In page links]
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki