| At line 1 removed one line |
| bocrelmonalb |
| At line 48 changed one line |
| If you want to start standarizing the extension names themselves, you open a Pandora box of internationalisation and localisation. On a Polish-only wiki, I will naturally want to use polish names for plugins. But domain names don't allow (by default) the use of characters like Ä
or Ä. I believe that Chinese users would have even more trouble. |
| If you want to start standarizing the extension names themselves, you open a Pandora box of internationalisation and localisation. On a Polish-only wiki, I will naturally want to use polish names for plugins. But domain names don't allow (by default) the use of characters like ą or ę. I believe that Chinese users would have even more trouble. |
| At line 92 changed 3 lines |
| Wiki A has 'late |
| 2000 |
| x' mapped to 'unaffiliated.radomir.dopieralski.macro.latex'. So {{{<<latex src="$a+1$>>}}} does its thing. Wiki B has latex mapped to 'unaffiliated.jared.williams.macro.latex' and uses {{{<<latex a+15>>}}}. Both can import the others pages, as long as they know how each other maps the markup to actual plugin implementations. |
| Wiki A has 'latex' mapped to 'unaffiliated.radomir.dopieralski.macro.latex'. So {{{<<latex src="$a+1$>>}}} does its thing. Wiki B has latex mapped to 'unaffiliated.jared.williams.macro.latex' and uses {{{<<latex a+15>>}}}. Both can import the others pages, as long as they know how each other maps the markup to actual plugin implementations. |
| At line 205 changed 3 lines |
| As for understanding LaTeX: I've listed all relevant constructs above. I would not introduce anything more complex than this. I like t |
| 2000 |
| he syntax because it is versatile, flexible and (at least some) people know of it. Furthermore, there are some Wiki extensions for typesetting math that use LaTeX. These would blend in naturally with a LaTeX command syntax. One problem might arise for Windows user, though: they might need the backslash for paths (as I'm only using Linux + Mac OS, I'm not sure how much of a problem this is). |
| As for understanding LaTeX: I've listed all relevant constructs above. I would not introduce anything more complex than this. I like the syntax because it is versatile, flexible and (at least some) people know of it. Furthermore, there are some Wiki extensions for typesetting math that use LaTeX. These would blend in naturally with a LaTeX command syntax. One problem might arise for Windows user, though: they might need the backslash for paths (as I'm only using Linux + Mac OS, I'm not sure how much of a problem this is). |
| At line 242 added 40 lines |
|
| YEP - need a generic extension proposal. Firstly a triple bracket like, { { { .... } } } and {{{[[[ quote ]]] }}} as I'm suggesting for a [[Quoting|quotes]] implies that the content between the brackets is not parsed normally by the creole parser. |
| *{ { { - everything is accepted |
| *{{{[ [ [}}} - only formatting is parsed, whitespaces and newlines are displayed as is. |
| *{{{<<<}}} - nothing in the brackets is part of the specification, except to say that the application must interpret it and/or reject it. |
|
| However, humans being humans, people are going to want to introduce their own code into Creole for those little things like font colours, sizes, table borders etc. etc. |
|
| If {{{<<< ....>>>}}} means "You've got to be kidding Creole doesn't have anything to say about text between those brakets. |
|
| {{{<<SOMETHING>>}}} might mean "not sure about that" and be reserved for an optional extension to the specification such as text colours. |
| More specifically:- |
|
| {{{<<#ABCDE#>>}}} would have the meaning "optional code #ABCDE#" |
|
| -- [[Isonomia]] May 2008 |
|
| I am personally against using {{{<< ... >>}}} for Plugins. My main reason is that the double-angle-brackets are operators in this world (think C/C++/Java etc.) |
|
| Plugins should use the most rare syntax in order to allow a greater number of character combinations to be placed inside (as parameters). If {{{<< ... >>}}} is used, the content between the brackets would not be able to use {{{>>}}}, making it impossible to use with C code inside. Well, escaping could be done for each {{{>>}}} but that would be tedious and would complicate the parser (not sure if escaping should even be possible inside the brackets for a plugin). |
|
| -- Mircea Bardac, August 2008 |
|
| Do you have any example of such a plugin that accepts C code in it in any real wiki out there, or uses "{{{>>}}}" for other purposes? |
|
| The only thing that comes to my mind is syntax highlighting, but that could be built into the preformatted blocks. |
|
| -- RadomirDopieralski, 6 September 2008 |
|
| I do not have an example of a plugin that accepts C code. All the C code I have seen was rendered in preformatted blocks, as you have mentioned. Then again, I haven't seen any wiki having a "plugin" markup. |
|
| I am considering using Creole and extending it in order to be able to custom render blocks. By "custom rendering" I mean <render this block only if "condition" is true>. These blocks can contain anything, including {{{<<}}}. |
|
| Also, how would someone build a "preformatted block with syntax highlight/line numbering" in Creole?. I am thinking that {{{<<syntax=C ...>>}}} could be used for this, because there is no support in the default markup. That means the contents of the tag would have to be somehow escaped if {{{<<}}} is in the block. |
|
| This is the main reason for trying to have something as uncommon as possible for the Plugin markup. You can't know exactly what needs to be passed to a plugin and the plugin markup should be as uncommon as possible (maybe even more verbose). This is probably one of the problems for HTML templating systems. There will always be conflicts and escaping would be needed, but I guess the need for this could be decreased. |
|
| As for the implementation, I believe it should be like a block markup ([[HintsOnExtending]]) to cover all possible uses of the Plugin. The 3-characters block markup would also decrease the chance of collisions. I think the specification should also include a way of defining the plugin name inside the markup - would definitely help the developer and make the plugin markup look clean across implementations - maybe something like {{{$$$plugin:...$$$}}} - $ was chosen randomly from the list. |
|
| -- Mircea Bardac, 7 September 2008 |
.