Here is the revision history of TSnip. If you feel there are other improvements that could be made feel free to contact me and suggest them. My real-world and e-mail addresses are in the TSnip.doc file. ** Minor enhancements in 1.4a ** - Emacs bindings while in editor mode: - command line options -vi and -emacs to set editor type - additional tooltype EDITOR=vi or emacs - sendline routine now handles control characters - bug fix for output to stdout and pipe files -- extraneous null characters no longer added (this caused problems for editors like DME) - bug fix for clipboard output -- previously each line cut was over- writing the last one ** New features in 1.4 ** - everything now compiles under 16 bit Aztec - control panel lets you change font, output file, text colour, output destination on the fly; position of the control panel is remembered when it's closed - plain English explanations of what is happening printed while control panel active - TSnip will no longer interfere with mouse handlers which auto- activate windows, via control file "handler-commands". This option can be set by "-m" command switch, and toggled by the "m" key while TSnip is running. - TSnip window(s) can be switched between multiple screens via new keyboard option, . Repositioning of windows is reasonably intelligent when moving to a screen of different size. - new keyboard option "q" tells you the colour of the pixel underneath the mouse; if you have some text printed in JAM2 mode, ie 2 solid colours, you can use the TextPen gadget on the control panel to make TSnip recognize only a single colour as legal text. - location of the 8x8 square recognized as a character can be reset to default position by new keyboard option - TSnip no longer detaches from the CLI, you must use "run" again; this is due to the workings of the mouse-handler option - added ability to run from an icon, with customizable set of options - new CLI option / keyboard command "e" to toggle vi edit mode, where mouse is used for cursor positioning; setup options from CLI or Workbench for using vi along with VT100 or Z Bugs? Some may have been introduced in the final stages, since I've added a lot of features lately and may not have tested every possible combination of features since. However I've been using TSnip 1.4 extensively lately and haven't encountered any that haven't been fixed. Please let me know if you find any. The future? There are enhancements I want to make, compatibility for the future with keymaps and gadgets that I'll have to investigate. Right now I haven't a lot of time for programming so I'll release TSnip at the stage it's currently in; otherwise creeping featurism will keep me tinkering with it forever. I already have definite plans for different font sizes and much faster recognition... ** New features in 1.3 ** - new option -a, to have Snip window re-activate itself after pasting to the keyboard (which requires that another window be activated) - bug due to Manx's "detach" module fixed by adding -o option, which writes output to a file when -s (standard output) is selected - Snip will run on any screen currently open; make sure you terminate Snip before closing any screen it is running on, otherwise you may be in danger of crashing This is primarily a bug fix / minor functionality enhancement version as opposed to 1.2 which added major new capabilities. ** New features in 1.2 ** - new save formats (clipboard and two methods for redirection into the input stream) - the "-c" option now works, and causes text to be written to the clipboard - new options "-k" and "-K" allow you to paste text back into any window that you would normally type into. "-k" writes the block of text back using carriage returns to terminate each line, "-K" writes the text back as one long line. - new key commands 'k' and 'K' allow you to select the equivalent output options at any time - support for *any* 8 x 8 font (see SNIPGEN.DOC for details on -f option) - supplied program to generate font definition files for new fonts - extended help message - now detaches from CLI window so you don't need to 'run' it, and never eats more than 4K stack Bugs/caveats: - Certain operations, such as window depth-arranging or the appearance of requesters, have caused me lockups in the past if they occur while an area of text is being outlined (since I lock the layers of a window which may be on the WB screen). Note that this will be an exceptional case since the mouse will be operating TSNIP. I don't know about interaction with programs that use window-to-front to keep themselves on top of the display. - Outlining of text must be from top-left to bottom-right, although the box will follow the mouse correctly in all directions. - Unrecognized characters are signalled by a '?'. These will be those in reverse, bold, italics, or underline or special accented characters - the method of inserting rawkey events into the input stream may not work with different keymaps; I don't know how to get around this short of altering the internal tables I use; if I can find a way I will make it fully keymap-compatible - the new -k and -K options may overflow the output buffer of some programs, for instance if you paste a large section of text into a terminal program operating at 1200 baud. If this turns out to be a big problem I'll allow some form of delay in the output, but that's the only scenario I've been able to cause any problems in so far.