Definition: A plaintext Wiki accepts any PlainText document as input and outputs XHTML which must render identical to the input document. PlainLink is used to allow linking to occur without changing the document.
The markup, links and folds are similar to Emacs `font-lock’ + ETAGS + an automatic folding mode. The rendered OUTPUT may adjust the appearance and may add actions for you to perform, but must render every character when the buffer is copy/pasted.
;;XML entities ("<" "<") ("&" "&") ;; whitespace ("[\n]" " <br/>\n") ("\t" " ") ;;TAB (" " " ") ;; two spaces ("^ " " ")
Lists of other transforms could be stored in separate files similar to Emacs `mode’ files.
Associating each mode to each filetype is like Emacs `auto-mode-alist’, the wiki software must decide which Mode(s) to apply to each file it encounters. These may be augmented in a ~/.PlainTextWiki file.
Some especially noisy INPUT files, such as some ASCII Art, may do best with no other Mode applied.
("\\*\\([^ \t\n]*\\)\\*" "<b>\\&</b>") ;bold ("_\\([^ \t\n]*\\)_" "<u>\\&</u>") ; underline ("/\\([^ \t\n]*\\)/" "<i>\\&</i>") ;italic
Transforms that determine what regexps link usually have nothing to do with CamelCase ‘s or _‘s.
;; explicit URLs (misspelled for now to pass OddMuse SPAM filter) ("\\(ftp\\|https?\\)://[^ \t\n\r]*" "<a hrf=\"\\&\">\\&</a>") ;; (http:// assumed) ("[a-zA-Z][a-zA-Z0-9_-]+\\.[a-zA-Z0-9-_]+[^ \t\n\r]*" "<a hrf=\"http://\\&\">\\&</a>") ;; cache and inline external image ;;("\\(file\\|ftp\\|https?\\)://[^ \t\n\r]*\\.jpg" (cache-and-inline-image "\\&"))
When a section ‘header’ is identified, the child text may be enclosed in a div that is hidden by default.
Transform lists may also be adjusted by a mixture of community and private NameSpaces.
Any User may work immediately and all changes are stored, and appear to be ‘done’ to the editor, but are actually just votes for those changes to be made if the community agrees (but what percentage?).
SPAM and SPAMMERS are quickly voted away (hidden by default for other users) when too many early viewers find them offensive enough to hide or reject. This could be a problem too.
The VoteWeight? of a user is increased whenever that user makes a change that is accepted by the community.
Users implicitly vote for and against others by accepting, hiding or rejecting comments and changes.
Identity may be optionally ‘secured’ through password if a User decides to stay a while.
Sub-communities need to be able to “carve out” their own space without annoying others with what the old-timers may consider SPAM. SPAM is subjective pollution?
To continue a discussion from CwbTotal:
Talking a bit more about security, ownership, control and voting:
It is similar, but more like TransparentMarkup?, as markup characters are more ‘suggestions’ than absolutes, and are not necessarily ‘known’ at the time the text is being constructed.
PlainTextWiki must preserve all whitespace perfectly.
PlainTextWiki will also never use CamelCase, ‘s or _‘s to indicate links, as that data is carried outside of the files themselves in separate NameSpace file(s). This is what adds most of the extra complexity.
This makes me begin thinking about how to ‘render’ binary files. For instance, a .jpg could be interrogated by some imaging tools, and a page could be created that showed the metadata names and values, and probably also the image itself. This is blending into my thoughts on making a wiki engine that act much like a local directory browser, file editor, and maybe even command executor; really just another ripoff of Emacs as an OS interface.
are not needed – just either use a
<pre> block or add
white-space: pre to apropriate element with CSS. As for rendering images as ascii-art, there are ready libraires for it: libaa and libcaca (color). There is also an image viewer using them, and you can configure lynx and other text-based web browsers to use it. Might be useful if someone didn’t provide an alt attribute for images with text and you are at a character terminal.
We can’t use
<pre> blocks because whitespace must be preserved for the entire document, not just some section and of course you can’t have hyperlinks and other markup we may want once inside
Thanks for pointing to the ASCII-art libraries, but that is not what I was talking about. When I said ‘render’ I maybe should have said ‘interpret’ or even ‘interrogate’. For instance, what does a person see when they open an executable in a text or hex editor? It is usually not very useful, but a disassembler could be used to ‘render’ that data at a higher level so it much more useful.
Of course you can put links and other tags inside a
<pre> tag in HTML. And you can also apply the
white-space: pre CSS attribute to any HTML element, making all the spaces and newlines being preserved in output. Try it!
As for interpreting raw bytes of data – that’s exactly how oddmuse stores images. As normal pages that contain raw bytes of data instead of text. One problem is that you also have to know what format the bytes are – what kind of data it is. Oddmuse uses a standard MIME type for this, so it knows when a page is normal wiki page, image, archive or text file.
Oops, sorry for the ASSumption. I wonder how I got those ideas about
There is another problem though, the lines don’t ‘wrap’, but instead cause the horizontal scroll-bar to appear. I know, I could break the lines at some column, but I very much dislike that.
About the “raw bytes”: I’m not concerned about how the images stored, but instead how they are presented. For instance, what would you expect a .tar.bz2 to ‘look’ to a user that attempted to view it? My guess would be a listing of it’s contents with links to the individual files.
This is a little mre complicated, as it requires different CSS for different browsers, but fortunately browsers will ignore the rules they don’t know, so you can just use all the rules at the same time. Messy, but works:
white-space: pre-wrap; /* this is the standard, not supported anywhere */ word-wrap: break-word; /* MSIE */ white-space: -moz-pre-wrap; /* Mozilla */ white-space: -pre-wrap; /* old Opera */ white-space: -o-pre-wrap; /* Opera */
You can read this forum thread for more details.
And how would you represent an application binary? Run it and make a screenshot?
Thanks so much for that Radomir, it is exactly what I’ve been looking for.
As for the “application binary”, I mentioned this above as:
For instance, what does a person see when they open an executable in a text or hex editor? It is usually not very useful, but a disassembler could be used to ‘render’ that data at a higher level so it much more useful.
But I really like the idea of taking a screenshot also, and have mulled this over in the past as I have dreamt of making more FreeSoftware available in even the most size-restricted (mini) GNU/Linux distros by organizing entries in the ‘Start’ menu (different for various window managers I know) for thousands of applications and games - with a screenshot and description that pops-up as you pause on each entry.
Most applications would be “greyed out” or use some other indication that they are not actually installed yet, but are available for installation over the network - not by using <pre>apt get<pre/> at a command-line or by opening an ‘installer’ program (such as <pre>aptitude</pre> - but by simply clicking on that menu item.