On Wed, 16 Apr 2014 12:48:13 +0200 Bram Moolenaar <[email protected]> wrote:
> This is a different settings with very different potential problems. > That the other modes work gives no indication that 8-bit mode will > work. That's fine; we're not /relying/ on 8-bit mode to work. If we don't receive an 8-bit-clean CSI reply, we'll still accept the 7-bit ESC-prefixed encodings anyway, and things will continue to work exactly as they do now. But if we did receive it, then we can do the user a favour and remove the timing-ambiguity of ESC-prefixing. > Think of this: why do terminal emulators start in 7-bit mode anyway? > If 8-bit mode is so great, why don't they start in 8-bit mode? Because most programs are still doing keyboard sequence parsing simply by trying to match the fixed database of strings that termcap/terminfo gives, and those strings almost invariably are the ESC-prefixed 7-bit versions. If terminals defaulted to start in 8-bit mode then bash/readline would not recognise these keys any more. So it starts off. For the same reason that the number keypad starts in keypad-cursor mode, and mouse tracking starts off disabled. readline and other programs just don't recognise them. But vim /does/ recognise those - vim can cope just fine with receving keypad-application sequences, and mouse reporting events, so it enables those things. Vim could just as easily cope with receiving 8-bit CSI/SS3s. > In the mean time the user may have typed something, screen has > refreshed, other codes may be received. All this is asynchronous, > there are many ways in which it can fail. Vim may even exit before > 8-bit mode is really working. And that's all fine. We'll still correctly interpret most keypresses that received. We're not relying on definitely receiving it. If we /happen/ to receive it, then we can help the user by removing the timing wait on ESC-prefix. There likely will be a short delay on startup, while that round-trip happens. During that time it is exceedingly unlikely the user wanted to press <Escape>, because vim starts up in normal mode anyway. They'd have to have entered insert mode, typed something, then left it again for this even to matter. > > If for some reason the terminal doesn't understand S8C1T then it > > doesn't matter. You'll simply never receive that 8-bit response, so > > you'll never trigger the logic in step 3 to disable the > > Escape-prefixed versions of CSI and SS3. > > It may also happen that the terminal works, but the communication > channel has a problem with 8 bits (using parity bit, from the old > days?). I suppose it's possible they are using a vim from 2014 and a terminal from 2014, over a serial connection from 1970. In that case, UTF-8 and a whole bunch of other things will also break. In the exceedingly-unlikely case that their serial line can't transport 8-bit sequences, they could disable this feature. As they'd almost certainly know about it because many other modern things like UTF-8 won't work either. > > If you're going to claim that switching on S8C1T is dangerous and > > the user's problem, then I'm going to claim so is setting alternate > > buffer, keypad-application and mouse tracking, and that vim should > > stop doing those as well and leave them up to the user to set. > > All these are dangerous, but the ones that are being used have been > tested, debugged and problems have been fixed. Adding a new one means > it will take some time before it works reliable (or we would have to > revert the change if there are problems that can't be fixed). OK, then lets make it non-default. For people who want to be able to type Escape reliably they can :set use8bit in their .vimrc; for anyone else they won't notice a difference. Also this neatly solves the problem of "what if my 1970s-era serial line can't transport 8-bit data?". > Why don't you ask the maintainers of terminal emulaters to use 8-bit > mode by default? We can't, as you well know. Seriously Bram; you and I are probably the two people on the planet most aware of the fact that if terminals were to suddenly start sending 8-bit versions of CSI and SS3 for keypresses, then vim would not work. It doesn't understand them by default. Additionally, neither would bash/readline, irssi, mutt,... practically any terminal-based program, that wasn't specifically designed to cope with it (i.e. by doing actual parsing and not just dumb terminfo-string-prefix-eating). DEC in their wisdom /knew/ this change would break older programs that didn't understand it, that's why it was an optional non-default on the VT2xx series, where applications can enable it if they know they can cope. That was released in 1983; I think in the intervening 31 years we have just about progressed the state of art in terminal applications to the point they can cope with it now. Don't you? -- Paul "LeoNerd" Evans [email protected] http://www.leonerd.org.uk/ | https://metacpan.org/author/PEVANS -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
