[Info-vax] VMS Features I Wish Linux Had

[Johnny Billquist]

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