File: XTree:\Forum archive |Bottom_of_page

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

XTree Forum archive

Re: Shift-Letter / Spell Mode Comparison - Added FEATURES

Posted By: Walter Rassbach <>
Date: Friday, 11 September 1998, at 9:35 a.m.

In Response To: Re: Shift-Letter / Spell Mode Comparison (John Gruener)

First, let me again emphasize that what John has done is wonderful and I think the dialectic is bound to result in a better synthesis feature in the end...

This part of the response (the second), is intended just to cover the added sub-functions that John supplied or give reasons why I think those sub-functions are not critical (of course, this will be one of the primary areas of disagreement and a factor in the final selection)...

A note on notation: I think that the terms I was using previously, i.e., "initial state" and "(navigation) extension" or "non-initial state" are causing a lot of confusion... I would like to change them to:

"navigation start" or "nav.start" (rather than "initial state")
"navigation continuation" or "nav.cont" (rather than "non-initial") when entry of a "nav.key" will affect/extend the MAIN part of the navigation string
"navigation extension" or "nav.ext" (rather than "non-initial/extension") when entering a "nav.key" will affect the file extension part of the nav.string

Lines from John's comparison posting are marked with the standard leading '>', but I have deleted as much as I can JUST to keep the size of these messages down to something readable and useful.
>...> add functions to his, and I invite him to do so, so that in the
> end we can compare each on equal grounds.

That's what this posting is meant to address...

> A note on the usage of the "|" key to enter the Spell
> mode: I picked it because it's available in all windows; it's intuitive
> in the sense that the unshifted "\" key starts the Spell
> mode for the logical path; and, in my view, its an important enough
> function to dedicate an unused key. I'd be open to a different key
> if it made more sense.

Actually, the '|' key currently starts TreeSpec just like '\', but assigning it a new function is not much different that the changes I have suggested for some of the other keys... My only concern is that it would be the only function key (in the sense of a "command") which requires a shift.

> -WR-> Spell with Shift-Letters, Numbers and all legal special
> characters except Period, Comma and Space, (and Plus and Minus unless
> configuration option is set).
> -JG-> Spell with any legal characters, including Unshifted
> letters, Period, Comma, Plus, Minus and Space without needing an
> option to disable the main Plus and Minus keys or to add Ins/Del
> key functions.

