.TH twander 1 "TundraWare Inc."

.SH twander

Wander around a filesystem executing commands of your choice on
selected files and directories. If you're new to \'twander\' and want
to know why this program is better and different than whatever you're
using at the moment, take a moment to read the section called 
.B DESIGN PHILOSOPHY 
toward the end of this document first.

Similarly, if this is the first time you've worked with \'twander\',
there is a section towards the end of this document entitled
.B INSTALLING \'twander\'
which describes how the program should be installed.

.SH SYNOPSIS
twander [-bcdfhnqrstvwxy] [startdir]

.SH OPTIONS
.TP
.B startdir
Directory in which to begin. (default: ./)

If this directory does not exist or cannot be opened, \'twander\'
will display an error message and abort.

.TP
.B -b backcolor
Desired background color. (default: black)

.TP
.B -c path/name of configuration file
Specify the location and name of the configuration
file. (default is ~/.twander)

If this file does not exist or cannot be opened, \'twander\' will
display a warning to that effect but continue to run.  This is
reasonable behavior because \'twander\' provides a command to reload
the configuration file without exiting the program (which you would 
presumably do after fixing the configuration file problem).

.TP
.B -d
Start in debug mode.  (default: debug off)

The program runs, but does not actually execute any commands.
Instead, the contents of various internal tables such as the Symbol
Table and Command Table are listed on standard output. The Key
Bindings are also listed.  If the user presses a defined command key,
the command that would have been executed is printed to standard
output, but no command is actually performed.  This option is mildly
useful in debugging configuration files insfar as it will display the
command string after all substitutions of variables (both built-ins
and user-defined) has been done.

.TP
.B -f forecolor
Desired foreground color. (default: green)

.TP
.B -h
Print help information on stdout.

.TP
.B -n fontname
Name of desired font family. (e.g., courier, times, helvetica) (default: courier)

.TP
.B -q
Quiet mode - suppresses warnings. (default: warnings on)

.TP
.B -r 
Turn off automatic refreshing of directory display. (default: refresh
on)

Normally \'twander\' re-reads and displays the current directory
every few seconds to reflect any changes that might have occured to
that directory's contents.  This option is useful on slow machines (or
slow X connections) and/or when working with very large directories.
In this situtation, the frequent updating of the \'twander\' display
can make the program unacceptably slow and unresponsive.  In this case
you can still force an update manually with the REFRESH function (default
assinment is to Control-l key).

.TP
.B -s fontsize
Font size in points. (default: 12)

.TP
.B -t
Turn off quoting when substituting built-in variables. (default: quoting on)

Anytime \'twander\' encounters a reference to one of the built-in
variables (DIR, DSELECTION, DSELECTIONS, PROMPT:, SELECTION,
SELECTIONS) in a command, it will replace them with
.B double quoted
strings.  This is necessary because any of these can return values which
have embedded spaces in them.  By quoting them, they can be passed to a
command or script as a single item.  The -t option disables this behavior
and replaces the built-in variable with unquoted literals.

.TP
.B -v
Print detailed version information.

.TP
.B -w fontweight
One of:  bold, italic, underline, overstrike. (default: bold)

.TP
.B -x width
Set window width. (default: 60)

.TP
.B -y width
Set window width. (default: 25)

.SH KEYBOARD USE

By design, \'twander\' allows you to do almost everything of interest
using only the keyboard. Various \'twander\' features are thus
associated with particular keystrokes which are described below.  It
is also very simple to change the default key assignments with entries
in the configuration file, also described below.

.SH A NOTE ON KEYBOARD ARROW AND KEYPAD BEHAVIOR

Generally, the arrow and keypad keys should do what you would expect
on the system in question. On Win32 systems, particularly, there ought
to be no odd arrow/keypad behavior.  

X-Windows is somewhat more problematic in this area.  Just what an
arrow key is "supposed" to do depends on how it's been mapped in your X
server software.  Testing \'twander\' on various X servers showed
quite a bit of variability in how they handled the arrows and keypad.
So ... if you're running in an X Windows universe and arrows or keypad
do nothing, or do strange things, look into your key maps, don't blame
\'twander\'.


.SH DEFAULT KEYBOARD AND MOUSE BINDINGS

Here, ordered by category, are the default keyboard and mouse
bindings for \'twander\'.  The general format is:

.TP
.B Description (Program Function Name)
.PD 000
Default Key Assignment
.IP
Default Mouse Assignment (if any)
.PD
.P

The "Program Function Name" is the internal variable \'twander\'
uses to associate a particular feature with a particular keystroke
or mouse action.  You can ignore it unless you intend to override
the default assignments.  This use is described below in the
section entitled,
.B CHANGING KEYBOARD BINDINGS.


.SS GENERAL PROGRAM COMMANDS

This family of commands controls the operation of \'twander\' itself.

