[Info-vax] "Clever code", was: Re: wrong file format

[Jan-Erik Söderholm]

Den 2021-01-08 kl. 16:16, skrev Stephen Hoffman:
> On 2021-01-08 13:14:12 +0000, Simon Clubley said:
> 
>> Yes. The VMS terminal driver is an example of this idiotic mindset and is 
>> also the reason why, in 2021, we can't even do something as simple as 
>> edit DCL command lines which are longer than the terminal width. :-(
> 
> Pragmatically, the terminal driver class-and-port design has survived for 
> an unusually long time for software, and is still in active use.
> 
> Terminals and storage I/O are the two biggest class-and-port driver stacks, 
> and for similar reasons—trying to have logic common to all devices, without 
> having to maintain and update common code across multiple monolithic device 
> drivers; splitting device-generic from device-specific processing.
> 
> The design assumptions and trade-offs around the terminal driver and 
> LOGINOUT and JOB_CONTROL and CLI are all inter-related, too. Might command 
> editing be better implemented in the CLI? Quite possibly. Probably. Sure. 
> But there are requirements around responsiveness, and moving editing 
> further from the hardware usually adds latency. In years past, terminal 
> hardware was really slow. And some was even slower. So too was VAX slow. 
> And debugging a CLI gets... interesting, too.
> 
> For why this line-editing length limit still exists? Not clever nor idiotic 
> code. I'd tie that limit to a ~thirty year old class-and-port driver design 
> mixed with support for yet older hardware and sorta-kinda support for far 
> newer software terminals, with a very large dollop of 
> compatibility-preservation, along with fewer non-revenue-focused long-term 
> investments than any of us including the folks in OpenVMS development might 
> prefer. Forever-compatibility has its costs. And rip-and-replace is less 
> than popular with the apps and users dependent on the existing behavior. 
> (There was some other and non-technical "fun" arising here aeons ago, too.)
> 
> Past some threshold app size or app complexity, it's never simple. 
> Trade-offs all the way down, too.
> 
> I'm usually running terminal line widths ~200 characters, and usually using 
> scripts or cut-and-paste for longer commands and repeated commands. Yes, 
> this line-editing limit is annoying. Many other areas of OpenVMS are ripe 
> for updates, too. Feature-competitive operating systems are very large 
> projects. Very. Large.
> 
> Ponder the very long list of feature requests at VSI, and at the very 
> limited budget and staff available, and at what from that list can get 
> implemented, and what revenue that work might bring in. VSI hasn't surveyed 
> the paying folks and prolly won't, but I'd put the x86-64 port, the 2 TiB 
> and other file system limits, and better integrated database support, all 
> ahead of extended line editing, among other details.
> 
> 

This line editing "issue" commes up now and then. I can understand
stricly technicaly what is meant, but I do not really see the practical
limitation.

I just tested now and I can easily edit and re-issue a 250 char line.
When do you have any need to manually edit command lines of that lenght?

Agree, I really hope this is at the bottom end of VSI's priority list...