[Info-vax] VMS Features I Wish Linux Had

[Chris Scheers]

Johnny Billquist wrote:
> On 2016-06-15 20:26, Chris Scheers wrote:
>> Stephen Hoffman wrote:
>>> On 2016-06-15 11:57:06 +0000,   VAXman-  @SendSpamHere.ORG said:
>>>
>>>> THere IS line editing in the terminal driver but it's limited.
>>>> Extending that to 'vi' and 'emacs' capabilities is NOT appropriate in
>>>> the terminal driver.  Put it where it belongs!
>>>
>>> What most folks would want is some flexibility around editing command
>>> input, allowing vim or emacs or (since this is OpenVMS) EDT-compatible
>>> cursor control.
>>>
>>> http://www.catonmat.net/blog/bash-vi-editing-mode-cheat-sheet/
>>>
>>> The cursor handling is inherently going to be part of the driver (and
>>> also sensitive to the character encoding), whether the command history
>>> or recall buffer or the rest is part of the driver or is implemented
>>> elsewhere is an implementation detail.  If OpenVMS ever went onto Mach
>>> (past that prototype from many years ago), this handling could be in a
>>> process somewhere, for instance, and for all anybody using it cared.
>>>
>>> Akin to the lack of FUSE support within the OpenVMS I/O and file
>>> system implementation on OpenVMS, there's also no input character
>>> handling layer on OpenVMS.
>>
>> It sounds like what is being asked for is something like an ACP (class
>> driver?) for character I/O.
>>
>> Let the low level driver do driver stuff and move the bytes between the
>> hardware and the machine.
>>
>> Let the "ACP" layer handle editing and formatting and provide
>> consistency to all programs.
>>
>> Many "SET TERMINAL" settings would be handled in the "ACP".  You could
>> even add settings to specify "vi", "emacs", "VMS", etc. line editing.
>>
>> I think this is what Steve means by "input character handling layer",
>> but I would extend it beyond input to also include output formatting,
>> command history, etc.
> 
> Yes! That is a good concept. And in fact, this is what RSX has, and 
> there it is called an ACD - Ancilliary Control Driver. It hooks into the 
> terminal driver at certain points in the processing for both input and 
> output.
> 
> The interface is not as clean as an ACP, as this is not something that 
> can be handled at the QIO system call level, but is processing that 
> needs to happen for individual characters as they are entered, or 
> strings when they are output, which can happen for other reasons than a 
> QIO as well.
> 
>     Johnny

I would expect that, if such a facility was implemented on VMS, it would 
intercept at the $QIO level and be transparent to calling programs, 
i.e., it would look just like the existing terminal driver.

I would also expect that it would execute within the context of the 
process and not as a separate process.

Think of XQP as a model.

-- 
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360            Internet: chris at applied-synergy.com
   Fax: 817-237-3074