.TP
.B Quit Program (QUITPROG)
Control-q

Exit the program.

.TP
.B Re-Read Configuration File (READCONF)
Control-r

Re-read the configuration file.  This allows you to edit the
configuration file while \'twander\' is running and then read your
changes in without having to exit the program.  This is handy when
editing or changing command definitions.  However, if you edit the
configuration file and introduce an error, \'twander\' will terminate
when you try to re-read it (just as it will if you try to start the
program with a bad configuration file).

.TP
.B Refresh Display (REFRESH)
Control-l

Re-read the current directory's contents and display it.  This is most useful
if you have turned off automatic directory refreshing with the -r command
line flag.  

.TP
.B Toggle Details (TOGDETAIL)
Control-t

Toggle between detailed and filename-only views of the directory.


.SS DIRECTORY NAVIGATION

This family of commands controls movement between directories.  If at any point,
you attempt to navigate into a directory that does not exist or which
does not have appropriate permissions, \'twander\' will issue an appropriate
message, and remain in the original directory where the request was issued.
This is
.B unlike
the case of a non-existent or unreadable directory specified when the program
is first started.  In that case, \'twander\' reports the error and aborts.

.TP
.B Change Directory (CHANGEDIR)
Control-x

This is a shortcut that allows you to directly move to a new directory/path -
i.e., Without having to navigate to it.


.TP
.B Go To Home Directory (DIRHOME)
Control-h

If the "HOME" environment variable is defined on your system, this will move
you to that directory.  If the "HOME" environment variable is not defined,
this command will move to the original starting directory.

.TP
.B Go Back One Directory (DIRBACK and MOUSEBACK)
.PD 000
Control-b
.IP
Control-DoubleClick-Left-Mouse-Button
.PD

\'twander\' keeps track of every directory visited and the order in
which they are visited.  This command allows you to move back
successively until you get to the directory in which you started.
This feature is implemented as a stack - each "backing up" removes
the directory name from the visited list.  The "Directory" menu (see
.B MENU OPTIONS
below) implements a similar feature in a different way and keeps track of
all directories visited regardless of order, never discarding any entry.

.TP
.B Go To Starting Directory (DIRSTART)
Control-s

Go back to the original directory in which \'twander\' was started.

.TP
.B Go Up To Parent Directory (DIRUP and MOUSEUP)
.PD 000
Control-u
.IP
Control-DoubleClick-Right-Mouse-Button
.PD

Move to the parent of the current directory ("..").


.SS SELECTION KEYS

This family of commands controls the selection of one or more (or no)
items in the current directory.

.TP
.B Select All Items (SELALL)
Control-Comma

Select every item in the current directory.

.TP
.B Unselect All Items (SELNONE)
Control-Period

Unselect everything in the current directory.

.TP
.B Select Next Item (SELNEXT)
Control-n

Select next item down in the directory.

.TP
.B Select Previous Item (SELPREV)
Control-p

Select previous item up in the directory.

.TP
.B Select Last Item (SELEND)
Control-e

Select last item in the directory.

.TP
.B Select First Item (SELTOP)
Control-a

Select first item in the directory.  This will always be the
".." entry, but it is a quick way to get to the first part of
a very long directory listing which does not all fit on-screen.
.PP

The mouse can also be used to select one or more items.  A
single-click of the left mouse button selects a particular item.
Clicking and dragging selects an adjacent group of items.  Clicking an
item and then clicking a second item while holding down the "Shift"
key also selects an adjacent group of items.  Finally, a group
non-adjacent items can also be selected.  The first item is selected
with a single left mouse button click as usual.  Each subsequent
(non-adjacent) item is then selected by holding down the "Control"
key when clicking on the item.

.SS SCROLLING COMMANDS

If a given directory's contents cannot be displayed on a single
screen, \'twander\' supports both vertical and horizontal scrolling
via scrollbars.  This capability is doubled on the keyboard with:

.TP
.B Scroll Page Down (PGDN)
Control-v

Scroll down one page in the directory listing.

.TP
.B Scroll Page Up (PGUP)
Control-c

Scroll up one page in the directory listing.

.TP
.B Scroll Page Right (PGRT)
Control-g

Scroll to the right one page width.

.TP
.B Scroll Page Left (PGLFT)
Control-f

Scroll to the left one page width.


.SS COMMAND EXECUTION OPTIONS

This family of commands causes \'twander\' to actually
attempt to execute some command you've chosen:

.TP
.B Run Arbitrary Command (RUNCMD)
Control-z

This is a shortcut that allows you to run any command you'd like
without having to define it ahead of time in the configuration file.
It is more-or-less like having a miniature command line environment at
your disposal.

.TP
.B Run Selected File / Move To Selected Directory (SELKEY and SELMOUSE)
.PD 000
Control-space
.IP
DoubleClick-Left-Mouse-Button
.PD

