create new tag
, view all tags
Hello all.

I never particularly liked the way the "verbatim" processing is handled within TWiki. I was always getting backward on the first pass and had to go back and fix my pages. In the past, I noticed and fixed one place here at http://twiki.org where someone who was a technical user made the same mistake. This page was created to discuss the problem and a way to improve TWiki for the layperson and also for the techs who haven't had their 3rd cup of coffee yet.

First, one of TWiki's greatest strengths is the ability to directly use HTML within a page. While this is a great feature, I am sure the laypeople trying to use TWiki are constantly tripped up by this because TWiki does not escape out HTML tokens when processing. From my point of view, it simply does not make sense that I cannot type a "<" directly into my text (I would have to type "&lt;") in order to have it show up on the browser screen.

So, here is my proposal:

By default, TWiki would escape out all potential characters which conceivably would be "eaten" by the browser when trying to display the page. A new directive(s) would be introduced so that the HTML coders would be able to still code HTML into the pages.


  • TWiki, for the layperson and non-HTML coder would start acting more like they originally meant when typing
  • The hassle for the layperson and tech to type "&lt;" when needed, would dissappear.


  • Extra step for the technical user when actually coding HTML into a page
  • Breaks existing content (a perl script could convert pages to new format pretty quickly??)

I propose for the new syntax something similar to the following:

  • A "<directive> ... </directive>" pair would indicate the start and end of HTML code to "push out" to the browser (a reworked "verbatim" ??)
  • An additional new directive to turn off and on variable expansion (possibly "<noexpand> ... "</noexpand>" ??)
  • Document the "<noautolink> ... </noautolink>" syntax, thus making it a fully standard feature.
  • Possible allowing a "shorthand" to combine some of the above new syntax

Just reusing "verbatim" as an example of what the above proposal could look like:

text including html characters automatically escaped out by twiki
 HTML, with autolinking and variable expansion on
 HTML, with variable expansion off but autolinking on
 HTML, with variable expansion turned back on and autolinking still on
&lt;noexpand noautolink&gt;
 HTML, with variable expansion off and autolinking off
 HTML, with variable expansion still off and autolinking turned back on
normal text processing again, including html characters automatically escaped out by twiki
&lt;verbatim noexpand noautolink&gt;
straight HTML, variable expansion and autolinking off
&lt;/verbatim /noexpand /noautolink&gt;

-- TomKagan - 14 Nov 2003

Thoughts? Comments?

Tom, that's a really interesting idea - a different way of looking at things. However, it's worth nothing that normal Wiki text is converted to HTML, so how would you get the equivalent of control the layout that <verbatim> currently gives you?

BTW, in the past we've preferred upgrades of pages to be automatic (each page contains a format version, this could be used to detect changes that a page needs conversion). Running upgrade scripts has many usability issues, especially when TWiki contains full version histories.

-- JohnTalintyre - 14 Nov 2003

In my humble opinion, the layout control currently given to "verbatim" is perhaps because TWiki's markup is lacking something. However, the obvious solution is to allow for an additional directive or two to handle these cases independently. Many times I've used "verbatim" and was annoyed by what it would cause TWiki to parse and not parse automatically.

I also don't see a problem if TWiki tries to handle both types of processing via the format version contained within the page. However, my past experience suggests the code will become quite bloated trying to be backward and forward compatible. I much prefer to have this type of code in separate convert/revert modules. Converting the complete version histories may take a lot of time but is still relatively straightforward to write. It only occurs once, whereas backward and forward compatible core code causes code bloat for a lifetime of runtime. Still, whatever way it's implemented isn't so important compared to having the improved features, as long as performance remains acceptable.

-- TomKagan - 14 Nov 2003

verbatim stops all processing, in particular all processing by the core of TWiki and by the plugins. It's biggest use is perhaps for showing Wiki markup code examples. I feel a lot of the above is really talking about a different issue e.g. everything is twiki markup text except in special escape sections (e.g. for HTML).

However, I'm dubious that the pain of this change to TWiki would be worth it. Mind you it would be great if < and > worked as single character entry.

-- JohnTalintyre - 05 Mar 2004

I think this is another issue, like topic-level preferences, that could be dealt with via a site-wide setting. Have a final preference ALLOWHTML which can take one of several values:

  • YES - default, current behavior
  • EXPLICIT - only within some kind of special delimiter block %STARTHTML% ... %ENDHTML% perhaps?
  • NO - never allowed anywhere, all < and > characters are escaped.

-- WalterMundt - 05 Mar 2004

Walter, I like the %STARTHTML% ... %ENDHTML% syntax!!! I think the need to use html and the need to use TWiki tags to avoid it is a serious usabillity issue. User in my company use <verbatim> often just to have their > and < displayed.

I started a new topic for that. Please participate in RequireEXPLICITTagToEnableHTML.

-- StefanSteinegger - 08 Nov 2004

Edit | Attach | Watch | Print version | History: r9 < r8 < r7 < r6 < r5 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r9 - 2008-08-24 - TWikiJanitor
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.