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

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Thu Aug 27 06:49:57 EDT 2015


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.


-- 
Pure Personal Opinion | HoffmanLabs LLC




More information about the Info-vax mailing list