[Info-vax] VMS Features I Wish Linux Had

[Johnny Billquist]

On 2016-06-15 12:17, johnwallace4 at yahoo.co.uk wrote:
> On Wednesday, 15 June 2016 10:34:33 UTC+1, Johnny Billquist  wrote:
>> On 2016-06-14 21:23, Simon Clubley wrote:
>>> On 2016-06-14, Johnny Billquist <bqt at softjar.se> wrote:
>>>> On 2016-06-14 15:44, Bob Koehler wrote:
>>>>> In article <njoior$lv7$4 at Iltempo.Update.UU.SE>, Johnny Billquist <bqt at softjar.se> writes:
>>>>>>
>>>>>> 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.
>>>>>
>>>>>    In the driver basically means at elevated IPL.  I don't want someone
>>>>>    running emacs at elevated IPL on my systems.  That's why we need both
>>>>>    the in-the-driver limited capabilities and the in-the-program
>>>>>    capabilities.  And DCL should take more adantage of the latter.
>>>>
>>>> Noone have suggested running Emacs in the driver. Jeez...
>>>>
>>>
>>> The best solution appears to be to keep the editing of the current line
>>> in the terminal driver (which would allow repainting of the line if
>>> there's any output while the user is typing) and to keep management of
>>> the command history within the application itself.
>>
>> Well, you could argue that the application should be responsible for the
>> repainting as well...
>>
>>> I wouldn't want to see large chunks of command history kept in non-paged
>>> memory in the kernel; I don't think that's where it belongs. OTOH having
>>> an OS which implements basic line editing services means you don't have
>>> to implement that in every application.
>>
>> Well, the saved history needs to go somewhere. Exactly where is a
>> technical question. But you are repeating my point about having the
>> (hopefully) same code replicated in each program being a bad design.
>>
>>> Of course, that argument would be more convincing if the terminal driver
>>> of the OS in question allowed editing of lines which wrapped multiple
>>> physical lines. :-)
>>
>> Agreed. But that is once more a technical issue. It does not change the
>> question of wether it should be there or not. But I agree that it should
>> be done better.
>>
>> 	Johnny
>
> continuing the rathole...
>
> Why does non-privileged hardware-independent commonly required
> stuff that's not in the driver need to be replicated individually
> in every program? Isn't that what libraries are for, be they
> vendor provided or whatever?

Well, this then boils down to which library, and which version of that 
library are you linking to, and is that a shared library, or is it 
linked into every program that use it? In an ideal world, all programs 
would then be linking to the same library, at the same version (I would 
assume), and this library would be shared, so that only one copy 
existed, and so on.

But ideal worlds so seldom show up in real life...

> Where the saved history lives is an interesting question. You
> presumably wouldn't want application B to be able to (by default)
> see data entered to application A?

I can see that some people would prefer that. Personally, I do not feel 
strongly about it, and am perfectly happy with input used in one program 
show up in another if you recall old input. It might sometimes be 
useful, and otherwise I can just move on to the next input.

	Johnny