[Info-vax] VMS Features I Wish Linux Had

[VAXman- at SendSpamHere.ORG]

In article <njtqt3$r4l$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>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.

$ MCR TFU HELP ABOUT_TFF

                   Terminal Fallback Facility (TFF)

    The  VMS  Terminal  Fallback  Facility  (TFF)  provides table-driven
    character   conversion   for   terminals.  The  conversion  is  done
    transparent   to  the  application  (unnoticed  by  the  application
    software  unless  explicit  inquiries  are  made).  You  can  choose
    character conversion tables from a master character library, located
    on the VMS system disk in:

    SYS$SYSTEM:TFF$MASTER.DAT

    This  library  contains  all  the character tables supported by TFF.
    Conversions  can  be  one character to many on output to a terminal,
    and one to one on input from a terminal.

    TFF   can   also  perform  character  compose  emulation  on  input.
    Furthermore, you can control which keys are auto-compose keys.

    One  of  the  applications  of  TFF  is to allow users with National
    Replacement  Character (NRC) set terminals to use software developed
    with   the   Digital  Multinational  Character  Set  (MCS).  MCS  is
    essentially  the  ASCII  character set plus 128 characters currently
    used by owners of NRC terminals around the world.

    In addition,  TFF  also  allows  users  to  use 16-bit character set
    terminals,  such as  DOOSAN  Code  and  Telex  Code  Asian  language
    terminals, for software developed  with  the Asian Language National
    Standard Character Set.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.