'''2006-11-10''' [KBK] is attempting to edit this page by deleting all text and then reconstructing it in bits, because there appears to be a Wikit bug preventing changes to it. Please don't mess with it until this message is removed. Suspicion arises that the following problem has recurred. ---- [Lars H], 25 Nov 2004: 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], 22 Dec 2004: 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. ---- [[Wiki Fire Brigade]] ---- '''On this page:''' Things that don't work as expected in this [Wikit] implementation ---- [LV] This is more of a warning about people using the wikit than the wikit software having problems itself. I discovered this week that the lynx text web browser is at least one web browser which does not handle [unicode] properly. It is 8 bit safe; but not unicode safe. Thus, when a lynx user edits wiki pages with unicode on the page, it is likely to damage the page. I don't know about other browsers like Mozilla, Firefox, Opera, Netscape, Safari, or Internet Explorer. [Lars H]: ''Now'' (27 April 2005) you notice? If you're speaking of the slight distorsion of just about anything non-ASCII that you (AFAICT from having read [WikiDiff]) have been causing these last months, then the problem has been observed several times before. I've made at least one comment about it below. Whether "8 bit safe; but not unicode safe" is a proper description of it is another matter. The sequence of bytes sent back and forth indeed seems to be preserved as it should, but what is lost is information about the encoding. It goes out UTF-8-encoded, but when it comes back it is for some reason interpreted as being latin1-encoded, and that is all that went wrong. (It is usually possible to ungarble Wiki page contents by subjecting them to a [[encoding convertfrom utf-8]].) What should be examined by someone who has access to one of these faulty browsers is however whether the problem is that the browser sticks an incorrect encoding header on the data, or whether it is Wikit that in the absence of an encoding specification defaults to the wrong encoding. [LV] I didn't say I just noticed the problem - I said I just discovered that lynx is one of the problems. Before this week, I was under the (now known to be mistaken) believe that because lynx was 8 bit safe, that made it unicode safe. I now know that is wrong. What I '''still''' don't know is how many browsers have the same problem. I know that old versions of Netscape has problems with long lines, as does lynx. I don't know what similar problems Mozilla, Firefox, IE, Safari, etc. introduce. ---- [LES] on April 23, 2005: I was looking for the [K] combinator and tried to access http://mini.net/tcl/K (or [http://mini.net/tcl/1923]), but wikit tells me that "This is not a valid URL for this site". Why? ''[Derek Peschel] 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.'' ''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] April 12, 2005 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. [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] April 11, 2005 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 ---- [NJG] March 25, 2005 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 houskeeping 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. ---- [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] 16feb05 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] 17feb05 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] 13feb05 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.'' ---- [Lars H], 25 Nov 2004: 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], 22 Dec 2004: 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] ''23Nov2004'' There seems to be an issue when html links are placed inside preformed text. For example, the following: UhOh 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] ''24Nov2004'' 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] on June 4, 2004: I wonder why wikit no longer displays accented characters correctly: [http://mini.net/tcl/9453]. 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). [LES] Not the end of the world. That's what we deserve for relying on computers. I recorded my editing in UltraEdit and came up with this macro: InsertMode ColumnModeOff HexOff UnixReOff Find "��¢" Replace All "â" Find "��©" Replace All "é" Find "����" Replace All "í" Find "��£" Replace All "ã" Find "��§" Replace All "ç" Find "��µ" Replace All "õ" Find "��º" Replace All "ú" Find "��¡" Replace All "á" Find "��³" Replace All "ó" Find "�� " Replace All "à" Find "��¼" Replace All "ü" Find "��ª" Replace All "ê" Find "â?¦" Replace All "..." Maybe it can be reused in other pages. Of course there is a "right way" to do it, but I have to confess my ignorance about encoding manipulation. Maybe, someday... [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? ---- [mailto:bchlawrence@hotmail.com] 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 [http://www.garshol.priv.no/download/text/perl.html#id3.3.] 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. ---- I notice that each Wiki page is served with 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] 31 Oct 2003'' - 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] 24 Aug 2003'' - 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. ''This has been added to the wikit bugs tracker (see #68 at [http://tinyurl.com/okmj]), thx. -[jcw]'' ---- ''[escargo] 14 Aug 2003'' - 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] 15-Aug-2003: 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] 15 Aug 2003'' - I see. It's not a bug; it's a ''feature!'' It's nice to know. ---- 2003-06-06 [BR] - 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... ---- '''April 9 2003''' 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 1. right plain text other plain text 1. but 1. what 1. is 1. this? (look at the page source) ---- '''November 3 2002''' 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''' occurance 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: Today I discovered that a question mark (?) is also a character that results in problems. 29-Mar-1999 ---- Fredrik Lundh [http://www.pythonware.com/people/fredrik]. 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: May 26, 1999 - 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: July 9, 1999 - 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''': ''Oct. 27, 1999'' - 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''': ''Oct. 31, 1999'' - 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...''