Updated 2015-09-01 13:34:16 by pooryorick ▲

On this page: Things that don't work as expected in the previous Wikit implementation

LV: This is more of a warning to people using the wikit. Older versions of the lynx web browser do not handle unicode properly. Be certain to upgrade to the latest development version.

LES 205-04-23: I was looking for the K combinator and tried to access http://wiki.tcl.tk/K (or [1]), but wikit tells me that "This is not a valid URL for this site". Why?

Derek Peschel interjects: Good question, but I've been seeing the same problem on the 27th, when I was trying to merge two versions of a page. I was trying to search for links to the not-yet-merged page too.

LES continues: How much state about my session does Wikit keep, either on the server or in cookies? If I knew that, it might be easier to understand why certain things happen.

LV 2005-04-12:

For some reason, the wiki URL searching doesn't seem to be working. I am using
        http://wiki.tcl.tk/ProperIntegers

which should take me to a wiki page selection web page. Instead, it tells me that the term isn't found. However, if I go to search and type in Proper Integers, then I get the pages sought.

LV 2007-09-25:

This problem continues to exist. The weird thing is that some searching works as documented:
  http://wiki.tcl.tk/LarryVirden

works for me. But
  http://wiki.tcl.tk/ProperIntegers

does not.

MG: If you enter ProperIntegers in the search field (without the space, as you did it on the URL), it doesn't find anything, either. Try using one of these
  http://wiki.tcl.tk/Proper+Integers
  http://wiki.tcl.tk/Proper%20Integers
  http://wiki.tcl.tk/Proper Integers (if you're not using an old browser that won't translate the space)

