Purpose: to collect information about the implementation of the Wikit being used to present the content of this web site.
To prevent this page growing too large it has been split into a number of smaller pages. New suggestions should be added to the main page: Suggestions for Wikit.
AK: Although I would like to have tables we should think carefully before going in this direction. The problem is the someone is more comfortable with part. Other people might not be comfortable with a markup system for a page they would like to contribute too, and so they don't. This psychological barrier is not good for the overall success of the wiki. That said, latex has a nice and simple table representation. begin/end markers could be exceptions to the part about "nice". And the hline/cline commands are not "simple". But we do not need them first, maybe never.
SB: I think having tables is more important than how it is done. It seems that each flavor of wiki has its own markup language, or dialect, that it doesn't make much sense to discuss personal preferences. It is rather a question of implementing a table feature in an environment which cannot rely on html for rendering as wikit in local mode doesn't understand html. For now I must paint my tables by hand in plain old ascii. (As a tcl illiterate I cannot contribute much)
LV: Wouldn't it be great to have a button right beside Save called 'Spell Check'?
AK: Yep. ispell, or something written in Tcl ? Hm, I don't know this, has someone tried to rip the checking engine from ispell for placement into a library ? If yes, SWIG and go.
LV: Note for Wiki users - page titles are case insensitive. This can be a good or bad thing. Also, there appear to be some characters which are not good to use in a title, such as : . March 11, 1999
JC: colons and parentheses are now accepted, but an ampersand is not allowed in the page title
DKF: Conflicts with the regexps, does it? (Not that I'm too fussed - I figured out how to do indented paragraphs... :^)
JC: Yes, I saw :o) ... cool. Indeed, the regexps are horrendously complex (and broken right now, as Larry mentioned elsewhere). It's the price to pay for lack of a real syntax, I suppose. And now I also need to make sure things don't break when fixing problems ... :o(
RWT: Wouldn't it be cool if there was some way to associate the IP numbers on the Recent Changes page with names? I seem to show up as 129.176.215.122. It would even be cool if there was a "change comment" field on the edit screen that would act like the RCS comments.
DKF: That would be very nice. Even though I'd always show up as having come from our webcaches... <sigh>
LV: What would it take to add to Wikit the ability to use http in stand alone mode and selecting an html URL? I'm just curious about the level of effort. Also, I was curious about the ideas planned two current Wiki page holders - the Tclkit page, and the starkit page ...
JC: Very little (I should have done it long ago, I admit, your honor). The HTML widget is already part of what is in the Wikit scripts. The work left is to adjust what the buttons at the top do when an URL is showing, including handling "Back" correctly to get back to the previous wiki page in the history list. More involved, because of platform difference, would be to launch a browser instead. And even less work, would be to at least copy the link to the clipboard when clicked (and show it in the status bar). I never knew clipboard handling was so simple in Tk. As for the two links you mentioned: I've added a few blurbs to those pages.
LV: I would like to have the following features in wikit, but I can't tell for certain whether or not they are present:
LV: I would like to see the following features in wikit, but again I can't tell whether or not they are present:
This would enable one to upgrade a wikit without touching the data.
LV: I would like to see hooks/user exits added to wikit for site specific procedures to be added. Some of the places I would love to see hooks:
JC: Plenty good suggestions. Let me start with the easiest case: if you create a directory containing scripts, you can import them with the line
./wikit.tkd -scripts=directory/
This merges, so files with the same name get overwritten and the rest is left alone. As a matter of fact, it's a smart merge: if the file has the same modification timestamp, it is not imported. This is how I develop scripted documents, a line like the above is part of my makes.
The other suggestions ought to be easy to add (he said, knowing full well that scripted docs and especially wikits are more a black box than anything else). You could write a script called "export.tcl", import it with the above trick, or just as a single file:
./wikit.tkd -scripts/export.tcl=export.tcl
and then say:
./wikit.tkd export args...
In other words, adding a script automatically makes it available as command. You might want to extract "dump.tcl" as script from the wiki to see how it was set up and for general ideas on how to get at data.
I'd like to be able to translate the static texts (Updated on ... - Edit ... Search - Changes - Expand - ... References - About Wikit - Go to ... among others) without having to change the script (with a companion "language" directory perhaps?). -- GP-L
Regarding spell checking, this can be done from the edit page itself. I've written and rewritten it twice. You can take all the textarea data, send it to a CGI, and return the results in a second window. It's not a pretty solution, but works quite well. The advantage is you get to see mispellings before the submit; the hard part is showing where the error occured. I have long felt the need for a better textarea, perhaps (shudder) an applet. --Steve Wainstead
The ability to "translate the static texts" could be implemented by simply editing special pages. For example, create a page called "Editing quick-reference", and include that page instead of hard-coding in the information.
(time passes)
Ok, I just implemented that on my wiki. It's a real pain to try to use the wiki format to write text that describes wiki format. There are definitely issues in trying to describe the formatting rules when using the formatting rules. Still, it's a nice technique. Eventually I'll get around to making my modifications available. Whine loud enough and maybe I'll send 'em to you. -- Bryan Oakley 02-May-2000
Bryan and friends - are there people actually coding new Wikit functions, fixing the existing ones, etc.?
(Bryan Oakley June 19, 2000) I have not messed with the scripts much. I have tweaked some of the standalone GUI code, but nothing worth publishing at this point)
I have recently converted Wikit for use with the new 8.3.1-based builds of Tclkit (with some extra info here [L1 ]), the results are decribed in the README at [L2 ]. This change makes the scripts of Wikit live in VFS (see [L3 ] if that sounds confusing), but the pages and history are still stored in almost the same way as before. The new file format is more efficient (time and space).
The next step will be to move all data to VFS, which will simplify all data access code. Also, the new Metakit datafile format (and s/w, which is now at 2.3.1 alpha) supports a far better form of concurrency. Ultimately, that will make the Tcl'ers Wiki scale better and handle more traffic (even as a CGI process).
So much for things related to Wikit. Evidently, I can easily sneak in changes and extensions once the conversion is carried through to the Tcl'ers Wiki itself. That will not happen before August, when the code is robust enough to continue the Wikit's track record of running flawlessly (knock wood...).
-jcw
Since the Tcl'ers Wiki is such a great place for learning about Tcl and viewing sample Tcl code, it would be nice if web accessible wikit introspection were available.
-BPT 10Sep2000
See http://www.equi4.com/pub/sk/wikit.kit/
A Wiki hierarchical table of contents might be a nice navigational aid.
-BPT 14Sep2000
DKF: 20000919 - It would be nice if pages without references to them said that there were no references to them at the bottom, instead of just omitting the Reference(s) word...
You guys are great. It's a delight to see all the productive creativity at work.
Jean-Claude, do you make judgments about what should and shouldn't be, with reference to the larger body of Wikis in use? I mean something like this: do you ever say, for example, "No, although we could implement embedded images, I don't think it's a good idea, because other Wiki sites have tried that, and {... security,accessibility,Wiki spirit,...} violations arose, and ..."? Or is this Wiki on an island, now, solely responsible for its own development, without regard to a larger Wikidom?
Do the good ideas here ever leak back out to other Wikis?
Also: while having this page is the right thing to do, I could live with the Wiki just as it already is for a long time. Adding new features is a real balancing act. I like the current Wiki plenty.
CL
Thanks :) ... balancing act indeed (also in time spent while not introducing more bugs).
I've just set up a very, very, very basic backup facility: every hour, a copy of the Tcl'ers Wiki is made, which is then accessible as "wikit2", e.g. http://purl.org/mini/cgi-bin/wikit2/19.html for this page. It can be used to recover from editing errors and clashes. Two comments:
This is a stopgap measure.
As for judgement on what to do next and what improvements to add: I very much appreciate all input. There will come a day when I get to improving things - so far, I'm trying to only fix the most glaring deficiencies.
--jcw
There should be a "Search" button in the search page, because enter doesn't always work, e.g. it doesn't work in Konqueror on my RedHat 7.0 machine and in IE 5.5 on my W2k I cannot open the page (who knows why?). It works only in Netscape, which I don't like so much and use now only for searching in this wiki ;-) --dma
June 25 2001 Bryan Oakley
I'd like a way to get back a page before it has been converted to HTML. The wikit uses the concept of a "stream" internally -- it converts a page to a stream, then the stream either to html or straight to a text widget. Getting at that stream (or something similar) would be mighty handy. That way we could write a really spiffy tk client (which I'm doing, FWIW) that could "attach" to a remote wiki. It could use the http package to fetch the data, and apply the formatting on the local side.
What's the point? With a tk client, we could have access to a much nicer client side tool. What I'm specifically after is a better editing environment with a spell checker, macros for formatting, full undo, all sorts of whizzo things.
Instead of a web browser, we'd have a wiki browser!
Cool, note that Wikit already has wiki->Tk widget conversion, when run locally - maybe that is of some use for this idea? Unfortunately, the other side of what you are asking is not possible right now. I'd be interested to discuss this further... JCW
Yes, that is the use of that data. To run the existing tk client, but have it fetch its data from a remote wiki instead of its internal database. All it needs is the stream, or even the raw page data (though, obviously, it's slightly more complicated than that...) (Bryan Oakley)
The editor Alphatk does just the above. It allows you to browse a wiki from within Alphatk (like lynx) and when you hit 'edit' it extracts the page from the HTML form which follows, and then allows you to edit the page in its very nice environment (with macros for formatting, full undo, etc) and then when you 'save' the window, it is posted back to the Wiki... all v. nice.
3 Septebmer 2001 Chris Nelson
When I want to point someone to the Wiki, I go searching for the page I want then I copy the title (from the top of the page) and the URL (from the top line of my browser) into an e-mail. The problem is, the URL in the browser is not a PURL. It would be nice if the pages rendered as:
This is the page title
(refer to this page as http://purl.org/tcl/wiki/12345.html )or some such so that I could cut and paste two lines from the top of the page and get a PURL.
--CLN
Why not just use http://purl.org/tcl/wiki/TitleOfPage such as http://purl.org/tcl/wiki/SuggestionsForWiki ?
That's fine but I'd still like it on the page so I can cut-and-paste it, not have to reconstruct it. --CLN
8 November 2001 Bruce Hartweg
Nothing spectacular & I don't know the implementation impact, but it would be nice to be able to create an anchor in a page & then be able to reference that specific point on a page. I realize the syntax might be hard not to screw up any existing pages, but it would be handy for a big page (like the Bag of algorithms) to define a section in there with a name <<section34>> and then from another page refer to it as something like [Bag of algorithms<section34>] and have only the name be visible, the the link include a #section34 at the end to jump right to the point in the page (or top of page if that anchor not defined).
Also if from external url, the auto-searching could handle it nicely, i.e. http:://wiki.tcl.tk/BagOfAlgorithms#section34 would do the same, for allowing links from outside the wiki
Yes, am thinking of adopting the TIP's "~ section" markup, which might also make a nice anchor... JCW
1 March 2002 Steve Cassidy
Being an anal valid HTML type I get annoyed at the HTML that the wiki produces which though servicable (ie. it renders ok) is far from valid. It would be a simple matter to add the proper <html> and <head> tags to the output. This might also be an opportunity to add a reference to a stylesheet which could make the wiki pages look much sexier. I'm happy to write one if you wish.
JCW: I'm all for it. The base requirement is that pages must render acceptably on Lynx (I can check that). I know *nothing* about style sheets - could you send me an example page (perhaps this one), as it is now and as you would like it to be? I can no doubt fit it in with very little effort.
LV while html and head sections are wonderful things, at least up to HTML 3.2 they were defined as optional. As for must render acceptably on Lynx, I appreciate the consideration!
17 May 2002 CM
In the Christophe Muller page, I have detailed a list of improvements for wikit that I have in mind: some that I have implemented already, some that are still being developed, and some that are just nice ideas at this time.. :-D. Do not hesitate to fix my suggestion list and/or make any comments.
ulis, 2002-07-06
When sharing a page with other Tcler's it would be great to be able to prefix the page with a summary containing for each section: the title, the author and an internal url (anchor).
2dec2002 PS:
Well, tclkit [L4 ] works just fine on my Zaurus. But as I have no X server installed on my Z (E_NO_MEM), I cannot view the wikit locally and installing a full fledged http server to run the cgi version is also a bit heavy weight.
After playing around with wikit for a while, it just seems like the perfect PDA application for storing information.
How about implementing a ultra-lightweight http server inside the wikit? Somebody must have written something like that in Tcl before, and if not - not much is needed. Most, if not all, PDAs have a graphical browser installed. It seems like a lot less work than to actually make a tclkit-linux-arm-qtEmbeded and a tclkit-Win32-CE (although I for one would love to have the former).
Like the following? - stevel
# http server modified from JCW's hpeek.tcl by Steve Landers
proc http_start {port} {
global http_fd
if {$port} {
set http_fd [socket -server http_accept $port]
}
}
# accept a new incoming tcp/ip connection
proc http_accept {sock h p} {
fconfigure $sock -blocking 0
fileevent $sock readable [list http_request $sock]
}
# process an http request
proc http_request {sock} {
set line [gets $sock]
if {[fblocked $sock]} return
fileevent $sock readable ""
fconfigure $sock -buffering full
set p /
regexp {/[^ ]*} $line p
regsub -all / $p :: p
puts $sock "HTTP/1.0 200 OK\n"
set p [string trimleft $p :]
regsub -all "::" $p "/" p
if {$p != ""} {
global topdir
set file [file join $topdir $p]
if {[file exists $file]} {
set fd [open [file join $topdir $p] r]
fconfigure $fd -encoding binary -translation binary
set img [read $fd]
close $fd
fconfigure $sock -encoding binary -translation binary
puts -nonewline $sock $img
}
} else {
puts $sock [html get]
}
catch {flush $sock}
catch {close $sock}
}
if {$argv == ""} {
set port 9108
} else {
set port [lindex $argv 0]
}
http_start $port08dec02 jcw - Been thinking about adding just a few more markup conventions (trying not to break things):
Another concern is that a few things don't work well, but these changes will require massive editing of existing pages:
Lastly, nested sub-lists don't work, and if they did we'd still have the issue of having an item consisting of some text, an indented sublist, and some more text...
It'll be hard to change things without introducing new gotcha's - but perhaps there is one guiding principle here which could help: if lines starting with 2 or more spaces are always treated as verbatim text, then one could reliably place code in it (any language, any syntax). The remaining wiki markup would then fall into two groups:
One thing to keep in mind, is that if any changes are to be made, they will need to work in web/html mode as well as in local/Tk mode.
09dec02 SC Headers would be great but why not use the TIP format of ~Title for headings (~~ could be subheadings). Also, I'd prefer sticking to just one kind of header and arrange for header alignment via the CSS stylesheet. IMHO it's confusing to see different kinds of header layout on a page/site. The Wiki should stick to 'just enough' markup, headers would be a useful addition.
The "-title" format seems a bit too likely to occur as is? Saw "!" on some other wiki, forgot which. As for simple/CSS: you have a good point there... -jcw
escargo 9 Dec 2002 - This reminds me of some other comments I made earlier. Why not have some markup that is invisible when displayed but that could tell the Wiki what wikitext renderer to use? That way you could say if that no renderer is provided, use the default one, and if one is indicated (using a name or a version or whatever) that you use the specified one. That way if pages change, the rendering will still be rational. (This approach has its own problems, of course.)
In terms of which markup to use, there might be some advantage in following Almost Free Text or other wiki markup styles. I would like to be able to have nested lists. There are some markup styles that allow them.
jcw - What do you want to do with a selectable renderer? Would that be similar to aku's suggestion to track mime types per page?
escargo - Primarily allow different encodings of wikitext. You could experiment with different conventions for nested lists, e.g., prefixes of multiple asterisks to indicate nesting of lists (one for first level, two for second level), prefixes of mixed asterisks and 1s (so you could nest a bulleted list inside a numbered one or vise versa). The main thing is flexibility. It does present problems: how do you bind a renderer to a page in a way that can't be changed (or at least changed easily)? Certainly you could build up from a literal renderer, to a full Almost Free Text renderer. Even embed HTML. If you can solve the binding problem, you don't have to use the same renderer for new pages as for old pages, and you don't have the same compatibility problems.
10dec02 jcw - Hm, that would introduce multiple formats. I'd much prefer a separate wiki setup for alternate formats, and switch to it wholesale later on if it turns out to work well, than to create per-page "modes". At least for smallish changes like these.
escargo - I understand. There are advantages and disadvantages to having multiple renderers. Keeping it simple is highly desirable. I can imagine that a renderer interface might return a success or failure code, and that processing a page could invoke a chain of renderers until one signals success, even if it is the literal renderer. But why add complexity you do not need? I can certainly respect going with a uniform renderer and running conversion scripts to transform the text to the new encoding. (Although, that is not without its own burden, since it might break the chain of CVS updates.)
DKF, 9 Dec 2002 - One of the things about the TIP Format is that it is always possible to inhibit special treatment of metacharacters by adding or removing space from the start of a line. This lets me be freer about the use of metacharacters...
jcw - The reason for bringing all this up, for me was twofold: to add just a little more layout capability (headers + subheaders), and to be able to safely embed source code in wiki markup.
The proposed changes so far are a leading "!" (bang) - strike my ^ and > suggestions - and the pipe after an URL to introduce a link title. More controversial, but IMO important, is how to get rid of the accidental capture of verbatim text as bullet items and such. There seems to be no other way than to stop intpreting lines with indent >= 2. This introduces a change which requires edits to all current pages (ouch). (though it can no doubt be scripted and done as one batch conversion). Even then, it won't be perfect: non-indented text in scripts (i.e. multi-line strings) won't fit in as is.
Not sure yet whether this is all worth doing...
SC -- searching for ~ gives me maybe 50 matches most of which won't have line initial ~ given its current useage. I'd think that ~ is just as unlikely to occur line initially as ! is and TIP compatibility is a useful thing.
The pipe after URL option is similarly useful and pretty unlikely to conflict with existing markup. I'd vote for that one.
The verbatim/bullet thing is harder to do without clobbering existing markup. It's more of a clarification of the markup which would be a nice option for new sites but perhaps not worth the effort for existing content.
jcw - Still hesitating a bit on the "-text" convention (it can be a way to write itemized list, especially is it also allows "- text"), and tip-compat, though worthwhile, is not the only reference point (as I said, I saw !text and !!text on another wiki). Some programming languages use "--" to introduce comments, so it sort of bites again for subheaders.
As for verbatim - one partial solution would be to require *precisely* three spaces for *-bullet, #/1.number lists, and :def: lists (the leading colon is new, but this is so infrequent that I wouldn't mind fixing things manually to get there). What this would solve, is that as long as source code is indented an even number of spaces (or tabs), it cannot be mistaken for other markup.
08Dec02 MT Are there any plans to add a hit counter? I am interested due to the small but steady hits a package I have, simple.sockets.tar.gz, got mentioned on the Tclers Wiki [[57]2] and most of those hits are direct hits, ie; my pages were not loaded by the visitor and since this is the only known reference on the web it must mean they are from people who access the wiki.
escargo 26 Nov 2002 - I ran into a limitation of the Wiki today. I tried to search for all the pages where I used my handle (searching for "escargo*"). Instead of getting a list, I got my own page, presumably because it matched exactly. Is there any way to get the other list?
A workaround is to search for the partial string "escarg" ...
Have you tried it? When I used "escarg*" and then "escarg" I still got to the single escargo page.
LV Hmm - I just now (Nov 26, 2002) tried it, and I get a list of about 50 pages...
I see what's happening. Instead of using the search form, I was just going up to the top of the browser and mangling the URL. In some ways that acts the same way a search does, but apparently not in all ways.
Whoa... I get *1* too, looks like there's a big nasty bug in here -jcw
This is clearly a lesson on test specification. Looking back at my initial description, I said "I tried to search", but I did not say how. It was only some back-and-forth discussion that I made it clear that I was searching through URL input, not through the Search page. That was poorly specified on my part. I am glad the dialogue continued to the point where the problem finally became clear.
Good work.
UKo what about a preview before the edited page goes really in the kit? Yes, there is something about "streams" used in the wiki on this page -- but I haven't understand what it has to do with editing and a preview, I have to admit ;-)
sm 23 Jan 2004: there's a patch to Wikit to add this functionality described at Wikit web Preview button.
UKo in local mode either on my linux box and on my iBook the fonts are too small. I have two suggestions to change this:
jcw - Good idea. I'm going to add a "source ~.wikitrc" - it's at least a first step.
Dave Bigelow - How about moving/adding "Search" and "Recent Changes" to the TOP of the pages so that they are immediately availiable to users (new ones esspecially).
DKF: Another kind of format that is interesting is that used by Mark Roseman in his projectforum stuff. In particular, if you have a look at what http://tcl.projectforum.com/tk/7 describes, you see some very nice features, such as a single '-' which gets a <br> and '*** Heading ***' which gets a heading.
You can't get best-of-breed without hybridization and evolution.