File: XTree:\Forum archive |Bottom_of_page

| View Thread | Return to Index | Read Prev Msg | Read Next Msg |

XTree Forum archive

Integrated Navigation/Spell PROPOSAL - SUMMARY

Posted By: Walter Rassbach <>
Date: Wednesday, 30 September 1998, at 11:22 p.m.

In Response To: Integrated Navigation/Spell PROPOSAL (Walter Rassbach)

The integrated navigation/spell proposal combines two proposals (one by myself and one by John Gruener -- See the referenced thread) to extend/enhance the current shift-letter "jump to" feature. An enhancement is needed due to the orders-of-magnitude increase in the number of files on a disk/partition (often > 20-50,000 nowdays). The navigation/spell feature is related to the FileSpec and TreeSpec features but provides a different kind of functionality. The emphasis is on File/B/G/S scroll-lists/views but the feature also applies to the directory/tree view.

[NEW:] In addition to the filename/extension spelling capabilities, the proposal suggests methods for indicating file attributes (RASH) as part of the selection capabilities, and this feature would be significantly enhanced by the treatment of TAGged as "just another attribute" which has also been independently proposed. There are two possible mechanisms suggested herein, one of which uses the '*' (currently unused in a File/B/G/S window but a key it might be nice to reserve) and the other which uses the single-quote escape mechanism proposed in (A).

"Navigation" and "SpellMode" are really just two different interfaces to the same basic function, which is used to locate and select (put the highlight bar on) a file according to information entered by the user, mainly the first few characters of the filename and/or extension and/or by attribute/tag flags. The "navigation" interface is designed for efficient (minimal keystrokes) "quick and 'dirty'" (athough it is fairly clean) usage while the "SpellMode" interface provides additional features (history, additional selection criteria, wildcards, editing, etc.), completeness (e.g., all filename characters are available), and closer ties to the FileSpec mechanism. The Navigation interface must be "fitted around" the existing HotKey/command structure (it is really just a specific set of HotKeys itself) and is subject to some compromises while the SpellMode interface is triggered by a specific HotKey/command, uses standard prompting methods, and is not subject to the same compromises.

Navigation is expected to be primarily used for entering just a few (4-7) characters of the filename, extension, or attributes/tags, and this fact sharply reduces the effects of some of the compromises (in particular, lack of space, comma, and period) needed to "fit" it around the HotKey/command structure.


A) Except for space, comma, and period, all of the characters which are valid in a filename are available for and used by the navigation interface, with alpha characters entered using shift-letters (with case ignored) and are called "nav.keys". In the directory/tree view, the characters - + = are also not available (unless there is a configuration option). In addition, single-quote might [TBD] be used as an "escape" to allow entry of space, comma, period, - + =, and, of course, single-quote (other keys might also be escaped or have special functions).

B) An unbroken sequence of "nav.keys" (a "nav.string") provides additional leading characters of a filename (and/or extension or attributes/tags). Except as specified below, pressing any other key (including ALT or CTRL) breaks the sequence and a subsequent "nav.key" starts navigation over at the first filename character.

C) The last or currently-being-entered "nav.string" is displayed in the path line (top of the window) using an appropriate color scheme. This color scheme also indicates whether a nav.string is currently being entered.

D) While a "nav.string" is being entered, BackSpace (or shift-BackSpace) "undoes" the effect of the last "nav.key", and ctrl-BackSpace undoes the whole "nav.string" (the highlight bar returns to its original place).

E) If double-quote is pressed while entering a "nav.string", the NEXT file matching the "nav.string" is selected and the user can continue to extend the "nav.string" and/or press double-quote again. If double-quote is hit as the first "nav.key", the last "nav.string" entered is recalled JUST AS IF the user had re-entered the keystrokes used to enter that string, and they can continue entering "nav.keys". (See below for the handling when the last thing entered was a "complex spell mode" string which does not fit as a "nav.string").

In a File/B/G/S window, a shift-TAB has a similar effect but the direction is reversed, with selection moving towards the top of the scroll-list rather than towards the end.

In an unsplit (F8) File/B/G/S window, TAB repeats the last entered nav.string but, unlike double-quote, does not put the user into the "navigation mode" and a subsequent nav.key starts with the first letter of the filename.

In addition, some other [TBD] keys, e.g., shift-HOME/END or ctrl-HOME/END may be defined to jump to the first or last file in the scroll-list which matches the "nav.string", and shift-/ctrl-PgUp/PgDn to have effects similar to those defined for shift-TAB and TAB -- Note however that these keys are available in the directory/tree view.

When ZTree first starts or when a new split window is created, the "last entered" "nav.string" is empty. In this case, it is suggested that these keys act as if the "nav.string" specified "tagged files" since that is probably the most useful default selection criteria...