LV: However, my notation is the documented manner (see Searching and bookmarking URLs on the Tcl'ers Wiki) by which the search urls should work - and in fact, some search terms do work properly that way. However, the search box was never intended to work that way. One of the little pecularities of this Wikit.

However, thank you for the other methods of notation - I was able to use one of those to get things to work for me in the short term. I just hope the bug that this phrase exhibits can be fixed.

PJR 2005-04-11:

I just downloaded wikit and there seems to be an error in:
 wikit.vfs/lib/wikit/image.tcl

line 9 has:
  export LocalImages

instead of:
  namespace export LocalImages

LV 2007-09-25: This web site no longer is based on the older version of the code, so while this error might still exist, it isn't relevant to this site.

NJG 2005-03-25:

On January 5th I placed a request on the Tcl'ers page concerning the handling of accented characters. A couple of days ago I noticed that an even more extensive damage had been done, now the title of my personal page had been busted as well. It seems as if some housekeeping program read in the wiki conent as if it were in some 8-bit character set (e.g. Windows-1250/52) and then wrote it back as UTF-8.

LV 2007-09-25:

Extensive work has been done on the new wikit code to prevent UTF damage. Given that the wikit implementation code is new, if you see this problem again, please report it via the URL listed at the top of this page.

CLN 2005-02-23: Why are half the items in today's Recent Changes not links?

  • A new(ish) feature. Pages with no content and no references to them are unclickable in the Recent Changes list. Another user had edited one of his duplicate topic/content pages with a "delete this" message indicating he didn't know how to delete pages (SG: so how does one delete a page from the wiki? I mean: not just pseudo-delete by clearing out, but actually remove the page itself, free up the number etc?). So I thought I'd lend a hand in clearing out and/or merging some of the other duplicate/obsolete/off-topic discussion pages that already had their references deleted (meaning they were essentially deleted, but still search results noise) before this feature went in.

SEH: I just wrapped a wikit starpack using the latest tclkit for linux-x86. I dropped it into my web server's home directory (/home/www-admin) and gave it executable permissions. I wrote a short script called wikit.cgi for the cgi-bin directory:
#!/usr/bin/env sh
exec /home/www-admin/wikit

and tried going to: localhost/cgi-bin/wikit.cgi/

After a long pause I got a 500 error and the error log said: "can't lock: wikit.lock"

I double-checked permissions, and another script in the cgi-bin folder writes to this same directory, so it doesn't seem to be a server config problem or permissions problem. Any ideas?

SEH 2005-02-16: Today I downloaded the starpack wikit.exe from the sdarchive and dropped it into the cgi-bin folder of my apache server on Windows 2000. I went to localhost/cgi-bin/wikit.exe/, but nothing happened except a small window popped up resembling the kind of window that appears when you do "package require Tk" in a console. When I closed that window the browser finally returned with the "My Wiki" page. Every time I click on a link the GUI window re-appears, and the call to wikit.exe doesn't return with the expected page in the browser until I manually close the window. What's up?

JSI 2005-02-16: The Wikit.exe from sdarchive is created using tclkit.exe, which contains TK for Wikit in local mode. For WiKit under CGI tclkitsh.exe (without TK) is the better choice. You can create your own starpack using SDX.KIT and tclkitsh.exe and wikit.kit. For example:
 tclkit.exe sdx.kit unwrap wikit.kit
 tclkit.exe sdx.kit wrap wikit.exe -runtime tclkitsh.exe
 ren wikit.exe wikitsh.exe
 dir wi*.exe:
 16.02.2005  21:05         1.199.025 wikitsh.exe

If you don't need to use Apache (for CSS or .HTACCESS or such), then simply use the embedded webserver: "wikit.exe -httpd 8081" and navigate to http://localhost:8081. For further details search the Wiki or drop a note here.

SEH: Thanks for the help, but wouldn't it be infinitely preferable for wikit.exe simply not to load Tk if it detects the presence of env(SCRIPT_NAME) and so goes into CGI mode? Then wikit would work regardless of which tclkit was used to wrap it, and newbies like me could get to work immediately instead of having to go through a cycle of asking for assistance.

Investigating and verifying which flavor of tclkit was used to create a starpack is pretty fine work for a product that's supposed to require zero configuration. It should Just Work, regardless.

jcw: I don't know who wrapped wikit.exe, so I can't comment on their choice. The issue is not Tclkit's fault, but Redmond's: in Windows, it's not possible to launch a command-line tclkitsh.exe and make it become a GUI as in Unix - the exe has a flag which tells the loader whether it's a DOS-box style app or whether it's a GUI app (which does not work conveniently from the command line).

The current wikit.exe was no doubt created for local mode GUI-based use, someone would just need to create and upload a wikitsh.exe to simplify the server/CGI case... OTOH, it's a simple case of starkit/starpack wrapping - is it really a good idea to manage lots of binaries when the wrap process for starkits is so straightforward?

BTW, you could also get tclkitsh.exe, get wikit.kit, and write a little batch file to launch one with the other.

SEH: I just downloaded a fresh tclkitsh.exe and wikit.kit, then unwrapped and wrapped it roughly as instructed at http://www.equi4.com/259, i.e. in my case the wrap command was: "tclkitsh.exe sdk.kit wrap wikit.exe". I got the error message "file in use, cannot be prefix: tclkitsh.exe". From this I gather that the runtime running the wrapping process can't be the one provided as the runtime included in the starpack.

I copied tclkitsh.exe to the above directory, then tried "tclkitsh.exe sdk.kit wrap wikit.exe -runtime ../tclkitsh.exe" and got a wikit.exe and a wikit.bat.

I tried to go to localhost/cgi-bin/wikit.bat/, but got an internal server error message. I opened it up and saw:
 @tclkit wikit.exe %1 %2 %3 %4 %5 %6 %7 %8 %9

Two problems suggest themselves: first, tclkit is perversely used instead of tclkitsh, thus tempting return of the original window popup problem. Second, wikit.exe is called instead of wikit.kit as expected.

I tried "tclkit wikit.exe" on a command line just to see if this could work, and in fact it didn't, I got an error message. Same with "tclkitsh wikit.exe".

I changed wikit.bat to read:
 @tclkitsh wikit.kit %1 %2 %3 %4 %5 %6 %7 %8 %9

and went to localhost/cgi-bin/wikit.bat/ again, and I got to the My Wiki intro page.

I then deleted wikit.tkd and tried simply localhost/cgi-bin/wikit.exe/, and at last successfully got to my zero-configuration Wikit CGI page.

JSI 2005-02-17: Congratulations, no kidding. Hint One: Don't delete wikit.tkd, this file contains the wiki-pages (->your work). It is automatically created with initial content on first startup. "Don't try this at home": Edit or create some pages, then delete the wikit.tkd and then revisit your Wikit: All your work is gone. Hint Two: The original wikit.exe from sdarchive can do two things, which are not possible via CGI: Rename pages and edit ALL of the first nine pages, some of them are readonly via CGI.

JSI 2005-02-13: IMO this page here could/should be shorter. Some entries are quite ancient. Should we for example refactor solved problems to some sort of Wikit-FAQ or split it into separate pages "Wikit Problems 1999", "Wikit Problems 2000", "Wikit Problems 2001",...?

jcw: - I'm all for it. Feel free split and re-org further.

LV 2007-09-25: There is now a bug database for reporting problems in the latest source code. Please use that site for reporting all bugs. Thanks.

Lars H 2004-11-25: The Tcl'ers page has been spammed, and I don't seem to be able to restore the previous contents. I did report the spammer on chongqed.org, though.

Lars H 2004-12-22: Another "not being able to save contents" problem with a particular page. This time page 12559 (Wiki Spamming), shortly before [clock format 1103726997]. Pressing the "Save" button, I get a page claiming "Page saved", but apparently my changes haven't been saved, because the page is exactly the same after I reload it. I also tried editing from another browser, but that made no change: It's claimed the changes were saved, and they were not.

RHS 2004-11-23: There seems to be an issue when html links are placed inside preformed text. For example, the following:
 <a href="http://a.site.net/apage">UhOh</a>

It shows up with an actual link labelled UhOh, whereas it should not. I'm not sure how to actually display that text without running into an error, but look at the source for the page to see that its just a normal href.

LES 2004-11-24: If you don't mind my piggybacking on your report, I also found some trouble creating char2ent because the XML numeric codes for special characters are rendered as the characters when the page is displayed. I did some experimenting and tried to escape this or that character, but could not achieve what I wanted. That is bad because if you copy and paste the code off the wiki, it won't work.

LES 2004-06-04: I wonder why wikit no longer displays accented characters correctly: [2]. It used to.

jcw: I'm afraid I messed up badly, and I apologize for that. Reinhard Max has helped figure this out recently, and we came to the conclusion that in one of my batch jobs (rename or re-pack) I must have copied pages with incorrect encodings set. As a result about two dozen pages appear to have been damaged. We started fixing it for about a dozen pages - and AFAIK everything changed from now on should be correct. The only remaining problem is when browsers mess up in an edit, but such edits can be reverted if needed.

Several pages - including 9453 - are very hard for me to fix because I don't know their languages. Please fix where you can (and if there is any regression from now on, send me a very scornful email).

Lars H: For the record, the most common case of browsers messing up the encoding seems to consist of mistaking UTF-8 for latin1. One example of this can be found in http://mini.net/tclrevs/3283-27-26 where each byte of a UTF-8 character has been mistaken for a separate latin1 character. (It doesn't exactly help that WikiDiff/tclrevs also do this display error, though. Not to mention that it makes it hard to copy back the old contents.)

The big issue is of course how to detect that something is an encoding error in the browser and not deliberate editing (e.g. fixing previous encoding errors). One way might be to have a known string containing non-ASCII characters that the browser is supposed to send back, because then it would be possible to see whether something was garbled. As I recall it, Wikit is already sending some fixed strings (e.g. a time stamp) with each edited page that has to be sent back as it were (or else the edit is rejected). Perhaps something similar could be done to check that all characters used on the page would have survived the trip?

[3] 2004-04-20 Lawrence: Hello! The standalone wikit allow hyperlink to files. Say "file://c:\a.jpg" can link to a.jpg in c:\ However I can't figure out how to use using relative paths.

Say the my_wiki.tdk is in c:\my_documents folder, and I got a.jpg in c:\my_documents. I can't open it by "file:a.jpg". however, I can use "file://c:\my_documents\a.jpg" but that will be not useful instead of a relative path. How to do that? Thx!

CMCc 2004-4-18:

Problem with bold in definition lists, which seems to react badly to colons, as follows:
::env
doesn't seem to work as one would expect.

ak's doctools generates this.

whereas
env
removing the colons produces the expected result.

Lars H 2004-03-16: I tried to make a [1]-style link [4] but Wikit screws it up. The second period in "3.3." is part of the URL, but it is not made part of the link address. Also the link comes out in full, with a strange "g" in front that isn't part of the Wiki code.

Lars H 2004-11-27: OK, now I've had a look in wikit and see what goes wrong with the above. The render helper of TextToStream processes links in three steps: free-text external links, bracketed external links, and (bracketed) internal links. Trailing periods (and several other punctuation marks) are excluded from the free-text links, which probably makes sense. The problem is that Wikit's definition of a bracketed external link is "a free-text external link which precisely fits between two brackets", i.e., the entire bracketed string must qualify as a free-text external link. This is not at all intuitive! Since the period was left out by the free-text link matching, the bracketed link doesn't match the bracketed link RE, so it isn't recognised as such. Then things go even more wrong. The brackets are caught by the internal link RE, and it is from the "stream" markup of internal links that the mysterious g above comes. That this can happen clearly demonstrates that the wikit link formatting has a bug.

Another silly thing I noticed is the following: [ Looks like a left bracket, does it not? Well, if you look at the page source you'll see it is really an ampersand and an exclamation mark. That left brackets are temporarily converted to another sequence of ASCII chars is probably also a bug.

Lars H, 2009-01-20: In current WubWikit, the first bug actually seems to have been fixed now. Hurrah! But "[" still looks like a bracket.

I notice that each Wiki page is served with
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8"></meta>

as the start of the html. However, when using Tcl's http package to get these urls (with http::geturl), the page is not seen as utf-8. This is because the header information being sent by the web server is:
HTTP/1.1 200 OK
Date: Mon, 10 Nov 2003 15:38:37 GMT
Server: Apache/1.3.27 (Unix)  (Red-Hat/Linux) mod_ssl/2.8.12 OpenSSL/0.9.6b DAV/1.0.3 PHP/4.1.2 mod_perl/1.26
Content-Location: 34.html
Vary: negotiate
TCN: choice
Last-Modified: Mon, 10 Nov 2003 15:16:20 GMT
ETag: "17328c-12c1-3fafabc4;3fafaecf"
Accept-Ranges: bytes
Content-Length: 4801
Connection: close
Content-Type: text/html

Notice no mention of charset on this last line. Is this a bug in the wikit web server or in the http package or both?

The basic result of this is that http::geturl any-wiki-page will mangle any non-ascii characters!

BR 2003-12-04: There is no default for the charset in HTTP/HTML, so the web server is correct, even though it's inconvenient that it leaves out the charset. The docs for the http package say:
STATE ARRAY

[...]

charset

    The value of the charset attribute from the Content-Type
    meta-data value.  If none was specified, this defaults to the
    RFC standard iso8859-1, or the value of $::http::defaultCharset.
    Incoming text data will be automatically converted from this
    charset to utf-8.

So you want to use
set ::http::defaultCharset utf-8

to configure the right default before using http::geturl.

RPH 2003-10-31: I downloaded and installed wikit and created a CGI script to run it, but I am totally clueless as to how to do any of the following:

  • [1] Change the title words.
  • [2] Add new pages.

The documentation is less than useful. My Wiki page is at http://vis-www.cs.umass.edu/~heller/cgi-bin/wiki.cgi - feel free to randomly mess with it.

RWT 2003-08-24: Wikit in local mode on Windows XP selection highlighting is almost invisible. The text widget on Windows (at least on my XP box) changes the text foreground to white, and white text on "LightGoldenrodYellow" selection background is really hard to read. You can fix this in gui.tcl at around line 375 by either setting -selectforeground $Color::wikiFg, or by simply not setting the -selectbackground option.

jcw: This has been added to the wikit bugs tracker (see #68 at [5]), thx.

escargo 2003-08-14: I was checking out A Toy Piano when I noticed something unusual. Most pages I go to have the name of the page on the browser title bar and on the top of the page. For the toy piano page, the title does not appear on the page itself; it might be hiding under the graphic, but it's not visible. I don't know if this is a known problem or not.

It happens with several pages with a picture at the top. I can't remember any, but I am sure I have seen them.

PT 2003-08-15:

The TclBridge page is another, and http://www.equi4.com/tclkit which also a Wikit site. I suspect this is by design to permit logo's to be used to replace the text title. If it's uninteded then a blank line at the top should fix it I think.

AK: Yes, this is by design. If the first non-empty line of the page refers to an image this image is used as the title instead of the text. See for example Starkit. Adding blank lines will not help. It has to be some text, or a separator definition.

escargo 2003-08-15: I see. It's not a bug; it's a feature! It's nice to know.

BR 2003-06-06: Several entries here mention encoding problems. I just sent in a fix to stabilize the encoding on all pages to UTF-8, and JCW applied it (many thanks). Please tell if anybody has problems with this. There may still be browsers that don't understand UTF-8 or that don't render it correctly. Meanwhile I'm going to correct all instances of bad data that i can find...

2003-04-09:

Don't know if this is mentioned elsewhere, but: more-than-three-spaces and 1. 2. 3. etc. are recognized as numbered lists. This sort of text should be treated as is instead, or am I wrong?

Example:

  • ok
  • right
  1. ok
  2. right
 plain text
 other plain text

  1. but
  2. what
  3. is
  4. this? (look at the page source)

2002-11-03:

Be careful when editing page titles in local mode, if you put in anything that would cause the page title to be unparseable as a regexp you will not be able to undo it and the page will disappear or worse!!

Example: Title a page [foo

LV: Today I ran into a problem where I attempted to put parentheses '(' and ')' in one page title and an ampersand '&' in another. in each case, Wikit seemed to not like that very much. It didn't treat the subject as a link. Also, I found that I had to remove any occurrence of a colon ':' in a page title.

JC: colons and parentheses are now accepted, but an ampersand is not allowed in the page title

LV 1999-03-29: Today I discovered that a question mark (?) is also a character that results in problems.

Fredrik Lundh [6]. I just installed Wikit on our intranet -- extremely cool, this one. A small nit, though: it doesn't handle accented characters in links properly: [Linkoping].

LV 1999-05-26: I was adding a few things to the Acronym Collection and ran into a weird problem with formatting - when I broke a line so that I could get the multiple formats, Wiki added some white space that was unexpected by me.

JC: This is correct (but unfortunate, I agree) - what happens is that a new line starts a non-indented item, which is no longer a bulleted item. So the preceding list ends, a normal line is inserted, and a new list is started on the next indented line.

LV 1999-07-09: There ought to be a way to rename wikit pages. I just noticed a typo in a page title that has content.

JC: Yes, the only way right now is to do the rename locally (because the Tk interface has rename capability). If you let me know what page needs to be renamed, I could try a remote rename through X to this server, or else download / rename / upload the Tcl'ers Wiki temporarily.

LV 1999-10-27: On I cannot get Tcl (or an extension) to compile I am having problems with square brackets. The URLs I needed to embed used them as arguments to the CGI (yuck). I tried to escape them using %5b and %5d, but the URLs no longer work. What are my alternatives?

LV: 1999-10-31: I canot figure out exactly how to deal with cases where I need embedded lists on a wiki page (ala an outline). For instance, if I wanted something that looked like:
 I. First point
  1. First subpoint
  2. Second subpoint
   i. first sub-subpoint
   ii. second ...
  3. Third ...

  • Unnumbered list item one
  • Unnumbered list item two
  • Unnumbered list item three
 II. Second point

etc.

JC 1999-11-01: I don't have answers for either of these two. The former is nasty (because there's no workaround), for the latter you can use indenation as you did to switch to fixed-format text (though then you lose Wiki's hyperlinking capability). FWIW, as the bugs/issues pile up, I intend to fix these things in one batch some day. Sorry for the lame answer...

RWT 2000-02-18: I like the feature of being able to use named URLs for direct reference to Wiki pages. I can post them in comp.lang.tcl or email them, and they make sense to the receiver. But I've noticed that when I put the URLs into a Wikipage, if I surround them with parenthesis without spaces, they don't work. For example, (http://purl.org/tcl/wiki/WikitProblems) is not even recognized as a URL, and this link with a leading space ( http://purl.org/tcl/wiki/WikitProblems) doesn't work. I have to make sure that spaces appear both before and after the URL, like this ( http://purl.org/tcl/wiki/WikitProblems )

DKF 2000-07-24: Why on earth is Wikit trying to discard all edits I make to the page Images With Transparency and Plain Images? I've tried several browsers, and none of them seem to be able to successfully commit the results back into the database!

DKF 2000-08-18: Apparently, you need to make sure that your {braces} are balanced. Shucks, thats so... conventional...

LV 2000-08-09: I am seeing a problem with Wikit actually CHANGING my edits! See http://purl.org/tcl.wiki/898.html - there are several broken URLs on this page that I fixed a number of times but that Wikit keeps breaking. Actually, there were quite a few more and I found that if I changed one a time, Wikit would accept changes to the rest of them...

EE 2000-11-23:

Whenever someone edits a page with certain characters in it, the Wikit seems to insert spurious characters before them. I theorize that this has to do with the characters in question being eight-bit, because the three characters where I have noted this behaviour are (pilcrow), and the Pounds Sterling symbol in A real problem towards the bottom.

RS 2001-01-08: I was unable to title a page "Invoking C commands from C++". This title resulted in a single close bracket when the edited New pages came back (here also). So I had to make it Invoking Tcl commands from Cplusplus.

Followup here - the wikit should do a 'syntax check' and generate some sort of warning when things like this occur; I found two more - presence of a ; and of a ? in a potential title cause the wikit heartburn, so to speak.

Anyone know of an automated way to identify which pages are not getting their page title links generated properly? For instance, Numerical Analysis in Tcl doesn't appear to be linking in properly - there should be a link back to new pages.

Automated not, but I can run a "fixpagerefs" script on the server (just did) when people tell me to... -- JC

EE 2001-06-07 15:10 EST: Now would probably be a good time to "fixpagerefs"... is there some specified official way of telling you to?

JC: You just did... refs should now be accurate again

Dossy 2004-06-04: Hey, JCW ... have you published that fixpagerefs script anywhere? Searching wiki for http://wiki.tcl.tk/fixpagerefs* doesn't come up with anything other than the Wikit Problems page. The AOLserver Wiki seems to be bitten by this issue now: This page's[7] Reference link points back to [8] when it really should be [9].

Dossy 2004-06-04: Never mind, thanks to the WiKit over at AlphaTcl [10] there was mention of fixpagerefs and a pointer to the wonderful wikitool[11] Starkit.

EE 2001-06-19: I have just discovered that I cannot do a search for something containing an unmatched brace. This makes it difficult to find a specific conde construct I'm curious about, regarding which I want to ask questions in a place where the code already exists...

2001-09-01: Apparently someone erased my question I've put here several month ago, but the problem remains unresolved. So I make another try: Using the Wiki with MSIE 5.5 under Win2000 I cannot use the search facility AT ALL: "The page cannot be found" it sais always. With the search address (http://purl.org/tcl/wiki/BOOK) provided as an example at the homepage it works for "BOOK", but whenever I change this term to another one or enter a term in the search field on that page, the same error is generated. This certainly is NOT a problem of this installation, because I've got exactly the same problem at work as well as at home. Under Linux, konqueror does open the page but the search isn't accessible either, because there is no button for search and konqueror doesn't react to 'enter' (this is the problem of konqueror, of course, but it would be easy to get around by putting a simple button on the search page). Thanks for help.
 Nov. - The problem seems to be solved now, for MSIE and for Konqueror :-)

JCW 2002-01-31: There's a problem with the encoding system in the current tclkit running this wiki. When using "extended" ASCII characters (>127) you will see strange characters being added to the page. I'm looking into this, but haven't yet been able to figure it out. It looks like the code is UTF8-encoding text (which leads to multi-byte char sequences having the upper bit set, hence the A-like squigglies). The trouble is that this is exactly what is needed on file, but somehow the output to CGI is getting confused...

jcw: Fixed in May 2004 by reinhard Max - thanks!

2002-03-18: Trying out new Tclkit, checking whether funny characters are working properly: ??? ...

2002-03-28: When I attempt to access this page as http://wiki.tcl.tk/WikitProblems I get a no matches found page from the search.

''Is this a bug or a manifestation of the design? There is a space in the name of the page. http://wiki.tcl.tk/Wikit%20Problems works, but replacing the %20 with a space character does not, taking me
 instead to the Wikit page.''

Certainly other pages on this site I can access without coding the space character in the title - what's unusual about this one?

ulis: How to change the title of a page? (I used an already used name)

jcw: can't be done on the web interface, only in local mode - just copy and point things to each other so the end result is clear

WHD 2002-07-06: If I run the Wikit Tk GUI on Windows 2000, I get a Windows 2000 error when I shut it down. The data appears to be saved OK, though....

Same bug report, moved from the [wikit development] page:

I found these bugs in wikit.exe, downloaded on 27 June 2002, running on Windows 2000. Nota that I was running it as a standalone tool using the Tk GUI, not as a CGI script.

  • Entering a backslash into the Search field results in a bgerror.
  • Exiting Wikit causes Windows 2000 to emit the following error message (the Wiki data was saved OK):
  wikit.exe has generated errors and will be closed by Windows.
  You will need to restart the program.
  An error log is being created.

  • In the Tk GUI, anyway, an extra blank line is inserted between a normal paragraph and an indented verbatim paragraph.

I've got the same error running the Tk GUI with Win2000 SP2 and the latest tclkit and wikit (September, 2002)! But it only happens if the datafile is in the actual directory: tclkit-win32.exe wikit.tkd data.dat crashes, but tclkit-win32.exe wikit.tkd k:\dir\data2.dat not!

Could you fetch the July build of tclkit and try once more? There has been a change in the build, which I hope resolves this crash-on-exit issue. I'll look at the other two bugs. -jcw

08.11.2002: latest downloads of tclkitsh-win32.exe and wikit.kit -- same error -- sorry!

From the "Wiki gripes" page - http://wiki.tcl.tk/18

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: Comments on the Tcl'ers Wiki, Suggestions for Wikit, and Wikit Problems.

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:

  • URL recognition is tricky, "(URL)" links to "URL)", for example.
  • It's yet another formatting convention (albeit a very simple one) - the basic requirement being that it must display well as HTML, and on Tk. A secondary goal is to make it reasonably obvious and readable as plain text.

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.

AK 1999-03-09: 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.

DGP: What I miss most is a Table of Contents/Index/Site Map. Since The Tcler's 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 Tcler's Wiki.

AK 1999-03-09: 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, nn@, 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).

AK 1999-03-09: 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 1999-03-23: 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 1999-03-24: 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-04-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-01-02: 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 [12] 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 PSE: Why not allow embedded HTML which will pass through unchanged? This will allow Unicodes or other entities, embedded images, etc. Could look something like
    * This is normal WikiML
<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.

DKF 2000-03-21: The problem is two-fold. Firstly, this Wiki is designed to be accessed by routes other than over the web (apparently) and these do not necessarily understand how to render HTML fully. Secondly, embedding arbitrary HTML allows some really nasty tricks with tables, frames, javascript (think of the damage you can do with onLoad), etc. Prohibiting these forces people to concentrate on real content with relatively little pain. And how do you handle the use of Unicode escapes when the browser says it cannot handle such stuff? Passing off Unicode in such situations is downright rude...

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 2000-03-21: 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: [13] [14].

Ramon Rib:

The problem of the bad encodings in the wikit, gets solved for me by adding:
fconfigure stdout -encoding [encoding system]

in file start.tcl. Please, tell me if this is a general solution.

jcw 2002-010-02: YES, that fixes it. I've added your code to the wikit sources - thanks!

Ricardo Jorge 2004-09-30: I just downloaded Wikit from http://www.equi4.com/wikit.html and the fix for encoding problem was not in place at start.tcl, so I sdx unwrap wikit.kit put the code as mentioned and then sdx wrap wikit.kit and it works for me. This is just to remind someone else looking for an encoding solution. - thanks!

2002-09-11:

I upgraded my tclkit and wikit last night and discovered that my old hack of editing the text at the top of the wikit file no longer works, It now causes some mysterious failure with the apache logs announcing:
 [[Thu Oct 10 21:55:29 2002]] [[error]] [[client 127.0.0.1]]
 couldn't read file "/apache/cgi-bin/wiki/main.tcl":
 no such file or directory

So I decided to rename "wiki" to "wikiup" and I wrote a script called "wiki" that I placed in /apache/cgi-bin/:
#!/bin/sh
export WIKIT_BASE=http://inferno.slug.org/cgi-bin/wiki/
export WIKIT_HIST=/apache/cgi-bin/history
export PATH=/apache/bin
cd /apache/cgi-bin
exec ./wikiup

And this seems to make everything go exactly as I like it.

BTW, I run Apache-2.0.43, wikit.tkd is 0600 nobody:nobody. My history directory: /apache/cgi-bin/history is 0700 nobody:nobody.

  • I run Apache suexec nobody out of /apache.
  • tclkit is kept in /apache/bin.

The CGI script I call wiki is the thingy distributed as wikit.kit, and which is popularly called Wikit

Woo! First comment on my Wiki from comp.lang.tcl (with my reply at top):
 Not my fault, Jean-Claude Wippler is no more responsible than I
 am. Maybe somewhat less so!  That's one of his distributed pages.

 Glenn Jackman wrote:
 > In comp.lang.tcl, you wrote:
 > > I have posted the details of my (highly satisfying) experience
 > ...
 > > http://wiki.tcl.tk/17
 >
 > Pretty cool.
 >
 > I found a bad link on the (uneditable) Help page:
 > http://inferno.slug.org/cgi-bin/wiki/3
 >
 >     See http://wikit.tcl.tk/IncrTcl for more details.
 >
 > Should of course be http://wiki.tcl.tk/IncrTcl
 >                            ^^^^^
 >

male 2004-06-24:

Since the revisions of wiki pages are accessible, I ask myself often why pages are listed in the Recent Changes, even if nothing has changed!

What's about changing this, to have really a "Recent Changes" page!

escargo: It seems like have a "Recent Changes" page with an automatically generated link to the diff between the most recent two versions would be good, so you can choose to focus on the change (desired behavior) or on the whole page (current behavior).

Remember that the current revisions support is, as far as I am aware, only relevant for changes made the previous day basically. Also note that if someone makes a bogus change to a page, and someone else comes along and repairs the damage, the page won't appear to have changed, but will in fact have changed.

male 2004-06-24:

A bogus change is no change and should not appear on the "Recent Change" page!

A try to save a page without changes, don't have to succeed! The wiki should take this as a cancelled edit! To act like this, there is no need of a CVS and the nightly revision mechanism!

I don't understand why this tcler's wiki has such revision mechanism, where you have to wait a day to see what had changed! Our (usemod) wiki, we use as team in the company, supports an external diff to allow revisions inspection.

The times when we had to decide, which wiki should be used, the usemod wiki (written in perl) was chosen, because of the markup language containing tables, nested (un)ordered lists, (ordered) headings, this diff capability and a users recognition via cookie admin!

escargo 2004-06-24: I found this fragment at the end of the category list; maybe somebody who knows what it should be could put it where it belongs: s.umass.edu/~heller/cgi-bin/wiki.cgi/10

Robert Heller has a page here, and mentions http://www.cs.umass.edu/~heller/ on his page, I wonder if http://vis-www.cs.umass.edu/~heller/cgi-bin/wiki.cgi/10 is a valid page. http://vis-www.cs.umass.edu/~heller/cgi-bin/wiki.cgi/0 is the top of his wiki - and page 10 is an empty page relating to starkits...

LES 2004-08: Why would someone try to insert a picture into a piece of code? No reason, I guess. But wikit tries to parse (img border="0" src=") and display a picture at TclHttpd RSS Processing. Looks like a bug to me.

But, wait! It only happens in my Mozila Firefox 0.8! Not in Internet Explorer 5. Hmmm... Maybe I just cried "wolf"...

Lars H 2004-09-14: Many IP numbers in the recent changes page look very strange, with three or fewer components. Here's some of the HTML for that page, showing this:

KBK 2006-11-10: Lars's HTML has been elided, since it apparently causes Wikit to make this page uneditable!

jcw 2004-09-13: Cleaned up some weird cross-reference and title problems. The wiki DB should be 100% consistent again now. I caused most of the problems by copying a modified copy over a live DB, silly me. One other problem was caused by double spaces in the title (which can no longer happen, it must have been a left-over from earlier times).

I've also just changed the SearchResults proc to ignore pages with exactly 1 char on them. I usually (pseudo-)delete pages by storing just a single space in them. From now on, these pages will no longer show up in a search. They do show up in the Recent Changes because otherwise no-one would see it when an entire page is cleared this way.

escargo 2005-07-22: The following paragraph illustrates a problem. The bold text spans too many words:

If you click on the taskbar icon for the two apps the iconnames show but the iconnames don't update! Even more amusing is that the iconnames appear in tooltips when you roll over the iconnames with the updated values that are not shown in the iconnames.

For some reason, the closing triple quotation marks are not closing the first set, and the embolden treatment is continuing.

Another problem that I found; consecutive links get combined and only a malformed link gets coded:

An bad example of including a link that will be numbered [15][16] followed by another one.

An good example of including a link that will be numbered [17] [18] followed by another one.

There are really two links in the markup, but only one gets displayed.

Lars H: The first problem can often be worked around by not putting the entire paragraph on a single line, but I suspect you already know that.

The linking problem is another effect of Wikit's "free-text links first, bracketed links later" processing which IMO in very Murphy (whenever it can get it wrong, it will). See my comments dated 2004-11-27 above for details.

MG: I've just looked at the code for Wiki (assuming I downloaded the right thing), and it looks like the problem is in format.tcl (the 'render' proc):
while {
    [regsub -all {'''([^']+?)'''} $text "\0\1b+\0\\1\0\1b-\0" text] ||
    [regsub -all {''([^']+?)''}   $text "\0\1i+\0\\1\0\1i-\0" text]
} {}

# And then the remaining ones. This also captures the hilites
# where the highlighted text contains single apostrophes.

regsub -all {'''(.+?)'''} $text "\0\1b+\0\\1\0\1b-\0" text
regsub -all {''(.+?)''}   $text "\0\1i+\0\\1\0\1i-\0" text

Those first two regsub commands (inside the while loop) aren't needed, by the looks of it, and seem to be what's breaking it. Though I've only looked at it briefly - there could be something earlier that requires those.

And I think the link problem comes from this line (also in the render proc of format.tcl):
set pre  {\[([^\]]*)]}  ; # page references ; # compat

Which should, I think, be
set pre  {\[([^\]]*?)]}  ; # page references ; # compat

to make it non-greedy. None of that's tested, or even looked at too heavily - just some quick glances while I had a few minutes free - but I think it's right.

escargo 2005-07-25: Is Google supposed to be indexing the "Differences" pages? Or is somebody retrieving them and making them available inappropriately? (See http://matsuri.site.ne.jp/neko/neko.cgi?KEYCODE=&URL=http://mini.net/tclrevs/3011-2 for an example.)

escargo 2005-08-17: The following line does not format as a tagged list item, despite conforming to the formatting rules statement: "To create a tagged list, use: three spaces, item tag, ":", three spaces, item text"
::math::sum
calculate arithmetic sum of two or more arguments

I suppose the problem relates to all those extra colons.

escargo 2005-10-17: I wanted to use a definition list to reformat the Consio page a bit, but this problem still exists; is there any workaround that allows the namespace separators ("::") to be rendered without causing the definition list formatting to fail?

Andreas Otto 2005-10-06:

1) I have installed wikit and use the following line to start the application:
 tclkit-solaris-sparc wikit.kit -httpd 8090 something.tkd

the problem is that I allways get "My Wiki" as main page name => how can I change it ?

jcw interjects: You can only rename pages in Tk local mode. I do it by tunneling X11 through SSH, or temporarily moving the datafile to a local machine.

Andreas Otto continues:

2) an easy command-line help would be useful:
 >tclkit-solaris-sparc wikit.kit -h
 unknown option: -h
    while executing
 "source wikit.kit/main.tcl"
    ("uplevel" body line 1)
    invoked from within
 "uplevel [list source [file join $self main.tcl]]"

it was very difficult to figure out the -httpd PORT option

Thanks for your work !!

jcw interjects: Indeed, only docs are some scattered info on the web, and of course the WOS (Wide Open Source) itself ;) - patches are always welcome. Thx.

Andreas Otto continues:

3) using an X window system session on windows and starting the wiki with:
   ./tclkit-solaris-sparc wikit.kit Portal.tkd

works but the backspace key does not work (erase works)

4) starting the same wiki on the same share but mounted to windows with:
   tclkit-win32.exe wikit.kit Portal.tkd

crashes the wiki after saving and the whole information is gone

5) I would like to use pictures in the wiki but I found out that it is only available as link like:
   http://www.equi4.com/images/wikit.gif

but I start the wiki using the internal webserver like:
   ./tclkit-solaris-sparc wikit.kit -httpd 9080 Portal.tkd

Question: How I can add a picture to the internal web server ? or can I put the images locally on the share and provide the internal webserver with an external image directory

SG: I think this is answered in Adding images to local mode wikis

HZe 2005-11-19:

Only a small issue: when I use my PocketPC/WLAN to read this Wikit (by the way: it's really good displayed on a small device like this), I cannot use the Search page. It uses <isindex> for the search phrase and the Internet Explorer on my PocketPC doesn't show this tag at all. Would it be possible to just change this into an <input> element?

An alternative is to type the search in the URL: http://mini.net/tcl/2?holger*

Lars H 2005-12-14: Page 8932 [19] has a title that seems to have been malencoded (Onze règles, rather than Onze régles). Is this a Wikit bug or user error? (The latter seems a bit unlikely, as page titles shouldn't suffer from the same saving-in-unaware-browser bug as the page contents do.)

MHo: wikit in CGI-mode: if you edit a page through your browser, then hit save or cancel and then the browser's back-button, you are again in edit mode. But what you possible wanted was to return to the previous page from where you navigated to this page. You have to klick on References and manually choose the page from where you came.

KBK 2006-11-11: I found it necessary to delete several lines of HTML that Lars H had posted giving sample output from an earlier malfunction of the Tcl'ers Wiki. The presence of these lines, presented to the Wiki as if preformatted text had been requested, caused this page to become uneditable. Refer to the page history prior to 2006-11-10 to retrieve the problematic text, which apparently had been saved without adverse consequences on an earlier version of Wikit.

Proposed solutions to the current problems, Discussion

Category WikitCategory Tcler's Wiki