Purpose: a place to list weird side effects, surprises, and ... gripes, with regards to the concept of Wiki Wiki webs, or Wiki in short. Related pages:
JC: Some of the comments below ought to be moved to the above (new) ones, I think
The concept of Wiki is fascinating. Here's a list of thing which may need some improvement, please feel free to add notes:
AK: I would like to embed image references and have the converter recognize them, showing the image instead of a simple link.
AK: I could have added this to Comments on the Tcl'ers Wiki, but my solution is more a general Wiki thing, so I did it here instead. I found no links to Gripes, Suggestions and Comments pages other than in the ChangeLog itself. It might be nice to have some sort of overview page containing references to all pages in the Wiki Web (Sitemap).
AK: Ok, I found the main references to the pages mentioned above, in Jean-Claude Wipplers page, but I think it illustrates a general problem. A Wiki usually grows in unpredecented ways, and very unstructured, thus easily causing the "lost in (hyper)space" syndrome: Where am I, where were I, how do I find X. I believe that at least one (trusted) user, in case of complex Wiki's some more, should try to "moderate" an area. Hm. ... I am not thinking of moderation in the sense of "pre-edit approval", it is more like gardening. First a spurt(?) of growth, then the moderator/gardener starts weeding (removing OT-post), structures the contents into something more coherent, afterward the next cycle of growth and weeding begins. These phases may overlap, of course.
JC: Does the new search capability compensate for the lack of a site map?
1999 Mar 9, AK: I thought to say "yes", but then I noticed that the search facility cuts the returned result at 50 entries, just like the recent page. So I have to say "Not quite". A sitemap tells us what we have, in a clear manner. Using a search facility however is more like being blind and probing, we don't know about the possible contents of the site, what we can search for.
1999 Mar 9
DGP: What I miss most is a Table of Contents/Index/Site Map. Since The Tcl'ers Wiki is promoted as the entry point, there ought to be available on that page, or on a page linked by that page, some way to find all the pages there are. I thought the New Pages page might be it, but it seems not. I first entered the Wiki on package management, following AK's link in c.l.t. I don't think I could have ever found that starting from The Tcl'ers Wiki.
1999 Mar 9, AK, Remark: My link in c.l.t. used a feature of this wiki, the auto-search. If the url given to the cgi does not match the various standard formats (nn.html, [email protected], nn!, ..., nn a number) it will start a search for possibly matching pages. A single word must be used, but capitalization can be used to mark inner components. The search will automatically add * between them before starting the search (LaVi => La*Vi for example).
1999 Mar 9, AK: The recent changes page is a quite good approximation of a sitemap, but currently had the problem that some huge content (Books, Tcl-URL!) was added to the wiki in the last days, overflowing the limit of 50 entries quite drastically. Many of the useful other pages were ousted because of this. Setting the limit to 100 entries could.
BSA 23-Mar-1999: Q: Why do we have to edit in yet another special format, What is wrong with just using html? (other than complexity for new users). NB I am new to the wiki experience and haven't read the FAQ if indeed there is a link to it here.
AK, Mar 24, 1999: IMHO you already gave the answer: complexity for new users. A wiki tries to encourage readers to start writing too. A (simple) formatting language which is mainly text with interspersed commands should fare better in this regard than something like HTML, where it is quite easy to get lost in heaps of markup with interspersed fragments of text.
It's up to the people writing the Wiki to make sure that new users can find their way around. On Ward Cunningham's wiki this is done by a writing pages to welcome new users and roadmap pages for major topics.
DGP, 1999 April 20: It's really annoying that you can't italicize more than once per line. Also, how does one include a literal "[" in their text ( I guess I just did. ) without triggering another page marker. It's awkward trying to document Tcl usage with these quirks.
JC: On normal lines (not bullet lists and such), you can italicize by starting a new line, since formatting codes are recognized per line, even though they end up concatenated into one, see WOBBLE for an example. Brackets can be escaped by doubling them. Like [ and ]. I've added a note in the Formatting Rules page, thanks.
BG, 2000 Jan 2: I found that good old buggy Netscape would crash consistently once the single textarea post data grew enough. I had to crank up good old WebTk[L1 ] to get the form to post.
RS, 2000-03-15: I'd like to be able to include Unicode entitities like 中国 in a Wiki page, but the ampersands get escaped, even with one or two backslashes in front. 2000-03-21: A more general thought, prompted by PS: Why not allow embedded HTML which will pass through unchanged? This will allow Unicodes or other entities, embedded images, etc. Could look something like
<HTML><h2>Chinese Header 中</h2></HTML> ---- And now we're back to WikiML again.
and everything between <HTML> and </HTML> would be copied as-is.
RS, 2000-03-21: Well.. we have kind of a class society where some browsers (getting more) can display Unicodes, and other can't (and show a question mark instead - also depends on the fonts you have, etc.). I see the point against arbitrary HTML, but &entities; (;-) can't do much more harm than being rendered as a "?", so I still advocate allowing them.
JC, same day: Yes, richer content (and how about images?) sounds attractive. It's true that WiKit runs as both CGI-generating-HTML and as local Tk app. Both of these wil probably handle extended character sets quite well nowadays (I still use an 8.0 TclKit for this web site, but I have an 8.3-based one ready to go). Also, Richard Hipp's TkHTML widget is up to an amazing level of functionality, so HTML in local mode is becoming a more realistic option (I'll need to check the Mac side). But what kept me from making all sorts of changes, is that the current setup works well from a more modest goal and "if it ain't broke don't fix it" (whether it is broken or lacking new features is debatable). I find the current wiki markup pleasant to use as is. So here's my next excuse (hey, I have loads of 'em): TclKit and the scripted document mechanism are both undergoing major changes. The new TclKit uses Matt Newman's Virtual File System (VFS) approach, which is a fascinating way to hide differences between file systems and databases. So I've been sort of holding back (for months now), before going into WiKit again and changing things. To prove that these excuses are not completely lame: TclKit 8.3 has become viable about a week ago, and I've started switching to it in a commercial project only two days ago. So there is measurable progress. Not that it's enough to make a difference for the issues raised here yet... :o(
If someone wants to work on some of this, let me know. It would make a good excuse for me to bring WiKit to the new setup, and it'll be much easier to modify and try out things, because with VFS you could run WiKit either as a scripted document or from a regular directory with a set of scripts.
Bryan Oakley, 2000-05-15: I wish that multiple references to the same external document would have the same number in 's. For example, the following two references both point to the same location, but appear as distinct numbers: [L2 ] [L3 ].
Dossy, 2001-05-14: It seems that surrounding text that contains parenthesis by a pair of single-quotes (to try and italicize it) doesn't work: this is a test (and will fail) because of the parenthesis between the pairs of single-quotes. Interesting, was this fixed (my WiKit may be old and outdated by now ...) Ah, it seems to be when there's a matching set of single-quotes (') between a pair of single quotes ... that's a big drag. Is there a "right way" of doing this, other than to break up lines and surround each with a pair of single-quotes?
AEC, 2002-05-03: I acquired tclkit from the downloads page and renamed it to tclkit.exe: /pub/tktclkit-win32.upx.exe 30-Apr-2002 05:55 862k. Wikit.bin.txt was next downloaded: /pub/tk/examples/wikit.bin 07-Nov-2000 01:45 43k. A windows shortcut was created to run wikit. I executed this shortcut by clicking on it. Several new pages created within wikit. I navigated among the pages and then exited the application. When I attempted to restart the application the following error message appeared:
couldn't read file "wikit.bin/Html_library.tcl":No error
I am running on a windows NT workstation. Is this a known error? Is there a fix?
JCW, same day - I'm looking into this now, got another similar bug report a few days ago, so it looks like I messed up some sort of compatibility issue. Note that you can salvage all page contents with "wikitool", see [L4 ].
escargo 3 Mar 2003 - The following text gave me unexpected results when I added it to my own page. I don't know if this is a problem with Formatting Rules not covering this case, or if there is a problem with interpreting the markup. Contrast the editable versions of these two pairs of lines (not the same!):
It looks like some parser is getting thrown by the paranthetical.
Also, didn't there used to be a link from the front page to the Graffiti page? It's not there anymore.
Also, if you search for "graf" you will find three pages, probably two more than are really needed:
escargo 6 Mar 2003 - If I use the Search page and search for "test" I do not get references for titles that contain "tcltest". Is there are reason why?
Yes - Wikit searchs are prefix anchored. Thus, when you search for test, you will find titles with the words test, tests, testing, testable. However, tcltest has test as a suffix - which the search will not find. Do a full text search (search for test*) and I believe then you should find tcltest.
escargo 7 Mar 2003 - Using the search box and entering a search for "*test" produced No matches found (so the results of searching for "test", "*test", and "test*" produce radically different results). There does not appear to be any way to do a wild card search of just the titles. That seems like a significant functional limitation.