diff --git a/twander.1 b/twander.1 index 4f8279d..c9b0615 100644 --- a/twander.1 +++ b/twander.1 @@ -2635,12 +2635,24 @@ .B and under a shell interpreter. -This is not much of an issue on Win32 systems where the first +This is not as much an issue on Win32 systems where the first form of the command above works fine. Win32 appears to have no problem invoking a new window whether the command is GUI-aware or not. -.SS Using Wildcards In Command Definitions +However, +.B which +terminal window is used for output can be confusing. If you +start \'twander\' from a terminal session, +all terminal output will be sent to +.B the terminal session you used to invoke the program. +The way to work around this is to start \'twander\' from a Win32 +shortcut, using \'pythonw.exe\' rather than \'python.exe\'. Now +each time you run a command that needs a terminal session for +output, Win32 will automatically create that session for you. + + +.SS Using Shell Wildcards In Command Definitions The [PROMPT:...] Built-In Variable is provided to make it possible to write general-purpose commands which @@ -2736,7 +2748,7 @@ invoke new commands using conventional (heavyweight) process spawning. -.SS Windows That Don't Disappear On Command Completion +.SS Windows Don't Disappear On Command Completion It appears that some X Windows implementations (noted on XFree86 / FreeBSD) do not correctly destroy an \'xterm\' window after a command @@ -2755,6 +2767,120 @@ threads rather than processes. Once again, the workaround here is to set "USETHREADS=False" in the Configuration File. +.SS Really Slow Response Times When Changing To A New Directory + +You may occasionally see +.B really +slow response times when you change to a new directory. This occurs +when you enter a huge directory with thousands of file or subdirectory +entries. \'twander\' has to to compute the detail information for +each of these entries and this can take a lot of time. On a fast +machine with modern hard drives and controllers, \'twander\' is able +to process several thousand entries in just a second or two. However, +a number of factors can significantly slow down this process: + +.IP \(bu 4 +The Autorefresh interval is set too low. Processing the directory +takes so long that as soon as one refresh finishes, the next starts +right away. The program will appear to hang. There are two +possibilities here. Either disable autorefreshing (via the -r command +line option or the AUTOREFRESH Configuration File option), or set the +REFRESHINT value to some high number so that \'twander\' has plenty +of time to process a directory before the next refresh occurs. + +.IP \(bu 4 +Slow disk drives. You can really watch \'twander\' grind if you +change to a large directory on a CDROM, for instance. There is no +good solution here. These drives are inherently slower than hard +drives, and you just have to wait. Make sure you lengthen your +refresh interval as described in the previous bullet. + +.IP \(bu 4 +By far the worst culprit here, though, is when running Win32 +with \'win32all\' options enabled. It takes a lot more work +to get win32all-style information about each directory entry, +than the default Unix-style information. Simply turning +off \'win32all\' features alone can speed up directory processing +by a factor as high as 4X. + +.P +When you combine these factors, it is possible to get really +long processing times. One test situation we observed was +reading a directory with over 4000 entries on a Win32 CDROM. +With \'win32all\' processing enabled this took over a minute. +By disabling these features, the time came down to under 30 seconds. + +.SS Your Configuration File Does Not Produce The Desired Results + +It's easy to fall into the trap of treating the \'twander\' +configuration capabilities as a real "programming language". +It is not, it is a fairly simple macro language that does +very little more than string substitutions. You should thus kee these +rules in mind as you edit your configuration: + + +.IP \(bu 4 +Except for conditional tests, Environment Variables and User-Defined +Variables are never resolved +.B until they appear in a Command Definition. + +.IP \(bu 4 +Option Statements, Key Binding Statements, Directory Shortcut +Statements, and Wildcard Statements +.B are treated literally +with no variable substitution ever done to their Right Hand Side. + +.IP \(bu 4 +A Conditional Statement always involves a variable +.B reference, +never just a variable name. + +.IP \(bu 4 +For a Conditional Statement to be true, the referenced variable +.B must be defined +and any equality test must be satisfied. + +.P +Common mistakes include: + +.nf +##### +# Trying to embed a variable where it will never be resolved +##### + +DIRSC03 = [$SystemDrive]\\Program Files +MYCOLOR = blue +FCOLOR = [MYCOLOR] + +##### +# Expecting a conditional variable to be resolved before the test +# Suppose $EDITOR is set to "/usr/local/bin/emacs" ... +##### + +EDT = [$EDITOR] + +##### +# The following will be False because [EDT] equals +# the string "[$EDITOR]". It is not replaced +# with "/usr/local/bin/emacs" until [EDT] appears +# in a Command Definition +##### + + .if [EDT] == /usr/local/bin/emacs + ... + .endif + + +# Note, however, that *this* would work because +# Environment Variables are permitted in conditionals ... + + .if [$EDITOR] == /usr/local/bin/emacs + ... + .endif + +.fi + + .SH OTHER File/Directory name sorting is done without-case sensitivity on @@ -2776,6 +2902,17 @@ You must install the \'win32all\' extensions if you want to use the advanced Win32 features. +You'll find the latest version, and occasionally, Release Candidates +of the next version of \'twander\' at: + +.nf +http://www.tundraware.com/Software/twander +.fi + +You should check this site regularly for updates and bug-fixes. The +\'WHATSNEW.txt\' file describes changes since the last public release +of the program. + .SH BUGS AND MISFEATURES As of this release, a number of problems relating to \'twander\'