This N That

[Robert Holmgren]

 Dear SysOp:

 Where do we find MINI.MNU for Xy4?

 Do we really need MINI.MNU, if we're not running much of anything out of the
factory-issue Help system?

 How do I get Ctrl-PgDn to work in the Microlytics thesaurus? I've tried
accessing it every which way, via func SY, via DLG frame, whatever. Doesn't
seem to want to work. BTW, thanks for restoring Thesaurus function in XP mode.
Has that been changed with the Sig-style Thesaurus too? Used to work in $DT>0
only...

 How do I toggle the Sig-style Thesaurus into action? Suppose I want to
consult them both...

 Suggestion: I'd like to be able to use Graphic View in expanded mode, i.e.
see all the guillemets & formatting but view them using graphics chars. There
are excellent reasons. First, I like to work in high-speed XP mode (that's top
priority, and my default) -- WYSIHowYouGetWYG aka `Wissihigwig'. Second, I
want to use and print with the expanded char set (very wide and heavy use
thereof); I want to see the actual result chars, not the monstrous "[###]"
strings. At present, because XP is more important to me, I'm reliant on custom
code pages and custom fonts that redefine 128-254. But the resizable Speedo
fonts are attractive, and I'd like to migrate. I should think it would be easy
to implement "XP Graphics"...

 Can you tell me the purpose of the U1, U3, and U4 Help files? At present they
seem not be in use.

 I seem to be losing the OO state (VA$OO) very frequently -- it virtually flops
from OO=1 to OO=0 all by itself. Very hard to handle. Suppose you dedicate
one global S/G to control the state of OO|OX. Then, you run a routine A that
(assuming OO=1 before entry) toggles OO=0 on entry, and then restores OO=1 on
EXit. Within routine A, you shell to child process routine B, which utilizes
the same S/G to toggle the OO|OX state. Goodbye VA$OO! You'd have to make
sure you used different S/G numbers in *EVERY* routine that might potentially
be run as a parent or child process! One hundred possible
parent+child+child+... permutations=one hundred different routine numbers
permanently set aside. Alternatively, suppose you dedicated a frame to control
OO|OX and nothing else -- how would you ever know whether  in another frame
meant you were dropping out of a nested situation, or dropping out of Help
altogether and therefore should call that dedicated OO|OX frame as your
goodbye? How does XyQuest envision that this be handled? It's a mess.

 If there a VA that retains the last string displayed as a PRoMPT? (Not the
last canned error msg ? la VN$ER, but the last string, whatever it may have
been.)

 If you ChangeCase (UC|LC|etc), then issue func|command SAve, EDITOR does not
recognize that the file has been changed; it responds "Proceed" rather than
"Done", and case changes are *not* saved

 VA// is disabled (though VA/NV still works): bummer. It was ergonomic to hit
"/" twice and Done.

 Suggestion: It would be nice if, when using the SEarch command to find a
string in a fileset (SE FILESET|STRING|), a command to pen the file placed
the cursor on the found $ instead of at TOF. If we really _want_ to go TF,
it's an easy maneuver; but finding that string again is trouble, particularly
when it's the fifteenth iteration of the string in the file (you already hit
ontinue fifteen times, now you gotta do it again!). Second, if you Open one
file in the set, why does the SEarch command shut down? Often there's more
than one file that contains the target string. I have on disk many different
versions of similar texts; I may want to compare them, find the most
appropriate or newest one, etc. To restart the SEarch, you gotta go back to
the top of the bloody list, and plough through all the same files again, to
find file #2. Then again for file #3. Whew. (Thank god for OS utils like
GREP!)

 Where are the text strings located that are accessed when VA_ reports, e.g.
the "Ctrl+Alt+Shift+F4" stuff? I assume that they can be made smarter, to
distinguish RightShift from LeftShift, etc?

 Well, the weather's balmy down here; how about up there? Is there a fug-bi a
bug-fixed EDITOR.EXE in the works? Ciao