If the selected item is a Directory, \'twander\' will move into
that directory when this command is issued.  If the selected item
is a file, \'twander\' will attempt to execute it.  Whether or not
the file is actually executed depends on how the underlying operating
system views that file.  

In the case of Unix-like operating systems, the execute permission
must be set for the user running \'twander\' (or their group) for the
file to be executed.

On Win32, the file will be executed if the user has permission to do
so
.B and
that file is either executable or there is a Windows association
defined for that file type.  For example, double-clicking on a
file ending with ".txt" will cause the file to be opened with
the \'notepad\' program (unless the association for ".txt" has
been changed).

If \'twander\' determines that it is running on neither a Unix-like
or Win32 system, double-clicking on a file does nothing.

.TP
.B Run User-Defined Command
User-Defined (Single Letter) Key

Each command defined in the configuration file has both a "Command
Key" and a "Command Name" associated with it.  Pressing that key
will cause the command associated with it to be run.  If no command
is associated with a given keystroke, nothing will happen.


.SH MENU OPTIONS

Although \'twander\' is primarily keyboard-oriented, several
menu-based features are also implemented to make the program
more convenient to use.  These menus appear at the top of the 
\'twander\' display window, above the directory listing. 

The first item in each menu is a dashed line ("----") which indicates
that it is a "tearoff" menu.  Clicking on the dashed line will detach
the menu from \'twander\' allowing it to be placed anywhere on screen.
Even when detatched, these menus remain current and in-sync with
\'twander\' as it continues to run.  You can also tear off multiple
instances of these menus if you'd like copies of them at several
locations on the screen simultaneously.

.SS Commands MENU

Every command defined in the configuration file is listed in this menu
by its "Command Name".  The association "Command Key" is also shown in
parenthesis.  Clicking on an item in this menu is the same as invoking
it from the keyboard by its "Command Key".  This is a convenient way
to invoke an infrequently used command whose command key you'e
forgotten.  It is also handy to confirm which commands are defined
after you've edited and reloaded the configuration file.  The commands
are listed in the order in which they are defined in the configuration
file. This allows most frequently used commands to appear at the top
of the menu by defining them first in the configuration file.

.SS Directories MENU

\'twander\' keeps track of every directory visited.  The previously
described command to move "Back" one directory allows directory naviation
in reverse traversal order - you can back up to where you started.
However, this feature "throws away" directories as it backs up, sort
of like an "undo" function.  

The "Directories" menu provides a slightly different approach to the
same task.  It keeps permanent track of every directory visited and
displays that list in sorted order.  This provides another way to move
directly to a previously visited directory without having to manually
navigate to it again, back up to it, or name it explictly using the
"Change Directory" command.


.SH LOCATION OF CONFIGURATION FILE

\'twander\' needs a configuration file in order to define commands
available to the user.  Although the program will run without a
configuration file present, it will warn you that it is doing so with
no commands defined.  Not only are commands defined in this
configuration file, but keyboard bindings can optionally be assigned
(changed from their defaults) in this file.

By default, the program expects to find configuration information in
.B $HOME/.twander
but you can override this with the -c command line option.

Actually, \'twander\' can look in a number
of places to find its configuration file.  It does this using
the following scheme (in priority order):