F) The colon key is used to switch between entering further leading characters of the filename and leading characters of the extension (it toggles like INSert), For example, shift-P/shift-R/colon/shift-E will look for a file matching "PR*.E*". This usage of the colon key in the directory/tree window is still tentative (after all, directories don't really have "extensions") and a better usage may be found...

G) [TBD/NEW:] In a File/B/G/S window, the '*' key may be used (either [TBD} as a prefix on a per-attribute basis or as a "toggle" like colon) to indicate specification of file attributes (RASH) and/or tagging flags (this assumes that TAGged is treated as an attribute, an extension which has been separately proposed).

. .ALTERNATIVE: If the single-quote character is used as an "escape" (see item (A)), it might also be used here as a prefix for entering attributes/tags, possibly allowing shift-/non-shift-letters to indicate plus/minus (plus/minus should also be allowed...).

I am currently leaning toward the second method although I am not ecstatic about "giving up" the single-quote key (even though it can still be entered via the escape mechanism). However, this might allow the '*' key to actually be used (in File/B/G/S) to indicate a wildcard as part of the "nav.string". I would really like to see some opinions/preferences expressed here....!!!

H) There are really up to 4 last-entered-"nav.strings" buffers, one for the directory/tree window/view and one for the File/B/G/S window/view in each of the two sides of an F8-split. When split mode is entered, the buffers for the new window are cleared. [TBD:] Use shift-DELete to re-clear the buffers and reset/discard the last "nav.string".

I) The '|' (vertical bar) character is used as a hotkey to enter SpellMode, with the prompt field defaulting to either the last entered or the currently-being-entered "nav.string". The shared "history" of Navigation and SpellMode strings is available in the normal way and the SpellMode prompt provides the standard editting functions available to all ZTree prompts. As far as is possible, ZTree should attempt to provide immediate visual feedback (like TreeSpec and navigation) while the SpellMode prompt is active, but there will be situations (e.g., in the middle of an edit) where this is not possible. In addition:

. . 1) The "spell string" syntax and semenatics should be identical to that used for FileSpecs, and, in particular, a rightmost period is generally interpreted as introducing the extension (no special "toggle"). A "spell string" also allows the specification of additional selection criteria such as DateSpecs, wildcards, multiple wildcard strings, etc.

. . 2) Although the "spell string" history should be kept separately from the FileSpec history, some mechanism should be provided to allow access to the FileSpec history from the SpellMode prompt (and vice-versa). In addition, to avoid flushing.invalidating the SpellMode history, short "nav.strings" (less than say 5 characters) should not be entered into the history and it may be desirable to limit the number of such strings as well.

. . 3) A "spell string" may fall into the simpler syntax of a "nav.string" (but with characters like space, comma, period, and possibly wildcards allowed) or it may be considered to be a "complex spell string" (e.g., with multiple wildcard strings, exclusions, DateSpecs, etc.). When the SpellMode prompt is exited, a simple "spell string" is treated just as if it had been entered as a "nav.string" (even if it could not have been) and the double-quote, shift-TAB, colon, and '*' keys act as described above. If the "spell string" is a "complex" string, the effects of these keys must, of necessity, be modified: double-quote and shift-TAB act like TAB, repeating the selection in the appropriate direction, and colon and '*' start a new navigation.

. . . .NOTE: This issue is probably the "stickiest" one in the integration of the two proposals and any discussion or suggestions are certainly welcome.

. . 4) The primary functional keys, e.g., F4 (see below), PgUp/PgDn (or their shift-/ctrl- forms) are directly available from the SpellMode prompt

J) In a File/B/G/S view, the F4 (and/or shift-F4) key is used to "reduce" the scroll-list to just those files matching the last "nav./spell string" in much the same way as ctrl-F4 reduces the display to just the tagged files -- In essence, it uses the "nav./spell string" as a temporary FileSpec which is reset upon exit from that File/B/G/S view. While in this reduced view, the existing "nav.string" is treated as a prefix for any further "nav.string(s)" in a fashion akin to the way that the part above a Branch point is treated in a Branch view. It would also be nice if some method for "un-reducing" the display WITHOUT LOSING the position of the highlight bar is or could be made available...

>Old navigation and spell-mode thread

Messages in This Thread

| View Thread | Return to Index | Read Prev Msg | Read Next Msg |

XTree Forum archive is maintained by Mathias Winkler with WebBBS 3.21.

Xtree and XtreeGold are registered trademarks of Symantec Inc.
Other brands and products are trademarks of their respective holders.

FILE COMMANDS:  Directory_view Previous_file   Next_file cuRrent   /Help |Top_of_page