Paul Gilmartin wrote:
What about the minor change to make the existing behavior unsymmetrical? The editor should, prudently, set CAPS OFF when asked to edit a file containing lower case characters. As we note that's safe and easy to undo with UCC if wrong; but never override an existing setting of CAPS OFF to CAPS ON. I hope that can be justified by objective considerations and not as simply an accommodation to my personal preferences. Perhaps three settings: CAPS ON, CAPS OFF, and CAPS DATA. I'll even willingly admit that an initially empty file "contains no lower case characters" and can be treated as upper case under the CAPS DATA setting, but CAPS ON and CAPS OFF should never be overridden by the editor.
Or something like 'CAPS ON LOCK' and 'CAPS OFF LOCK' where the optional 'LOCK' keyword would indicate the setting cannot be automatically changed for this profile until another CAPS ON/OFF command without LOCK is issued. This has the added benefit of being upwards compatible with the existing behavior.
[snip]
Wandering much further into fantasy ... Nearly all features of modern workstations are under program control -- I know one screen saver which fully darkens the screen and merely twinkles the CAPS LOCK, NUM LOCK, and SCROLL LOCK to indicate its status. I assume it does this by toggling the associated states of the keyboard; restoring them when awakened. So, suppose an editor set CAPS LOCK on the terminal when appropriate. This would have the desirable effect of making the final state of the characters immediately visible as the programmer typed.
I agree it would be neat if there could be more interaction between software on the mainframe and hardware on the workstation. And, having characters accepted as typed is one of the major benefits of always using CAPS OFF in ISPF edit. (There are no surprises.) With CAPS OFF mode, your use of the <Shift> and <Caps Lock> keys strictly controls the case of the characters you enter. WYSIWYG.
And I've often wished the scope of CAPS LOCK were limited to the currently active window: as a bring each window to the fore it should assert its own setting of CAPS LOCK and turn the LED on or off appropriately.
I never thought of this before. But, I like your idea of a per-window <Caps Lock> facility on the PC. (This really has nothing to do with mainframes or 3270 emulators. I can easily envision a situation in which uppercase is being typed into a PC editor while mixed case is being typed into an email program. Switching between the two windows should switch the <Caps Lock> setting.)
-- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
