[Info-vax] VMS Features I Wish Linux Had

[VAXman- at SendSpamHere.ORG]

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.

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?


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

I speak to machines with the voice of humanity.