.IP \(bu 4
If the -c argument was given on the command line, use this argument
for a configuration file.

.IP \(bu 4
If -c was not given on the command line, but the HOME environment
variable is set, look for the a configuration file as $HOME/.twander.

.IP \(bu 4
If the HOME environment variable is not set
.B and
a -c command line argument was not provided, look
for a file called ".twander" in the directory from which
\'twander\' was invoked.


.SH CONFIGURATION FILE FORMAT


\'twander\' configuration files consist of freeform lines of text.
Each line is considered independently - no configuration line may
cross into the next line.  Whitespace is ignored within a line as are
blank lines.

There are only four possible legal lines in a \'twander\'
configuration file: Comments, User-Defined Variables, Key Binding
Statements and Command Definitions.  Everything else is considered
invalid.  \'twander\' will respond with errors or warnings as is
appropriate anytime it encounters a problem in a configuration file.
An error will cause the program to terminate, but the program
continues to run after a warning.

This is both true when the program initially loads as well as during
any subsequent configuration file reloads initiated from the keyboard
while running \'twander\'.

See the ".twander" file provided with the program distribution
for examples of valid configuration statements.

.SS Comments

A comment is begun with the "//" string which may exist anywhere on
the line.  \'twander\' strictly ignores everything from the "//" to the
end of that line without exception.  This means that "//" cannot
occur anywhere in a User-Defined Variable, Key Binding Statement, or
Command Definition.

.SS User-Defined Variables

Variables are defined using the syntax:

.nf
Variable-Name = Replacement-String

For example,

EDITOR = emacs blah blah blah blah
.fi

Later on, when defining a command, instead of typing in "emacs blah
blah blah blah", you can just refer to the variable [EDITOR] - the
brackets indicate you are
.B referring
to a previously defined variable.

Why bother with this?  Because it makes maintaining complex
configuration files easier.  If you look in the example ".twander"
configuration file provided in the program distribution, you will see
this is mighty handy when setting up complex "xterm" sessions, for
example.

Here are several other subtleties regarding User-Defined Variables:

.IP \(bu 4
The Variable Name is case-sensitive - [EDITOR], [Editor],
and [editor] all refer to different variables.

.IP \(bu 4
Variables must be defined before they are referenced - no forward
references are permitted.

.IP \(bu 4
The "=" is what separates the Variable Name from the replacement
string.  Therefore, the "=" cannot ever be part of a Variable
Name.  Neither can "//", as described previously.   Finally,
a Variable Name cannot begin with "$" (see next bullet).

Other than these minor restrictions, both Variable Names and
Replacement Characters can be any string of characters of any length.
Good judgement would suggest that Variable Names should be somewhat
self-descriptive and of reasonable length - i.e., Much shorter than
the replacement string!

.IP \(bu 4
A Variable Name must never begin with "$".  This is because a Command
Definition containing a string in the form [$something] is understood
by \'twander\' to be a reference to an
.B Environment Variable,
named "$something". If you do something like:

.nf
$MYVAR = some-string
.fi

You will never be able to subsequently reference it because,
[$MYVAR] tells \'twander\' to look in the current environment,
not its own symbol table to resolve the reference.  However, note
that "$" symbol may appear anywhere else but the first character
of a variable name.  So, for example, MY$VAR is fine.

.IP \(bu 4
Variable Names may not be redefined.  This means you can only define a
given Variable Name once per configuration file.  It is also
considered a variable redefinition if you try to use a variable name
which matches either one of the Builtin Variables (used in Command
Definitions) or one of the Program Function Names (used for key
bindings).

.IP \(bu 4
User-Defined Variables are replaced with simple string substitution
logic.  Say you have:

.n
VAR = something or other ...
.fi

Anytime \'twander\' finds a reference later to [VAR] it replaces
it with everthing from "something..." to the end of the line including
spaces within the string.  Only the leading and trailing spaces of
the right side of the variable are dropped.

.IP \(bu 4
User-Defined Variables may be
.B nested
up to 32 levels deep.  You can have constructs like:

.nf
Var1 = Foo
Var2 = Bar
FB = [Var1][Var2]
.fi

Just make sure the variable
.B definitions
precede variable
.B references.
Later on (when defining some command) when \'twander\' runs into the
variable reference [FB], it will keep substituting variables until all
[...] references have been resolved or it hits the nesting limit (32).
This limit has to be imposed to catch silly things like this:

.nf
Var = a[Var]
.fi

This recursive definition is a no-no and will be cause \'twander\'
to generate an error while parsing the configuration file and then
terminate.

Your variable definitions can also nest other kinds of variables
(Environment and Builtins).  So, constructs like this are perfectly
OK:

.nf
Var1 = [$PAGER]
Var2 = command-arguments
V    = [Var1]  [Var2]  [DSELECTIONS]
.fi

Notice that since the right-hand side of User-Defined Variables
is literally replaced later, we have to make sure there is
space between the various variable references.  If we
used "[Var1][Var2][DSELECTIONS]" we would get one long string
back instead of a command with arguments and a list of selected
items.

.IP \(bu 4
While it is true that variables must be defined before they
are referenced, \'twander\' only checks this when
.B commands
are defined, not when variables are defined.  This is because a
variable "definition" does nothing more than associate a symbol name
(the left side) with a replacement string (the right side) in the
symbol table.  It is not until that string is actually referenced in a
Command String definition that \'twander\' does the variable
dereferencing that checks for validity.  This creates an interesting
situation if you define  an illegal variable, but never
actually use it.  You edit your configuration file and add:

.nf
foo = [BAD-VBL]  // Illegal! BAD-VBL is not defined anywhere
bar = x[foo]
.fi 


\'twander\' will run fine!  Why?  Because we are merely declaring
sting substitutions, we are not actually dereferencing any variables
that appear on the right-hand side of a definition.

Now we add this to configuration file:

.nf
c mycommand blah blah blah [bar]
.fi

Now we
.B do
get an error.  Why?  Because a [...] variable reference in a Command
Definition is actually dereferenced, detecting the fact that no
definition for BAD-VBL exits.

.P
.SS Key Binding Statements

Key Binding Statements look just like User-Defined Variables.  The
\'twander\' parser automatically figures out which is which.  For a
detailed explanation of key binding, see the section below entitled,
.B CHANGING KEYBOARD BINDINGS.

.SS Command Definitions

The heart of the \'twander\' configuration process is creating
of one or more "Command Definitions".  These definitions are the
way user-defined commands are added to a given instance of \'twander\'.
A Command Definition consists of three fields separated by 
whitespace:

.nf
Command-Key  Command-Name  Command-String
.fi

The "Command Key"
.B is any single character
which can be typed on the keyboard.  This is the key that will be used
to invoke the command from the keyboard.  Command Keys are
case-sensitive.  If "m" is used as a Command Key, "M" will not invoke
that command.  Command Keys must be unique within a given
configuration file.  \'twander\' will declare an error and refuse to
run if it sees two Command Definitions with the same Command Key in a
given configuration file.

The "Command Name" is a string of any length containing any 
character (except the "//" string).  This is the name of the
command which is used to invoke the command from the Command Menu.
Command Names are case-sensitive ("command" and "Command" are different
names), but they are not required to be unique within a given configuration
file.  That is, two different Command Definitions may have identical 
Command Names associated with them, though this is not ordinarily
recommended.

The "Command String" is any arbitarary string which is what \'twander\'
actually tries to execute when the command is invoked.

In its simplest form, a Command Definition looks like this:

.nf
// A simple Command Definition
m  MyMore  more somefile
.fi

This command can be invoked pressing the "m" key on the keyboard or
selecting the "MyMore" entry from the Command Menu.  Either way,
\'twander\' will then execute the command, "more somefile".  

The problem is that this command as written actually will not give you
the result you'd like.  (For more details on why, see the
.B GOTCHAS
section below.)  It turns out that starting a non-gui program like
\'more\' in a new window needs some extra work.  What we want to do
is run \'more\' inside a copy of \'xterm\'.  Now our command looks like
this:

.nf
// Our command setup to run as a GUI window
m MyMore xterm -l -e more somefile
.fi


.SS User-Defined Variables In A Command String

The last example works quite nicely.  But, we're probably going to end up
using the string "xterm -l -e" over and over again for any
shell commands we'd like to see run in a new window.  Why not create
a User-Defined Variable for this string so we can simplify its use
throughout the whole configuration file?  Now, our command looks
like this:

.nf
// Our command enhanced with a User-Defined Variable.
// Remember that the variable has to be defined *before*
// it is referenced.
XTERM = xterm -l -e            // This defines the variable
m MyMore [XTERM] more somefile // And the command then uses it
.fi


.SS Environment Variables In A Command String

This is all very nice, but we'd really like a command to be generic
and be easily used by a variety of users.  First of all, not everyone
likes the "more" program as a pager.  In fact, on Unix-like systems,
especially, there is an environment variable ($PAGER) set by each user
which names the paging program that user prefers.  We can refer to
environment variables just like any other variable as explained
previously.  Now our command looks like this:

.nf
// Our command using both a User-Defined Variable and 
// an Environment Variable to make it more general
XTERM = xterm -l -e
m MyMore [XTERM] [$PAGER] somefile
.fi

.SS Builtin Variables In A Command String

It would also be really nice if the command applied to more than just
a single file called "somefile".  The whole point of \'twander\'
is to allow you to use the GUI to select one or more directories
and/or files and have your Command Definitions make use of those
selections.  \'twander\' uses a set of
.B Builtin Variables
to communicate the current directory and user selections to the
any commands you've defined.  Builtin Variables are referenced
just like User-Defined Variables and Environment Variables and
may be inserted any appropriate place in the Command String.
In our example, we probably want the command to pickup whatever
item the user has selected via the GUI and examine that item
with our paging program.  Now our command becomes:


.nf
// Our command in its most generic form using
// User-Defined, Environment, and Builtin Variables
XTERM = xterm -l -e
m MyMore [XTERM]  [$PAGER]  [DSELECTION]
.fi

The "DSELECTION" builtin is what communicates the currently
selected item from the GUI to your command when the command
actually gets run.

\'twander\' has a small, but rich set of Builtin Variables 
for use in your command definitions:

.IP \(bu 4
.B [DIR]

[DIR] is replaced with the current directory which \'twander\'
is viewing.

.IP \(bu 4
.B [DSELECTION]

[DSELECTION] is replaced with the fully-qualified path name
of the item currently selected in the GUI.  If more than
one item is selected, [DSELECTION] refers to the last item
in the group. 

.IP \(bu 4
.B [DSELECTIONS]

[DSELECTIONS] is replaced with the fully-qualified path
name of 
.B all
items currently selected in the GUI.

.IP \(bu 4
.B [SELECTION]

[SELECTION] is replaced with the name of the currently
selected item in the GUI.  The path to that file is
.B not
included.  As with [DSELECTION], if more than one item is selected in
the GUI, the name of the last item in the group is returned for this
variable.

.IP \(bu 4
.B [SELECTIONS]

[SELECTIONS] is replaced with the names of
.B all
items currently selected in the GUI.  The path to those names is
not included.

.IP \(bu 4
.B [PROMPT:Prompt-String]

[PROMPT:...] allows you to insert an interactive prompt for the user
anywhere you'd like in a Command String.  The user is prompted
with the "Prompt String" and this variable is replaced with their
response.  If they respond with nothing, it is interpreted as an
abort, and the command execution is terminated.  This makes commands
extremely powerful.  For instance, say you want to create a group copy
command:

.nf
// Copy a group of items to a location set by
// the user at runtime
UnixCopy  = cp -R
Win32Copy = copy

// Unix Version
c UnixCP [UnixCopy]  [DSELECTIONS]  [PROMPT:Enter Destination]

// Win32 Version
C Win32CP [UnixCopy]   [DSELECTIONS]  [PROMPT:Enter Destination]
.fi


.P
A few other points about Builtin Variables are worth noting:

.IP \(bu 4
Any of the builtins that return selections from the GUI will
always end a directory name with a path separator character
("/" or "\\").

.IP \(bu 4
User-Defined and Environment Variables are processed
at the time the configuration file is read by \'twander\'.  That
is, they are handled
.B once
at load time.

Builtin Variables are resolved
.B on each command invocation,
i.e - at runtime.

.IP \(bu 4
The results of all builtins are put inside double-quotes when they
are replaced in the command string.  This default is recommended
so that any builtin substitutions of, say, file names with spaces
in them, will be properly recognized by your commands.  You can
suppress the addition of double-quotes by using the -t command line
option when starting \'twander\'.

.IP \(bu 4
Any of the variable types may appear multiple times in the
same Command String.  For example, suppose you want to
define a generic Unix copy command:

.nf
g gencopy cp -R  [PROMPT:Enter Source]  [PROMPT:Enter Destination]
.fi

When the user presses "g" (or clicks on "gencopy" on the Command
Menu), they will be presented with two prompts, one after the other,
and then the command will run.



.SH CHANGING KEYBOARD BINDINGS

No program that runs in many operating environments can satisfy 
everyone's (anyone's!) idea of what the "correct" key bindings
should be.  An emacs user, vi user, BSD user, and Windows user
are going to differ considerably on what keys should be bound
to what feature.

It is not difficult to override the default keyboard bindings by
adding entries in the configuration file.  Doing so requires some
familiary with how Tkinter names keystrokes.  Good resources for
learning this exist abundantly on the Internet, among them:

.nf
http://www.pythonware.com/library/tkinter/introduction/index.htm
http://www.nmt.edu/tcc/help/pubs/lang.html
http://www.cs.mcgill.ca/~hv/classes/MS/TkinterPres/
.fi

Keyboard binding assignments look just like local variable definitions
in the configuration file.  (The \'twander\' configuration file parser
automatically distinguishes between key binding statements and user
variable definitions.  This means you can never use one of the program
function names as one of your own variable names.) Key binding
statements thus take the form:

.nf
PROGRAM-FUNCTION-NAME = TKINTER-KEYSTROKE-NAME
.fi

Changing the default bindings is therefore nothing more than a matter
of assigning the appropriate Program Function Name (found in
parenthesis next to the description in the default descriptions above)
to the desired keystroke.  

Examples of all the default key bindings are shown as comments in the
".twander" example configuration file supplied in the program
distribution.  The easiest way to rebind a particular function is to
uncomment the relevant line and change the right side of the
assignment to the new key you'd like to use.  More detailed
instructions on what to do are found in the example ".twander" file
itself.

It is important to observe several rules when rebinding keys:

.IP \(bu 4
It is best if keyboard navigation commands are all Control or Function
keys.  If you assign a navigation or selection function to a single
keystroke, it may conflict with a user-defined command.  If you assign
it to a keypad/special key it may conflict with that key's normal GUI
behavior.

.IP \(bu 4
The Tkinter keynames should placed on the right side of the "=" symbol
.B without any quotation marks.

.nf
So, this is correct:    QUITPROG = <F3>

But, this is not:       QUITPROG = '<F3>'
.fi

.IP \(bu 4 
The Program Function Name variables (the left side of the assignment)
may not be used as names for your own user-defined variables elsewhere
in the configuration file.  In fact, \'twander\' will never even
recognize such an attempt.  For example, suppose you try to do this:

.nf
QUITPROG = something-or-other
.fi

Because you want to be able to reference [QUITPROG] in a subsequent
command definition.  \'twander\' will actually interpret this as just
another key binding command, in this case binding the program function
QUITPROG to "something-or-other" - probably not what you intended.
Moreover, if you have a Command String somewhere with [QUITPROG] in it,
\'twander\' will declare and error and abort because it has no
User-Defined variable of that name in its symbol table.

.IP \(bu 4
When you're done making changes to the configuration file, be sure to
either restart the program or reload the configuration file to assign
the new bindings.

.IP \(bu 4
Be aware that \'twander\' does no sanity testing on the assignments
you change.  If you assign a particular \'twander\' function to
an illegal or silly key string, the program will probably blow-up
spectacularly.  At the very least, that program feature will probably
be unusable, even if \'twander\' manages to run.


.SH GOTCHAS

There are several tricky corners of \'twander\' which need
further explanation:

.B 1) Getting Command Results Displayed In A New Window

When you invoke a command via \'twander\', whether via a command
definition in the configuration file or the keyboard shortcut, you
generally want it to run in a new window.  If the program you are
running is GUI-aware, this should not be a problem.  However, if you
are using \'twander\' to run a command line program or script, you
have to take extra care in the formulation of the command string.
In the case of Unix-like systems you have to invoke the command
so that it runs in some GUI context.  Say you want to use a pager like
\'less\' to view files.  You would expect that this entry might do it:

.nf
V   view    less    [DSELECTIONS]
.fi

Sadly, this will not work, at least not the way you expect.
If you started \'twander\' from a terminal session and use
the command above, it will work, but the results will appear
in the invoking terminal window,
.B not
in a new window as you might expect. If you started \'twander\'
from a GUI or disconnected it from the initating terminal with
a \'nohup\' ... & invocation, you will get
.B no
output.  This is not a \'twander\' problem, it is innate to
how command line programs run under Unix-like shell control.  To achieve
the desired results, you'll need something like this in your
configuration file:

.nf
V   view         xterm -l -e less [DSELECTIONS]
.fi

This causes your command line program to execute in an \'xterm\'
context.

This is not so much of an issue on Win32 systems where the first
form of the command above works fine.

.B 2) Modal Operation Of New Windows

Notice our example commands above do not end with "&". 
These should not be needed on either Unix-like or Win32
operating systems.  When a command is executed, \'twander\'
starts a new thread of execution which runs concurrently
with \'twander\' itself.  This means you should be able to
continue using \'twander\' while the new command executes.
If not (\'twander\' is locked out while the new command runs -
so-called "modal" operation), it means your system does not
completely or correctly implement threading.  In that case,
if you want non-modal command operation, try adding a "&" at
the end of your command definition.

.B 3) Windows That 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
initiated with -e terminates.  This is not a \'twander\' problem.  The
workaround is to manually kill the window or press enter once when
the command is complete and the window has input focus.

.SH OTHER
You must have Python 2.2 or later installed as well as Tkinter
support installed for that release.  In the case of Win32, Tkinter
is bundled with the standard Windows Python distribution.  In
the case of Unix-like, you may have to first install Python and
then the appropriate release of Tkinter.  This is the case,
for example, with FreeBSD.

.SH BUGS AND MISFEATURES
The color options (-b, -f), font options (-n, -s, -w), and size option
(-x, -y) are
.B not
checked for validity when the command line is initially read.
If you enter something unreasonable for
these options, \'twander\' will refuse to run with some
.B really
interesting and entertaining error messages.  The program could be
more gracious about this.

The configuration file parser does no validation of key binding
override values.  It is entirely possible to bind a \'twander\'
feature to a bogus key definition.  This will cause either a
spectacular prgram failure or, at the very least, that feature will
not work correctly or at all.  The assumption here is that if you are
smart enough to want to change key bindings, you're smart enough to
learn how Tkinter names keys.  You have been warned.

This program has not been tested on MacOS.  Please let me know how/if
it works there and any issues you discover.

.SH INSTALLING \'twander\'

Installation of \'twander\' is fairly simple and takes only a few
moments.  The most important thing before installing the program is to
make sure you have Python 2.2 (or later) with Tkinter support
installed on your system.

One other note: However you install the program, it is probably
easiest to get started by editing the example ".twander" file to
taste.  Be aware that this file is shipped with everything commented
out.  You have to uncomment/edit the section relevant to your
operating system: Unix-like or Win32.

.SS Installing Using The FreeBSD Port

If you've installed \'twander\' using the FreeBSD port, all you have
to do is copy the example configuration file, ".twander" found in
/usr/local/share/doc/twander to your home directory and edit it to
taste.  

Make sure that /usr/local/bin is in your path.  To start the program,
just type "twander.py" from the shell prompt.

.SS Installing Manually On A Unix-like System

Copy the "twander.py" file to a directory somewhere on your path.
(/usr/local/bin is a good candidate).  Make sure this file has
permissions 755 and owner/group appropriate for your system
(root/wheel, root/root, or bin/bin).  Copy the ".twander" file
to your home directory and edit to taste.

To run the program, just type "twander.py" from a shell prompt.

.SS Installing Manually On A Win32 System

Copy the "twander.py" file to a directory somewhere on your path,  or
create a new directory to hold this file and add that directory path
to the PATH environment variable.  

On Win32, where to put the ".twander" configuration file raises an
interesting question.  Microsoft operating systems normally do not set
the "HOME" environment variable, because they have no notion of a
"home" directory - Well, they do, but it is called "USERPROFILE" not
"HOME".  So, you can either create a new user-specific environment
variable called HOME yourself (which points to your desired home
directory) or you can invoke \'twander\' with the -c argument to
explictly declare where it can find its configuration file.

You can run the program several ways on Win32 systems:

.IP \(bu 4
Create a Win32 shortcut which points to the "twander.py" file using
the "pythonw" command to invoke it.  Normally, starting a Python
program from the Windows GUI creates a parent window which persists as
long as the program runs. Using "pythonw" instead of "python" to run
your program suppresses the creation of this blank parent window.  For
example, you might have something like this in the "Target:" field of
your shortcut:

.nf
"C:\\Program Files\\Python22\\pythonw.exe" C:\\twander.py /
.fi

This runs the program starting at the root directory of
the current drive (assuming "twander.py" is located in C:\\".

.IP \(bu 4
Start a command line window and issue a command like the one
above directly from the command line.

.IP \(bu 4
Use Windows Explorer (or better still, an already running instance
of \'twander\'!) to navigate to the directory where "twander.py"
is located.  Double-click on the file.  If Python is properly
installed, there should be an association for ".py" file types
and \'twander\' should start automatically.


.SH DESIGN PHILOSOPHY
Graphical User Interfaces (GUIs) are a blessing and a curse. On the
one hand, they make it easy to learn and use a computer system.  On
the other, they are a real inconvenience to experienced users who are 
touch typists.  Taking hands off the keyboard to use the mouse
can really slow down a good typist.

Nowhere is this more apparent than in filesystem browsers.  In one
corner we have the GUI variants like \'Konqueror\' and \'Microsoft
Windows Explorer\'.  These are very easy to use but you pretty much
need the mouse in your hand to do anything useful.  In the other
corner are the text-based file browsers like \'List\', \'Norton
Commander\', and \'Midnight Commander\'.  These are really efficient
to use, but have limited functionality and generally do not operate
very well on
.B groups
of things.

Both of these approaches also suffer from the well-known
interface problem of "What You See Is
.B All
You Get" - Each program has a predefined set of commands and the user
cannot easily extend these with their own, new commands.

\'twander\' is a new approach to the filesystem navigation problem which
embraces the best of both the GUI-based approach and the text-based
approach.  It also provides a rich mechanism whereby each user can
easily define their own command set and thereby customize the program
as they see fit.  This is done with a number of key features:


.TP
1)
The
.B Navigation
of the filesystem is graphical - you can use the mouse to select files,
directories, or to change directories.  However, each major filesystem
navigational feature is also doubled on the keyboard (using Control keys)
so you can move around and select things without ever touching the mouse.

.TP
2)
\'twander\' also supports a number of
.B navigation shortcuts.
It provides single control-key access to changing directories, moving
to the previous directory, moving up one directory level, moving to
any previously visited directory, (de)selecting any or all
files/directories in the current view, and escaping to the operating
system to run a command.  Some (but not all) of these features are
also doubled via GUI/mouse operations.

.TP
3)
There are
.B no
built-in file or directory commands.  All commands which manipulate
the files or directories selected during navigation are user-defined.
This command definition is done in an external configuration file
using a simple but powerful command macro language.  This means that
that the command set of the program can easily be changed or expanded
without having to release a new version of \'twander\' every time.
Better still, every different user can have their own command set
defined in a way that suits their style of working.  Best of all,
commands can be invoked either graphically (with a mouse click) or via
a single keypress to minimize moving your hands off the keyboard.

.TP
4)
Because \'twander\' is written in Python using Tkinter, the same
program runs essentially identically on many Unix-like-style and Win32
systems.  The only thing that may need to be changed across these
various platforms are the command definitions in the configuration
file.  You only need to learn one interface (and the commands you've
defined) across all the different systems you use.

.P
The consequence of all this is that \'twander\' is an extremely
powerful and highly customizable filesystem navigator.  Once
learned, both navigation and command execution are lightning-fast
(or at least, as fast as your machine can go ;) while minimizing
dependency on the mouse.

.SH COPYRIGHT AND LICENSING
\'twander\' is Copyright(c) 2002 TundraWare Inc.  For terms of use, see
the twander-license.txt file in the program distribution.  If you
install \'twander\' on a FreeBSD system using the 'ports' mechanism, you
will also find this file in /usr/local/share/doc/twander.

.SH AUTHOR
.nf
Tim Daneliuk
twander@tundraware.com