| At line 1 changed one line |
| ==MultilinePlaceholderProposal== |
| ==Multiline Placeholder Proposal== |
| At line 3 changed one line |
| I've added a link to [[MultilinePlaceholderProposal]], which 77.128.31.184 must |
| I've added a link to [[MultilinePlaceholderProposal]], which [[Gregor Hagedorn]] must |
| At line 7 changed one line |
| --[[YvesPiguet]], 07-Feb-26 |
| --[[YvesPiguet]], 27-Feb-26 |
| At line 9 added 6 lines |
| Yes, I am new here, thanks! I am not sure why the multiline placeholder has to start on a new line prevents it from being usable in a large number of extension cases. I clarified that the Generic Extension Element may start anywhere, and may contain line breaks. |
|
| -- [[Gregor Hagedorn]], 2007-02-27 |
|
| ==Generic Extension Element Proposal== |
|
| At line 33 changed 2 lines |
| To please everybody, I'd suggest that names with dots be reserved for reversed domains for people who care about |
| the issue, but by experience, I feel it's a loosing battle. |
| To please everybody, I'd suggest that names with dots be reserved for reversed domains for people who care about the issue, but by experience, I feel it's a loosing battle. |
| At line 76 added 206 lines |
|
| I don't think name clashes are an issue, since they're internal to the wiki anyway - it might even make sense to use something like {{{<<plugin 1>>}}}. If you want to have a global namespace for these, you will also probably need to add things like version information as well, and then it gets messy. |
|
| The whole point of the "plugin" syntax is that it allows a wiki engine to use native extensions without losing them in the edit. I don't think the point of actually *moving* content from one wiki to another has ever really been their objective. |
|
| -- Janne Jalkanen |
|
| I fail to see how using a domain name prevents name clashes when moving between different wikis. After all it's pretty common that someone makes a neat plugin and then makes several versions for different wiki engines. |
|
| I think that the content of {{{<<...>>}}} should always be considered engine-specific and either escaped or converted when moving between wikis. |
|
| You are right about the pipe. What other solution there is? "->" maybe? Or maybe if we chnaged th order of the alt text and plugin: {{{<<this is some plugin|pluginname some|paramaters|with pipes>>}}}... |
|
| -- RadomirDopieralski, 2007-02-27 |
|
| 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. |
|
| There is also the question of how much markup to allow in the alt text, allowing all the markup would allow better approximation of the plugins output. Could also allow plugin nesting, so if the outermost fails, it attempt a fallback to the next innermost. |
|
| I think there are few situations when the alt text would be displayed |
|
| When |
| * the plugin is missing. |
| * the plugin fails due to some exceptional circumstance (ran out of file space for instance) |
|
| If the plugin is missing or fails, and is going to degrade the quality of outputted page, then there should be some distinction, maybe a red bar to the left, with link to a footnote explaining more. |
|
| In PHP there is an error/warning message supression operator, @ |
|
| So whilst <<latex src="$1+b$"|1+b>> would generate a warning around the alt text, <<@latex src="$1+b$"|1+b>> still would use the alt text, but it wouldn't be highlighted. A plugin having no output, cant impact quality so using no alt and @ would be silently ignored as far as the user is concerned. |
|
| -- JaredWilliams, 2007-02-27 |
|
|
| From Gregor, originator of this proposal: |
|
| I think the debate whether plugins are uniquely identied by Java conventions is, ok, but its importance would be where two wiki engines do //want// to be interoperable or achieve automatic translation. |
|
| The point of an **extension element** is that Creole **does not know or cares** what is inside, except that the end-of-extension-box marker is //not// inside. The point is that providing an extension box stops screwing the rest of the content (especially by wiki-specific escaping requirements), and thus simplifies porting of content. |
|
| First as an aside: The extension box that I envision is not limited to plugins in a narrower sense, i.e. generating dynamic content. For example, I find JSPWikis abilitity to support custom CSS styles on Wiki text quite useful (much better than dozens of #red# etc. special markup) and would envision that inside an extension box as well. Or features like "invisible comments", etc. that some wikis support. |
|
| For dynamic plugins, I do like the idea of optionally supporting an "alt-text" or "cached-result" very much. It would be relevant for Creole to anticipate it, because Wiki-editor software may need to know about it. |
|
| {{{ |
| <<extension|cached-result>> |
| }}} |
|
| introduces the small problem that the bar character may longer be part of the plugin. I would favor: |
|
| {{{ |
| <<extension>>|<<optional cached-result>> |
| }}} |
|
| That is, multiple extension boxes separated by a bar without any other blanks refer to the first one, the second optionally containing a cached html-formatted result |
|
| The cached-result is automatically generated, so ease of typing is no concern here. |
|
| With regard to the discussion about URL/GUID plugin identifiers, what about: |
|
| {{{ |
| <<extension>>|<<optional cached-result>>|<<optional url-based plugin identifier>> |
| }}} |
|
| Perhaps that would simplify the migration, and would be added where confusion may arise, but not required. |
|
| -- [[Gregor Hagedorn]], 2007-02-27 |
|
| I generally like this proposal, but have one problem with it. This markup is not [[NonDestructive]] -- that is, if something goes wrong (for instance, an user forgets to close it) it will "eat" a large chunk of the page, making it disappear without a trace. |
|
| Most of Creole's markup is confined to a single paragraph and displays the text that is inside. This markup has neither of the two "safety guards". |
|
| Is there a way this could be made "safer"? |
|
| -- [[Radomir Dopieralski]], 2007-Mar-24 |
|
| Good point, I had never thought about this. However, any feature desiring to support hidden editing comments as part of this (a common extension of wikis) |
| would have this problem. |
|
| Would a clarification help, that |
|
| a) the extension element may not be nested (i.e. not only the closing ">>>" but aalso the opening "<<<" are illegal content of the element. |
|
| b) the element must be closed on a page. It should be rendered literally, with an error message added at the start of the element. |
|
| -- [[Gregor Hagedorn]], 2007-03-27 |
|
| I'm not a fan of error messages, especially in things like markup. You're likely to miss them and they usually are not even in your language. Besides, nobody but developers reads them -- they are scary. |
|
| I'm rather thinking of something less dramatic, like rendering the thing as a pre block if anything is wrong (bad opening/closing, nonexisting plugin, error returned by the plugin) -- it might be a differently colored pre block if you insist on marking errors. Actually, you could even highlight the offending fragment. It's still error, though. |
|
| I'm wondering if splitting it to inline and block elements would improve the situation? You could limit the inline one to the end of paragraph then... but then empty lines would be forbidden too. Maybe the solution you propose is enough? |
|
| Can we have some example use cases for this? I'm probably exaggerating the problem. |
|
| -- [[Radomir Dopieralski]], 2007-Mar-27 |
|
|
| I agree with the idea of suggesting to implementers to render the whole block following an erroneous extension element start as pre if extension elements markup is incomplete. I personally do like simple, non-programmer-oriented error messages. The kind of error message I imagine is: "(Start of extension-element markup found; please end-markup of nesting another extension element!)" in red. |
|
| For example, the JSPWiki we work on will highlight errors in interwiki links and I find that quite helpful: [[JSPWiki:Main]] is ok, [[JPSWiki:Main]] is not. (as you see, JSPWiki could do better, by repeating the offending interwiki link, rather than replacing it with an error message...) |
|
| -- [[Gregor Hagedorn]], 2007-03-28 |
|
| Syntax: How about using a simplified version of ~LaTeX? I'm mixing this kind of syntax with Creole in my wiki and it works really well. Advantages: It's established, many people know how to read and write it. |
| {{{ |
| \noargs |
| \command{arg1}{arg2} |
| \cmd[opt1=value1, opt2=value2] |
| \cmd[opt1=value1]{arg1} |
| \begin{environment} |
| \end{environment} |
| }}} |
|
| BTW: The way I currently parse my hybrid syntax is that the braces are dominant and inside a brace (as well as at the top level) you can have line-based Creole syntax. |
|
| -- [[Axel Rauschmayer]], 2007-04-11 |
|
| Axel, I don't quite understand, //how// do you want to mix it? Personally to me ~LaTex is a complicated markup language which I don't understand. I understand CSS, so for unlimited formatting, CSS would be my choice. Very personal and no poll! I am not opposed to making sure that a wiki could be in a mixed ~LaTex mode; that will certainly be very useful. But how do you achieve that? Do you propose to make single backslash a reserved Creole character? How is the end of the LaTex inline span defined? A new-line-character? |
|
| -- [[Gregor Hagedorn]], 2007-04-11 |
|
| It is not LaTeX per se, I only borrowed (a subset of) its syntax. |
|
| My motivation is as follows: While line-based wiki markup is great for the basics (bold, italics, lists, tables), one runs quickly out of symbols. For more complex things, I thus would want my syntax to be extensible. That is: there should be commands with parameters etc. My understanding of this proposal is that if we standardize the command syntax (not the command names), then at the very least we have a generic way of hiding additional markup. At best, we might even have exchangeable quite complex markup. |
|
| 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). |
|
| In my implementation, both backslash and a single closed brace are protected characters. LaTeX (which can nest text blocks) is "dominant" while wiki markup (which is line-based) is parsed inside a text block. If you don't use any LaTeX at all, you are in the "global text block" and can use Creole as you'd expect. |
|
| -- [[Axel Rauschmayer]], 2007-04-11 |
|
| AvoidTextTags, ReadableMarkup, EasyToLearn and other [[Good Practices]]. Then there is a problem of those who know LaTeX and would be surprised that their favorite construct (whatever it is) doesn't work, or work in a different way than in LaTeX. And of course, why don't you just use LaTeX everywhere in the first place? You can easily make some small macros for wiki links. No reason to ReinventTheWheel. |
|
| -- [[Radomir Dopieralski]], 2007-Apr-11 |
|
| Just to be sure: The generic extension proposal is essentially about text tags, right (or at least highly related)? I do want both: text tags and wiki markup. For basic things, I want the comfort and WYSIWYG-iness of wiki markup, for more complicated things, having a small semi-formal markup language is really helpful. So: having latex commands is a high-level feature that most users will rarely be confronted with. But for more complicated features, having text tags is actually **more** user-friendly. Example: Defining complex tables in Mediawiki is painful (I cannot remember the markup without looking it up, even for relatively simple tables), doing it in HTML is OK. As soon as wiki markup is hard to remember, I'd rather have text tags that are easy to remember. |
|
| The "don't surprise the LaTeX users" criticism is valid. |
|
| -- [[Axel Rauschmayer]], 2007-04-12 |
|
| Design guidance rules like [[Avoid Text Tags]] needs to be balanced against each other. 20 punctuation combinations as suggested in [[Hints on extending]] are not [[Easy To Learn]]. At some point text tags have an advantage. I know no Wiki which does NOT use a fair number of text tags, at least for the essential dynamic "plugins". |
|
| -- [[Gregor Hagedorn]], 2007-04-13 |
|
| You are both right. It's perfectly valid to use text tags and an easy to remember formal language, preferably one that can be read out loud (to dictate it over a phone, for instance) -- once the markup becomes more complicated than just few simple text-formatting rules. Creole should **not** be that complicated -- by definition. |
|
| There are separate standards and markup languages that handle the more advanced things -- and they can be easily mixed with Creole. |
|
| As for the GenericExtensionProposal and its "text-taggedness" -- it's like arguing that the links or images are also text tags, because you need to put text in them. Note however, that this text is not defined in Creole in any way, and hence polish wiki sites can use Polish text. |
|
| -- [[Radomir Dopieralski]], 2007-Apr-16 |
|
| I need to be able to embed large amounts of data in plugins (source code), without interpreting any |
| double-greaterthan as the plugin end marker. I suggest that if {{{<<}}} is on a line alone, the end |
| marker must be {{{>>}}} on a line alone; otherwise, the next {{{>>}}} is the end marker. That's |
| similar to the difference between nowiki and block preformatted. |
|
| Any support or disagreement? |
|
| -- [[YvesPiguet]], 2007-May-30 |
|
| I think it's reasonable, especially when the ">>" is much rarer alone on a line. You could also use the difference to decide whether render the plugin result in a div or span. |
|
| -- [[RadomirDopieralski]], 2007-May-30 |
|
| 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 |
.