[Info-vax] iTerm2 question (Re: OpenVMS graphics - once more)

[David Froble]

Stephen Hoffman wrote:
> On 2015-08-27 02:17:14 +0000, David Froble said:
> 
>> Stephen Hoffman wrote:
>>> On 2015-08-26 12:33:54 +0000, Craig A. Berry said:
>>>
>>>> At least with 10.10.5 I see no way to make F10, for example, do 
>>>> anything except adjust the volume or pop you into Exposé.
>>>
>>> Presumably with both the "Use all F1, F2, etc. keys as standard 
>>> function keys" checked and the associated Keyboard Shortcuts settings 
>>> also disabled?
>>>
>>> To create or modify an application to avoid these changes — requiring 
>>> manual changes to system-wide settings around a Terminal.app or 
>>> iTerm2.app session — a Docker search for Shortcut in the OS X 
>>> material returns a small mountain of hits; finding out if there's a 
>>> way for an app to override the system-wide settings will involve some 
>>> digging.  Though digging around here 
>>> <http://krypted.com/mac-os-x/defaults-symbolichotkeys/> initially 
>>> does seem promising, I don't immediately see an application-specific 
>>> function key override available.
>>>
>>> Dependencies on the editing and function keypads are only going to 
>>> get more problematic for serial-line-based applications, too.  As 
>>> I've mentioned elsewhere, these LK-only applications are only going 
>>> to get more ugly over time, as the keyboards wear out.  Things are 
>>> still ugly even if some hypothetical new replacement dual-use 
>>> LK450-like keyboards become available, as those will be both rare and 
>>> expensive add-ons.   Ignoring that many laptops and tablets just 
>>> don't have these keypads, too.
>>>
>>> In short, learn vim, emacs, nano or some other preferably-ubiquitous 
>>> and not-keypad-based text editor, configure your IDE to use your 
>>> preferred-editor key sequences, use the command mode in the various 
>>> OpenVMS tools that have that feature, and get working on updating or 
>>> replacing the rest of the old keypad-based OpenVMS apps you're using.
>>>
>>>
>>
>> Why go to all that effort?  Just get a decent terminal emulator.
> 
> Which effort?  The system-wide shortcuts apply everywhere on OS X, and 
> must be disabled to allow the terminal emulator access.   I've not 
> encountered an emulator that switches off the system-wide shortcuts, 
> either.   Or the effort of switching away from applications that use 
> keypads?  Because LK-compatible keyboards are no longer available, 
> function keypads are no longer ubiquitous, and because function keypads 
> as a serial UI are basically dead.
> 
> For all of the function key stuff, I really haven't had that requirement 
> with OpenVMS, and I'm using Terminal.app — the integrated emulator and 
> shell environment on OS X.  I might have wanted function keys and 
> related, as the command modes in more than a few OpenVMS packages are 
> craptacular, but the command lines are workable for all of the HPE 
> OpenVMS tools I deal with.  For end-user applications, that's the usual 
> "fix it long-term or hack around it short-term" discussion and 
> trade-offs.   If you haven't already been using some other editor 
> elsewhere — the OpenVMS text editors being far from ubiquitous — then 
> learning a new and more portable and ubiquitous text editor is useful, 
> but it's never fun.
> 
> Though the downside of using different text editors (for OpenVMS 
> development) is stupidity like the compiler ANA file format still being 
> undocumented.  (Which also means this runs afoul of the VSI EULA, but I 
> digress.)   Unfortunately, neither HPE nor VSI has an OpenVMS-targeted 
> IDE available, by present-day standards.  Why IDE?  Because development 
> and debugging are my most common activities,  when I'm at the OpenVMS 
> command line.  Other folks have other uses for terminal sessions, not 
> the least of which are existing serial-line user-interface applications.
> 
> Folks have been griping about emulation for eons, whether we're 
> discussing server or platform or serial terminal or some other form of 
> emulation.   Moving away from the tools and processes and applications 
> that require and depend on emulation is an investment in my own future, 
> and the future of the applications I deal with — the investment makes 
> the tools easier to use, easier to explain, easier to support and 
> maintain and update, and usually also lowers the long-term end-user 
> support costs.  Whether that initial investment makes sense?  That varies.
> 
> 

I guess part of the problem is using a "real" (in your opinion) OS instead of 
just a user interface to run an emulator ...

:-)

Since I use weendoze, which doesn't use the function keys for other purposes, to 
run a terminal emulator, I don't seem to have as many problems.  I miss F12 (I 
believe) for toggling between insert and overstrike mode, but not much else. 
Ctl-A also works, so it's not a problem.