[Info-vax] VMS Features I Wish Linux Had
Johnny Billquist
bqt at softjar.se
Thu Jun 16 05:18:27 EDT 2016
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
More information about the Info-vax
mailing list