[Info-vax] VMS Features I Wish Linux Had

[Johnny Billquist]

On 2016-06-14 22:55, VAXman- at SendSpamHere.ORG wrote:
> In article <njphnc$sa6$2 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>> On 2016-06-14 12:47, VAXman- at SendSpamHere.ORG wrote:
>>> In article <njoior$lv7$4 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>>> On 2016-06-13 22:51, Bob Koehler wrote:
>>>>> In article <njmdvo$vo0$1 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>>>>> On 2016-06-13 14:59, Bob Koehler wrote:
>>>>>>> In article <njeel9$fq3$1 at dont-email.me>, "John E. Malmberg" <wb8tyw at qsl.net_work> writes:
>>>>>>>>
>>>>>>>> One issue with the VMS terminal line editing is because it is handled in
>>>>>>>> the driver, it does not have access to the filesystem to allow it to do
>>>>>>>> filename completion.
>>>>>>>
>>>>>>>    Which belongs in the CLI, not the terminal driver.  The CLI should be
>>>>>>>    doing it's own command line editing,instead of leaning on the limited
>>>>>>>    editing in the driver.
>>>>>>
>>>>>> I don't agree. I want command line editing, no matter if I'm at the CLI,
>>>>>> or in some user application. And I do not consider it to be a good
>>>>>> system design that every program should include their own version of
>>>>>> commmand line editing.
>>>>>
>>>>>    Putting editing into the CLI does not mean it has to be removed from
>>>>>    the terminal driver.  But the terminal driver is a limited context
>>>>>    and should only be used for limited purposes.
>>>>
>>>> True. One does not exclude the other. But I fail to see the benefit of
>>>> having both.
>>>>
>>>>>    I've got UNIX shells that will let me make use of most of the power
>>>>>    of vi (oxymoron), or emacs.  I see no reason why all that should be
>>>>>    in a driver.  But I also don't want a driver that provides only the
>>>>>    functions of a card punch.
>>>>
>>>> I want that vi or emacs capability always, no matter what program or
>>>> context I am in, and not just at the CLI or shell. Which is the reason I
>>>> think it belongs in the driver. This functionality, in my mind, is not
>>>> tied to a specific application or environment. It's a functionality that
>>>> I want basically all the time, everywhere. Based on that, it's not hard
>>>> to see where it should go.
>>>
>>> So, vi and or emacs aren't that special; it's the unix terminal driver that's
>>> to be given all the credits.  ...wait for it... ...wait for it...  Hopefully,
>>> the light comes on.
>>
>> I'm getting the feeling that either you do not understand anything at
>> all, or you are trying to be funny and totally failing.
>
> It is you that are not being serious.  You'd said you wanted 'vi' or 'emacs'
> capability always.  I'll wager a good bet that those features are NOT part of
> the basic input of unix/linux.  Why do you believe that the terminal driver
> should have recall, search, find-and-replace, insert, delete, etc. which are
> functions in 'vi', 'emacs' and most every editor; yet, most of those functions
> are not implemented by/in the terminal driver.

Ok. So you did not understand.
The "vi" or "emacs" in line editing is not the full editor, and have 
never been. It is still line editing. But yes, things like recalling and 
editing previous lines, as well as the current line are things that I 
like to have.

And you are right, Unix/Linux do not have that, which is one of the 
things I am complaining about. The solution of having to include it in 
every program is horrible. Not only does it mean that it might be 
working differently in every program, but it also means that one program 
might not have it at all. So it's all very inconsistent, and ugly.

I think the terminal driver *is* the right place for this. But no, I am 
not calling for a full blown screen editor, and never have been.

> If you want elaborate input editing, don't use the basic terminal driver I/O;
> use other I/O routines -- for example, SMG.  If it was ALL up to the terminal
> driver and it buffered a pool of your input, how can you know if the recalled
> input is applicable to your command line or your current application or some
> previously executed application?  Oh, let me see, the terminal driver should
> expunge any data from the previous application at application rundown?  OK, I
> can see that.  Then, the terminal driver would need to maintain mode state of
> the input so that a new application can not touch the command line(s), or do
> you like to open up potential security holes in the name of simplicity simply
> because you don't want to take the time to program your application's input?

What data a user enters is the users choice. If he get that from 
recalling a previous line and entering it, or types it all in by hand 
makes no difference.

I suspect you still think that the terminal driver should handle things 
like rubout and ^U/^X. Why do you think those should be in there, but 
not the ability to delete anything else than the last character entered?

	Johnny