The full list is really period, comma, space and maybe plus, minus, AND EQUALS (which currently has the same effect as a '+', and I think has to be left as that if '+' is enabled since I would bet that most people actually use '=' for the "log directory" function, i.e., they don't use it with SHIFT pressed...)

However, it should be noted that plus, minus, and equal ARE AVAILABLE in a File/B/G/S window without any need for a configuration option since they currently have no effect on such windows -- they are only command keys in a directory/tree window (and in a "point to window"?) or if the /XT command line option is active (and I think that one should probably disable either of the proposed enhancements!...).

> -WR-> Use Double Quotes to recall the last spelled name from the Initial
> State or the Spell mode.
> -JG-> Use an Up/Down key to recall a history list of the last spelled names,
> or the F3 key to recall the most recent spelled name, from the
> Spell mode only.

Adding something like this depends on whether Kim can detect something like a shift-Up or shift-Down (in particular, a grey key Up/Down). If he can, that is the obvious choice... Otherwise, I could see using something like ctrl-PgUp/PgDn (from either a nav.start or nav.cont/ext state), or some similar key choice, to bring up a nav.string history...

In fact, if we are willing to re-assign the '|' key anyway (as John proposes), it is an obvious candidate to bring up a history (there is no start at top/bottom of list choice that the up/down arrows are supposed to give, but that feature doesn't currently work anyway...)

However, I am not yet convinced that a history is useful here... The whole idea (I think) is that navigation/spell strings are SHORT, and going through a history is actually more keystrokes than repeating entry would be... If people DO really want a history, I am sure that a reasonable way to get to it can be found.

> -WR-> Use Double Quotes in all windows to navigate to the
> next name meeting the spelling and enter/remain in the Spell mode.
> Also use the Tab/Shift-Tab, in the File windows only, (except the
> F8-Split mode), to navigate to the next/previous name meeting the
> spelling, but exit to the Initial state.
> -JG-> Use the PageUp/PageDown keys in all windows, (including
> the F8-Split mode), to navigate to the next/previous name meeting
> the spelling and remain in the Spell mode.

[notation change: "exit to the Initial state" -> "reset to nav.start state"]

Actually, I think I suggested that shift-TAB be assigned the "previous name" function in a File/B/G/S window even in F8-split mode, rather than having it do exactly the same thing as TAB (which is what it does now...)

It would not be hard to convince me that shift-TAB should act like more like double quote and not cause a reset to "nav.start" ["initial state"] -- In fact, I think I would prefer it...

> -WR-> Use the F4 key to reduce the display to those matching
> the spelling, (questionable, since this is another "command"
> key).
> -JG-> Use the F4 key to reduce the display to those matching
> the spelling, (not questionable, since we're in a dedicated Spell
> mode).

Does this mean one has to hit '|' and then F4 to do this function?
I will comment further on this area in the "content" reply I will write soon.

Also, I'm not sure that re-assigning/re-using the F4 key is really "questionable" since it was put in to XTree as an access feature to allow for purely ONE FINGER usage -- Using the '|' key for spell mode also violates this, and Windows ALREADY PROVIDES THIS ACCESS FEATURE IN A UNIFORM MANNER TO ALL WINDOWS -- Anyone who requires it is almost certainly going to be using the Windows access features and will also never use F4 anyway...

> -WR-> No method to get immediately to the first/last name
> meeting the spelling.
> -JG-> Use the Ctrl-Home/Ctrl-End keys to get immediately
> to the first/last name meeting the spelling in the current sort
> order.

There is no reason that these same keys could not be added to my proposal, although we will need to decide whether they act like TAB or like a double quote. Also, for John's proposal, I would suggest that these keys should work even if one is not in "spell mode"...

> -WR-> Has no "text entry" field.
> -JG-> Has "text entry" field, (just like the "\"
> function in the directory window), but with edit capabilities.

I would, in fact, like to see a "text entry" (and a continuous display) of the File/B/G/S navigation string (for my proposal there is only one), much like the current "File Mask" is displayed. In anything other than 25-line mode there is room on the right side of the screen, but I would like to suggest that it actually be added to the end of the "Path" string at the top of the screen, in the "character emphasis" color (the same color used to emphasize the actual command characters in the HotKey menu at the bottom of the screen, which is yellow in the default color scheme), with a highlight bar (black on grey in the default color scheme) used to indicate "nav.cont"/"nav.ext" ["non-initial"] state and which part (main or extension). In more detail:

1) If there is no navigation string (never entered or a newly split window), nothing is displayed for it (of course), and there is no emphasis color backslash at the end of the path string...

2) When we are in a "nav.start" ["initial"] state WITH a nav.string previously entered, the navigation string is displayed in "emphasis color {yellow}" at the end of the path line. It is appended to the end of the path string with an emphasis-color (yellow) backslash. I'm not sure whether a nav.string of "CL.E" should be displayed just like that or as "CL*.E*" as it would be in a FileMask. If there is no extension part specified, I would prefer "CL*" rather than "CL*.*"... NOTE: If the path name is LONG, this may lead to a small extra loss of displayed information since a few more characters will be elided from the displayed path name (more critical in split screen).

3) In a "nav.cont" state, the main part of the navigation string changes to the highlight bar (black-on-grey) color and any extension part stays yellow, as does the backslash that separates the path string and the nav.string. There may or may not (we need to decide) be a blinking underline cursor displayed -- If the string is displayed without any '*', the cursor (if displayed) should be on the extension period character (which should still be yellow). If the string is displayed with a '*', and no cursor is displayed, it is not clear whether it (the '*') should also be black-on-grey or yellow (I prefer the former I think). If a cursor IS displayed, it should be on the '*' which could be either black-on-grey or yellow...

4) In a "nav.ext" state (entered when a "colon" is pressed), a period is always displayed (even if we normally display just "CL" or "CL*") and the extension part of the string is highlighted (black-on-grey) with the main part of the name in yellow...

We may need to fiddle with this a bit (I'm SURE Kim will have something to say here), but I think this is fairly close...

> -WR-> No ability to edit the entered spelling.
> -JG-> Ability to use Left/Right, Ctrl-Left/Ctrl-Right, Home/End,
> Backspace/Delete, and Insert keys to edit the spelling.

I am again not convinced of the utility of this since I expect navigation strings to normally be short... If a history is provided (e.g., via "my" usage of a '|'), we could specify that a TAB on a history entry puts one in edit mode with that value as a starting point...

There is, however, the problem of a typo... I could see having a shift backspace remove the last nav.key in the obvious way (if Kim can detect it... However, I think that the API does not separate a shift-backspace from an unshifted one, so maybe a straight backspace [generally with the shift key down], if/only-if we are in a nav.cont/ext state -- this gives up the usage of backspace as a NOP reset to the nav.start state but I think that the ALT/CTRL method is probably more useful anyway...). In other words, a backspace acts like a one character undo while a ctrl-backspace acts like a complete undo of the navigation -- Note that either of these means that Kim will probably have to implement navigation with an "anchored starting point" (i.e., where the highlight bar was when the first nav.key was pressed), but I would bet that is probably the best way to go anyway...

There are a couple of other minor refinements I have thought of (largely triggered by the fact that John took the time to build a good alternative proposal for me to bounce thoughts off of...), but most of them can be added to either proposal and should be left until we resolve the main question...

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