Re: wsvt25 backspace key should match terminfo definition
On Thu 25 Nov 2021 at 08:01:48 -0500, Mouse wrote: > One of my very-spare-time projects is to move input line editing out of > the kernel. Move it into a separate line-editor process and then you > can choose your input line editor just as you can, today, choose your > shell. I'm still mulling over the design issues involved, though, On the Amiga there was CONMAN: which could replace CON: as a console window, and it had nice extras like line editing. It also kept track of the user process' current directory so it could also do file name completion. On the V7 I used initially, a local patch had added more-like paging to the kernel's terminal driver. Quite useful on ADM-3a terminals without scrollback... I never got around to add this to NetBSD, unfortunately. But it's a lot less needed in an xterm. -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: wsvt25 backspace key should match terminfo definition
>> Or, maybe have `erase=3D^?' and also a new `erase2=3D^H' [...] > That's an interesting idea... historically (and I mean decades) I > have setteled on choosing one (^H) and forcing all systems I used > over the years to use this one setting, but this might be more > convenient... One of my very-spare-time projects is to move input line editing out of the kernel. Move it into a separate line-editor process and then you can choose your input line editor just as you can, today, choose your shell. I'm still mulling over the design issues involved, though, since a lot of the line-editing programs want to do program-specific stuff like completion (of filenames, of command names, of internal keywords, whatever). Of course, there's xkcd-927 risk With a bit of care, it should even be possible to make it usable by programs that currently have to do their own input line editing (such as a curses IRC/ICB client); it's always bothered me that input line editing is sometimes done by the kernel and sometimes done by userland, and, except when the same person did both (and sometimes even then), they never seem to quite match up. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: wsvt25 backspace key should match terminfo definition
> key_backspacekbs kbsent by backspace key > key_dc kdch1 kDsent by delete-character > key Part of the confusion here is that this is not well-defined. Some keyboards have multiple keys which could reasonably be called a "delete-character key", and they often do not send the same thing. Similarly, is the BTW, since this is tech-kern, note that the wscons(4) manual page > tells a little white lie when it suggests that when in "vt100" mode > it "will work sufficiently as a VT220 emulator." It will, for most purposes. Most software does not use more than a few basic capabilities such as cursor positioning. Indeed, on most machines, wscons fails as a VT-100 - or VT-220 - emulator on one of the most basic counts: the size in lines, and not uncommonly columns, is wrong. Whether fortunately or unfortunately (I could argue either way), most software lets the tty size settings override the actual size of the terminal (supposedly) being emulated, even when that terminal was/is capable of only one size (or, as for the VT-100, a very few sizes). That's why mterm in "X3.64 + DEC extensions" mode sets $TERM to "decansi" rather than "vt100", even though in 80x24 size it's a better VT-100 emulator than many. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: wsvt25 backspace key should match terminfo definition
At Tue, 23 Nov 2021 18:31:38 -0500, Greg Troxel wrote: Subject: Re: wsvt25 backspace key should match terminfo definition > > Johnny Billquist writes: > > >> For vt320 (where it *is* configurable) terminfo has > >> > >>$ infocmp -1 vt320 | grep kbs > >>kbs=^?, > > > > Which I think it should be. > > > But what does kbs mean? > > - the ASCII character sent by the computer to move the cursor left? > - the ASCII character sent by the BS key? > - the ASCII character sent by the DEL key that the uses uss to delete left? The answer to your question is actually clearly documented in the terminfo(5) manual page: key_backspacekbs kbsent by backspace key (note I fixed the typo (s/set/sent/) in my /usr/src/lib/libterminfo/term.h) I.e. if you have a terminal keyboard that has a key with the "Backspace" label, and another key with the "Delete" label, (or their "moral" equivalents, label-wise) then the terminfo entry's "kbs" value should give the character sequence sent when the user presses the "Backspace" key, and it should also have a value for "kdch1" giving the sequence sent when the user presses the "Delete" key: key_dc kdch1 kDsent by delete-character key For a configurable terminal (e.g. a real VT220 in vt100 mode) there should be a separate terminfo entry for the terminal in that different mode. In NetBSD's terminfo file this is currently "vt220d" (or "vt220-old", if that applies better to the actual terminal and/or keyboard in use). Note also, just to be more pedantic, the "k" prefix on terminfo(5) "Code" names (and the corresponding "key_" prefix on the "Long name" names) is the clue that the value for these codes is to represent the sequence sent by the terminal. This has been true since the 1980s when terminfo first came along. Also, BTW, the tradition for which key was the interrupt key (i.e. the one eventually modifiable using "stty intr") (and which key was "stty erase") changed depending on where/when you were. Some say it had an "East Coast / West Coast" division -- Bell Labs vs. UCB. I began in the early 1980s with the Bell Labs tradition (and terminals to match) that "stty intr" was set to ASCII DEL. Indeed that's all I could do since I started with Unix V7. As I understood it at the time this matched the Teletype "rubout" key that was used as the interrupt key (though I never used a real Teletype back then) [from tty(4) in the Unix 7th edition manual]: During input, erase and kill processing is normally done. By default, the character ‘#’ erases the last character typed [[ ]] DEL (Rubout) is not passed to a program but generates an interrupt signal which is sent to all processes with the associated control terminal. Normally each such process is forced to terminate, but arrangements may be made either to ignore the signal or to receive a trap to an agreed-upon location. See signal(2). Original V7 stty(1) didn't even let one change the "interrupt" key (though I believe V7's tty(4) TIOCSETP command would allow it to be changed). Of course back then the tty line discipline didn't do live erase or kill processing, and so the erase character was often left as "#" to avoid confusion (and "stty kill" was '@' -- modern email was a long way off!). The tradition of "stty intr" being ASCII DEL (by default) carried on into the AT releases as well, just as one would expect. However even right up to Unix System V Release 4.2 (about 1992) they hung on to '#' being the default erase character [this from SysVr4.2's termio(7)]: INTR (Rubout or ASCII DEL) generates a SIGINT signal. SIGINT is sent to all frequent processes associated with the control‐ ling terminal. Normally, each such process is forced to ter‐ minate, but arrangements may be made either to ignore the signal or to receive a trap to an agreed upon location. [See signal(5)]. ERASE (#) erases the preceding character. It does not erase beyond the start of a line, as delimited by a NL, EOF, EOL, or EOL2 character. Leaving "stty erase" as '#' changed quickly once one upgraded to a new enough system to have "ECHOE" (and "ECHOK") processing, including for BSD with the "new crt" line discipline, where live erase and kill processing could be enabled. Then one would set the erase character to what was mo
Re: wsvt25 backspace key should match terminfo definition
On Thu 25 Nov 2021 at 00:16:36 +, RVP wrote: > Or, maybe have `erase=^?' and also a new `erase2=^H' like FreeBSD does? It > seemed extravagant to have 2 erase chars. when I first encountered it, but, > now I'm beginning to see why... That's an interesting idea... historically (and I mean decades) I have setteled on choosing one (^H) and forcing all systems I used over the years to use this one setting, but this might be more convenient... (And I have been thinking of switching since ^? seems more prevalent on keyboards than ^H these days. But it would mean that I have to switch everything over more or less at once.) > -RVP -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: wsvt25 backspace key should match terminfo definition
> The real issue is quite simple -- users want to be able to use the > easily reachable key that should delete the previously typed > character to actually delete the previously typed character. Yes...though, in many cases, that can involve negotiation with other pieces of software - anything using cbreak mode and doing its own line editing, such as a curses interface to something like IRC or ICB, might be an example. Your description below includes a number of unmarked assumptions, which may or may not be true. > Today in NetBSD we can also easily modify what the pressed key sends. > (E.g. with wsconsctl(8) or with xmodmap(1), depending on one's > environ) Assumption: the "terminal" in use consists of a keyboard and video display directly attached to the computer (as opposed to, say, a real serial terminal on a real serial port). > 3. type the key you want to use to erase character by character > 4. a) If it returns you to your shell prompt, continue to step 5a. > b) If it erases the most previous character each time you press >it, you're done -- press the return key, then . Assumption: c_cc[VEOF] is 4. This is not always true, especially in a document that's all about changing (other) elements of c_cc[]. (As someone who went through larval phase under VMS and even now runs with stty eof ^Z susp ^P kill ^X, I am particularly aware of VEOF assumptions.) > c) If two characters are echoed every time you press that key, for >example "^H", then press the return key followed by , ^D assumption again (and, below, I'm not going to mention repetitions of assumptions I've already called out), but also the assumption that ECHOCTL is set. > stty erase ^H Depending on the shell, and sometimes the shell's settings, ^ may be a shell metacharacter, leading to this not working. > Put a copy of this line in your ~/.profile followed by "tset -r" Assumption: the user is using a Bourne-derived shell (ie, one that reads .profile, as opposed to, say, .cshrc). (And why would you assume the user wants tset -r output blabbed as login noise?) > (You may, or may not, also want to change your interrupt key to > DEL with a command like "stty intr ^?".) More shell metacharacter assumptions, only even more likely to fail, because ? is much more commonly a metacharacter than ^. Some shells will still generate "^?" in the arglist, but some won't. In some cases it will depend on what files are present in some relevant directory. > stty intr ^C erase ^? ...assuming the user is willing to live with VINTR being ^C. > The Unix (or "UNIX") tradition is for "stty kill" to be 'DEL' (and > erase to be either 'BS' or '#', depending on how far back you go). If you go back far enough for (what I'm now, loosely, calling) VERASE to be #, then I think the corresponding VKILL character is @, is it not? (And, for that setting suite, I think DEL would be VINTR.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: wsvt25 backspace key should match terminfo definition
At Wed, 24 Nov 2021 08:08:39 -0500, Greg Troxel wrote: Subject: Re: wsvt25 backspace key should match terminfo definition > > The underlying issue is that the norms of some systems are to map that > "user wants to delete left easily reachable key" to BS and some want to > map it to DEL. I see these as the PC tradition and the UNIX tradition. I've just sent a long "history lesson" of a sort about this, but I'll try to distill it to what currently matters. I think describing it that way is, in part, what leads to some of the confusion surrounding this issue, especially for a system like NetBSD where for some scenarios the "system" is in full control over both sides of the problem. The real issue is quite simple -- users want to be able to use the easily reachable key that should delete the previously typed character to actually delete the previously typed character. That's it -- that's all there is to it. In the good old days this meant finding out what that key sent to the terminal would send when that key was pressed and using "stty erase" to set it properly (possibly also changing "stty intr" at the same time if that then conflicted). Sometimes this had to be done by the user, but ideally it would be the system manager who configured the correct defaults, especially for the "console" and any hard-wired terminals. Today in NetBSD we can also easily modify what the pressed key sends. (E.g. with wsconsctl(8) or with xmodmap(1), depending on one's environ) However there's also the issue of terminal type "descriptions", these days in the form of terminfo(5) (/usr/share/misc/terminfo) on NetBSD, and of course users can set up their own terminal descriptions. However it seems very difficult for many people to grasp what's really going with the interactions between all of these things and how to get the right behaviour, so unless you really do know how _ALL_ of the parts fit together, right from your keyboard to all of the applications you use, I would advise doing it the old fashioned way, and this should work no matter what kind of modern Unix or Unix-like system you are using, or what kind of terminal or console you are interacting with it through: 1. start the 'cat' program with no parameters: cat N.B.: This step and the next are critical -- you cannot trust anything that happens directly at a shell prompt to reveal what is really going on. 2. type a couple of words, but DO NOT press the return key asdf asdf 3. type the key you want to use to erase character by character 4. a) If it returns you to your shell prompt, continue to step 5a. b) If it erases the most previous character each time you press it, you're done -- press the return key, then . You should be back at the shell prompt and you don't need to do anything else. c) If two characters are echoed every time you press that key, for example "^H", then press the return key followed by , then continue to the next step (5): 5. Type "stty erase " followed by the two characters that were echoed, and then press the return key, e.g.: stty erase ^H Put a copy of this line in your ~/.profile followed by "tset -r" on the next line below, save your edits, logout and login and test that erase works correctly while running "cat". If not you will have to go back to step after restoring your ~/.profile to its previous state. If everything works OK, you're done. (You may, or may not, also want to change your interrupt key to DEL with a command like "stty intr ^?".) 5a. In this case your desired erase key is being recognized by the system as the interrupt key. You can examine the current settings with either "stty -a" or "stty -g". Most likely your interrupt key is set to be recognized as "^?". For example the third last line of the output from "stty -a" will include the phrase "intr = ^?;". In this case you can type the following command: stty intr ^C erase ^? Put a copy of this line in your ~/.profile, followed by "tset -r" on the next line below. save your edits, logout and login and test that erase works correctly while running "cat". If not you will have to go back to step after restoring your ~/.profile to its previous state. If everything works OK, you're done. If your interrupt key is not "^?" and you can't figure out what to do, then you need to ask for help. BTW, if you are using a real VT220 or compatible terminal then you can use "stty dec" to get the appropriate settings. This "should" work on the NetBSD console for i386 and amd64 and others using wscons(4). > So I think NetBSD should decide that we're follo
Re: wsvt25 backspace key should match terminfo definition
On Wed, 24 Nov 2021, Greg Troxel wrote: wscons is supposed to abstract all this, so making wsvt25-foo for different keyboard classes seems like the wrong approach. [...] The underlying issue is that the norms of some systems are to map that "user wants to delete left easily reachable key" to BS and some want to map it to DEL. I see these as the PC tradition and the UNIX tradition. So I think NetBSD should decide that we're following the UNIX tradition that this key is DEL, have wskbd map it that way for all keyboard types, and have stty erase start out DEL. (Plus of course carrying this across ssh so cross-deletionism works, which I think is already the case.) On Wed, 24 Nov 2021, Michael van Elst wrote: Some people also helped themselves with $TERMCAP. But I wouldn't create new entries for ps2 or usb (if anything use '-bs'/'-del'). Or, maybe have `erase=^?' and also a new `erase2=^H' like FreeBSD does? It seemed extravagant to have 2 erase chars. when I first encountered it, but, now I'm beginning to see why... -RVP
Re: wsvt25 backspace key should match terminfo definition
On Wed, Nov 24, 2021 at 12:05:28AM +, RVP wrote: > So, if I had a USB keyboard (don't have one to check right now), the > terminfo entry would be correct? How do we make this consistent then? > Have 2 terminfo entries: wsvt25-ps2 and wsvt25-usb (and fix-up getty > to set the correct one)? Most programs will use information from the terminal driver and only fall back to terminfo when the driver doesn't return anything. Some people also helped themselves with $TERMCAP. But I wouldn't create new entries for ps2 or usb (if anything use '-bs'/'-del'). Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: wsvt25 backspace key should match terminfo definition
> [...], and that in DEC tradition sent the DEL 0x1f character. Minor nit: DEL is 0x7f. 0x1f is US, Unit Separator, aka ^_. > [...c_cc settings...]. (Plus of course carrying this across ssh so > cross-deletionism works, which I think is already the case.) Mostly. ssh does define mechanisms for carrying most of the tty settings; I would expect most implementations would use it. However, it oddly does not define any way to pass IGNBRK BRKINT OXTABS ONOEOT CSTOPB CREAD HUPCL CLOCAL CRTSCTS CDTRCTS MDMBUF ECHOPRT ALTWERASE EXTPROC FLUSHO NOKERNINFO IUTF8 or CSIZE values other than 7 or 8, though most of those arguably shouldn't be passed through. It does define protocol values for IUCLC XCASE OLCUC PENDIN, the first three of which don't exist in the termios.h versions I have easy access to and the last of which has no business being passed - I have no idea why it has a protocol representation. When I did moussh, I ended up adding a private request to support passing ECHOPRT ALTWERASE NOKERNINFO and CSIZE values CS5 and CS6. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: wsvt25 backspace key should match terminfo definition
RVP writes: > On Tue, 23 Nov 2021, Michael van Elst wrote: > >> If you restrict yourself to PC hardware (i386/amd64 arch) then >> you probably have either >> >> a PS/2 keyboard -> the backspace key generates a DEL. >> a USB keyboard -> the backspace key generates a BS. >> >> That's something you cannot shoehorn into a single terminfo >> attribute and that's why many programs simply ignore terminfo >> here, in particular when you think about remote access. > > So, if I had a USB keyboard (don't have one to check right now), the > terminfo entry would be correct? How do we make this consistent then? > Have 2 terminfo entries: wsvt25-ps2 and wsvt25-usb (and fix-up getty > to set the correct one)? wscons is supposed to abstract all this, so making wsvt25-foo for different keyboard classes seems like the wrong approach. wskbd(4) says: • Mapping from keycodes (defined by the specific keyboard driver) to keysyms (hardware independent, defined in /usr/include/dev/wscons/wsksymdef.h). As uwe@ points out, the terms we use and the actual key labels are confusing. When I've talked about the DEL key, I've meant the key that the user types to delete backwards, almost always upper right and easily reachable when touch typing, and that in DEC tradition sent the DEL 0x1f character. It was pointed out that newer terminals have a backarrow logo, and I see that an IBM USB keyboard has that too. Then there's the BS key, which older (almost all actual?) terminals had, but my IBM USB keyboard doesn't have one, and my mac doesn't either. Looking in wsksymdef.h (netbsd-9, which is handy), we see "keysyms" which is what keycodes are supposed to map into, and it talks about them being aligned with ASCII. Relevant to this discussion there is #define KS_BackSpace0x08 #define KS_Delete 0x7f #define KS_KP_Delete0xf29f So that's for BS, DEL (to use ASCII) and the extended keypad "delete right" introduced with I think the VT220. On my USB keyboard, in NetBSD 9 wscons without trying to mess with mappings, I get backarrow (key where DEL should) ==> BS (^H) keypad Delete key (next to insert/home/end/pageup/pagedown) ==> DEL (^?) and I see that stty has erase to to ^H. The underlying issue is that the norms of some systems are to map that "user wants to delete left easily reachable key" to BS and some want to map it to DEL. I see these as the PC tradition and the UNIX tradition. So I think NetBSD should decide that we're following the UNIX tradition that this key is DEL, have wskbd map it that way for all keyboard types, and have stty erase start out DEL. (Plus of course carrying this across ssh so cross-deletionism works, which I think is already the case.) A quick glance at wskbd and ukbd did not enlighten me. xev shows similar wrong x keysyms, BS and DEL for "backarrow" and "keypad delete". signature.asc Description: PGP signature
Re: wsvt25 backspace key should match terminfo definition
On Tue, Nov 23, 2021 at 18:37:19 -0500, Greg Troxel wrote: > Valery Ushakov writes: > > > vt52 is different. I never used a real vt52 or a clone, but the > > manual at vt100.net gives the following picture: > > > > https://vt100.net/docs/vt52-mm/figure3-1.html > > > > and the description > > > > https://vt100.net/docs/vt52-mm/chapter3.html#S3.1.2.3 > > > > Key CodeAction Taken if Codes Are Echoed > > BACK SPACE010 Backspace (Cursor Left) function > > DELETE177 Nothing > > That is explaining what the terminal does when those codes are sent by > the computer. That is a different thing from how the computer > interprets user input. No. Or rather not only. Please, read the sentence before that table. The "code" column is the code that the terminal transmits when the key is pressed: Table 3-4 lists the function keys, the code they transmit to the host, and the terminal action taken if the code is echoed back to the terminal. > When using a VT52 on Seventh Edition, for example one pushed DEL to > remove the previous character, and the computer woudl send > "" to make it disappear and leave the cursor left. One > basically never pushed BS. It dawned on me that the terminals I used on the pdp-11 clone were (not surprisingly) vt clones and managed to find a picture of the keyboard, which jogged my memory: http://www.leningrad.su/museum/show_big.php?n=1539 so yeah, you would use DEL key on those to correct your typing mistakes. > > But vt200 and later use a different keyboard, lk201 (and i did use a > > real vt220 a lot) > > > > https://vt100.net/docs/vt220-rm/figure3-1.html > > > > that picture is not very good, the one from the vt320 manual is better > > > > https://vt100.net/docs/vt320-uu/chapter3.html > > > > vt220 does NOT have a configuration option that selects the code that > > the > So that is the "DEL" key, not the BS key. See, this is exactly why I said "
Re: wsvt25 backspace key should match terminfo definition
On Tue, 23 Nov 2021, Michael van Elst wrote: r...@sdf.org (RVP) writes: The kernel currently defines the backspace key as: $ fgrep CERASE /usr/include/sys/ttydefaults.h #define CERASE 0177 There is no 'defined as', in particular with emulated terminals that aren't even the same on all platforms. If you restrict yourself to PC hardware (i386/amd64 arch) then you probably have either a PS/2 keyboard -> the backspace key generates a DEL. a USB keyboard -> the backspace key generates a BS. That's something you cannot shoehorn into a single terminfo attribute and that's why many programs simply ignore terminfo here, in particular when you think about remote access. So, if I had a USB keyboard (don't have one to check right now), the terminfo entry would be correct? How do we make this consistent then? Have 2 terminfo entries: wsvt25-ps2 and wsvt25-usb (and fix-up getty to set the correct one)? -RVP
Re: wsvt25 backspace key should match terminfo definition
Valery Ushakov writes: > vt52 is different. I never used a real vt52 or a clone, but the > manual at vt100.net gives the following picture: > > https://vt100.net/docs/vt52-mm/figure3-1.html > > and the description > > https://vt100.net/docs/vt52-mm/chapter3.html#S3.1.2.3 > > Key CodeAction Taken if Codes Are Echoed > BACK SPACE 010 Backspace (Cursor Left) function > DELETE 177 Nothing That is explaining what the terminal does when those codes are sent by the computer. That is a different thing from how the computer interprets user input. When using a VT52 on Seventh Edition, for example one pushed DEL to remove the previous character, and the computer woudl send "" to make it disappear and leave the cursor left. One basically never pushed BS. > vt100 had similar keyboard (again, never used a real one personally) > > https://vt100.net/docs/vt100-ug/chapter3.html#F3-2 > > BACKSPACE 010 Backspace function > DELETE 177 Ignored by the VT100 same as vt52, I think. > But vt200 and later use a different keyboard, lk201 (and i did use a > real vt220 a lot) > > https://vt100.net/docs/vt220-rm/figure3-1.html > > that picture is not very good, the one from the vt320 manual is better > > https://vt100.net/docs/vt320-uu/chapter3.html > > vt220 does NOT have a configuration option that selects the code that > the But somehow the official terminfo database has kbs=^H for vt220! > > Later it became configurable: > > https://vt100.net/docs/vt320-uu/chapter4.html#S4.13 > > For vt320 (where it *is* configurable) terminfo has > > $ infocmp -1 vt320 | grep kbs > kbs=^?, Very interesting! > >> I think the first thing to answer is "what is kbs in terminfo supposed >> to mean". > > X/Open Curses, Issue 7 doesn't explain, other than saying "backspace" > key, which is an unfortunate name, as it's loaded. But it's > sufficiently clear from the context that it's the key that deletes > backwards, i.e. deletes under. So it's the codes generated by the DEL key (as opposed to the Delete key). >> My other question is how kbs is used from terminfo. Is it about >> generating output sequences to move the active cursor one left? If so, >> it's right. Is it about "what should the user type to delete left", >> then for a vt52/vt220, that's wrong. If it is supposed to be both, >> that's an architectural bug as those aren't the same thing. > > No, k* capabilities are sequences generated by the terminal when some > key is pressed. The capability for the sequence sent to the the > terminal to move the cursor left one position is cub1 > > $ infocmp -1 vt220 | grep cub1 > cub1=^H, > kcub1=\E[D, > > (kcub1 is the sequence generated by the left arrow _k_ey). Then I'm convinced that kbs should be \? for these terminals. signature.asc Description: PGP signature
Re: wsvt25 backspace key should match terminfo definition
Johnny Billquist writes: >> For vt320 (where it *is* configurable) terminfo has >> >>$ infocmp -1 vt320 | grep kbs >>kbs=^?, > > Which I think it should be. But what does kbs mean? - the ASCII character sent by the computer to move the cursor left? - the ASCII character sent by the BS key? - the ASCII character sent by the DEL key that the uses uss to delete left? signature.asc Description: PGP signature
Re: wsvt25 backspace key should match terminfo definition
On Tue, Nov 23, 2021 at 19:23:30 +0100, Johnny Billquist wrote: > > But somehow the official terminfo database has kbs=^H for vt220! > > Which is wrong. Exactly. > >kbs=^?, > > Which I think it should be. Amen! (unironically) :) -uwe
Re: wsvt25 backspace key should match terminfo definition
On 2021-11-23 18:59, Koning, Paul wrote: On Nov 23, 2021, at 12:53 PM, Valery Ushakov wrote: On Tue, Nov 23, 2021 at 09:22:43 -0500, Greg Troxel wrote: I think (memory is getting fuzzy) the problem is that the old terminals had a delete key, in the upper right, that users use to remove the previous character, and a BS key, upper left, that was actually a carriage control character. [... snip ...] I see the same kbs=^H on vt52. vt52 is different. I spent a lot of time on VT52, VT100, and VT2xx terminals. Me too. :-) All DEC terminals have a "delete" or "rub out" key, which transmits 0177. VT52 and VT100 also have a backspace key, which transmits 010. VT2xx (LK201 keyboard) do not have that key. Or rather, they do have a top row function key that is sometimes labeled BS but it sends an escape sequence, and is not taken seriously by most DEC programmers. It's a bit more convoluted than that. If you set a VT200 in VT100-mode, those three keys on the top row will in fact actually send LF, BS and ESC. Because if you wanted more VT100 compatibility, the VT100 had those keys, so the VT200 also had to have them if in VT100 mode. But yes, if you are in VT200 mode, they will in fact send various escape sequences. Not that it's really relevant here. The key to correct typing errors send a DEL, which is what this is about. DEC software convention always was that the delete/rubout key is how you erase the previous character. Backspace was never used for that, and there wasn't any obvious reason to have it on the keyboard. It is, of course, an output formatting character. Some DEC software used BS, which is why the VT200 in VT100 mode still had it. One of the more known pieces is FMS, which uses BS to step to the previous field, and TAB to step to the next field (there was no possibility of doing shift-TAB back then, which is popular nowadays for that same function). Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: wsvt25 backspace key should match terminfo definition
On 2021-11-23 18:53, Valery Ushakov wrote: On Tue, Nov 23, 2021 at 09:22:43 -0500, Greg Troxel wrote: I think (memory is getting fuzzy) the problem is that the old terminals had a delete key, in the upper right, that users use to remove the previous character, and a BS key, upper left, that was actually a carriage control character. [... snip ...] I see the same kbs=^H on vt52. vt52 is different. I never used a real vt52 or a clone, but the manual at vt100.net gives the following picture: Not really different. The VT52 key that you use to delete characters to the left sends a DEL. https://vt100.net/docs/vt52-mm/figure3-1.html and the description https://vt100.net/docs/vt52-mm/chapter3.html#S3.1.2.3 Key CodeAction Taken if Codes Are Echoed BACK SPACE 010 Backspace (Cursor Left) function DELETE 177 Nothing Yes. And noone would ever be hitting the backspace with the intent of deleting what you just typed. This all originates with the ASR33 actually. There the key was labelled "RUB OUT". And it sends a DEL. vt100 had similar keyboard (again, never used a real one personally) https://vt100.net/docs/vt100-ug/chapter3.html#F3-2 BACKSPACE010 Backspace function DELETE 177 Ignored by the VT100 I've used both VT52 and VT100, as well as almost every other model of VT terminal there is. But vt200 and later use a different keyboard, lk201 (and i did use a real vt220 a lot) https://vt100.net/docs/vt220-rm/figure3-1.html that picture is not very good, the one from the vt320 manual is better https://vt100.net/docs/vt320-uu/chapter3.html vt220 does NOT have a configuration option that selects the code that the Correct. But somehow the official terminfo database has kbs=^H for vt220! Which is wrong. Later it became configurable: https://vt100.net/docs/vt320-uu/chapter4.html#S4.13 Yes. It might only have been configurable if you had specific keyboards, but at least it was possible to change for some. But default is still DEL. For vt320 (where it *is* configurable) terminfo has $ infocmp -1 vt320 | grep kbs kbs=^?, Which I think it should be. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol
Re: wsvt25 backspace key should match terminfo definition
> On Nov 23, 2021, at 12:53 PM, Valery Ushakov wrote: > > > On Tue, Nov 23, 2021 at 09:22:43 -0500, Greg Troxel wrote: > >> >> I think (memory is getting fuzzy) the problem is that the old terminals >> had a delete key, in the upper right, that users use to remove the >> previous character, and a BS key, upper left, that was actually a >> carriage control character. > [... snip ...] >> I see the same kbs=^H on vt52. > > vt52 is different. I spent a lot of time on VT52, VT100, and VT2xx terminals. All DEC terminals have a "delete" or "rub out" key, which transmits 0177. VT52 and VT100 also have a backspace key, which transmits 010. VT2xx (LK201 keyboard) do not have that key. Or rather, they do have a top row function key that is sometimes labeled BS but it sends an escape sequence, and is not taken seriously by most DEC programmers. DEC software convention always was that the delete/rubout key is how you erase the previous character. Backspace was never used for that, and there wasn't any obvious reason to have it on the keyboard. It is, of course, an output formatting character. paul
Re: wsvt25 backspace key should match terminfo definition
On Tue, Nov 23, 2021 at 09:22:43 -0500, Greg Troxel wrote: > Valery Ushakov writes: > > > On Tue, Nov 23, 2021 at 00:01:40 +, RVP wrote: > > > >> On Tue, 23 Nov 2021, Johnny Billquist wrote: > >> > >> > If something pretends to be a VT220, then the key that deletes > >> > characters to the left should send DEL, not BS... > >> > Just saying... > >> > >> That's fine with me too. As long as things are consistent. I suggested the > >> kernel change because both terminfo definitions (and the FreeBSD console) > >> go for ^H. > > > > Note that the pckbd_keydesc_us keymap maps the scancode of the <- key to > > > > KC(14), KS_Cmd_ResetEmul, KS_Delete, > > > > i.e. 0x7f (^?). > > > > terminfo is obviously incorrect here. Amazingly, the bug is actually > > in vt220 description! wsvt25 just inherits from it: > > > > $ infocmp -1 vt220 | grep kbs > > kbs=^H, > > > > I checkeed termcap.src from netbsd-4 and it's wrong there too. I have > > no idea htf that could have happened. > > I think (memory is getting fuzzy) the problem is that the old terminals > had a delete key, in the upper right, that users use to remove the > previous character, and a BS key, upper left, that was actually a > carriage control character. [... snip ...] > I see the same kbs=^H on vt52. vt52 is different. I never used a real vt52 or a clone, but the manual at vt100.net gives the following picture: https://vt100.net/docs/vt52-mm/figure3-1.html and the description https://vt100.net/docs/vt52-mm/chapter3.html#S3.1.2.3 Key CodeAction Taken if Codes Are Echoed BACK SPACE010 Backspace (Cursor Left) function DELETE177 Nothing vt100 had similar keyboard (again, never used a real one personally) https://vt100.net/docs/vt100-ug/chapter3.html#F3-2 BACKSPACE 010 Backspace function DELETE177 Ignored by the VT100 But vt200 and later use a different keyboard, lk201 (and i did use a real vt220 a lot) https://vt100.net/docs/vt220-rm/figure3-1.html that picture is not very good, the one from the vt320 manual is better https://vt100.net/docs/vt320-uu/chapter3.html vt220 does NOT have a configuration option that selects the code that the https://vt100.net/docs/vt320-uu/chapter4.html#S4.13 For vt320 (where it *is* configurable) terminfo has $ infocmp -1 vt320 | grep kbs kbs=^?, > I think the first thing to answer is "what is kbs in terminfo supposed > to mean". X/Open Curses, Issue 7 doesn't explain, other than saying "backspace" key, which is an unfortunate name, as it's loaded. But it's sufficiently clear from the context that it's the key that deletes backwards, i.e. My other question is how kbs is used from terminfo. Is it about > generating output sequences to move the active cursor one left? If so, > it's right. Is it about "what should the user type to delete left", > then for a vt52/vt220, that's wrong. If it is supposed to be both, > that's an architectural bug as those aren't the same thing. No, k* capabilities are sequences generated by the terminal when some key is pressed. The capability for the sequence sent to the the terminal to move the cursor left one position is cub1 $ infocmp -1 vt220 | grep cub1 cub1=^H, kcub1=\E[D, (kcub1 is the sequence generated by the left arrow _k_ey). -uwe
Re: wsvt25 backspace key should match terminfo definition
Valery Ushakov writes: > On Tue, Nov 23, 2021 at 00:01:40 +, RVP wrote: > >> On Tue, 23 Nov 2021, Johnny Billquist wrote: >> >> > If something pretends to be a VT220, then the key that deletes >> > characters to the left should send DEL, not BS... >> > Just saying... >> >> That's fine with me too. As long as things are consistent. I suggested the >> kernel change because both terminfo definitions (and the FreeBSD console) >> go for ^H. > > Note that the pckbd_keydesc_us keymap maps the scancode of the <- key to > > KC(14), KS_Cmd_ResetEmul, KS_Delete, > > i.e. 0x7f (^?). > > terminfo is obviously incorrect here. Amazingly, the bug is actually > in vt220 description! wsvt25 just inherits from it: > > $ infocmp -1 vt220 | grep kbs > kbs=^H, > > I checkeed termcap.src from netbsd-4 and it's wrong there too. I have > no idea htf that could have happened. I think (memory is getting fuzzy) the problem is that the old terminals had a delete key, in the upper right, that users use to remove the previous character, and a BS key, upper left, that was actually a carriage control character. The basic problem is that in the PC world, the idea is that key where DEL should be has a backarrow the the PC world thinks it is backspace. That's the DEC-centric viewpoint of course :-) I think any change needs a careful proposal and review, becuase there are lots of opinions here and a change is likely to mess up a bunch of people's configs, even if they have worked around something broken. I don't mean "no changes", just that if you don't think this is a really hard problem you probably shouldn't change it (globally). Also /usr/include/sys/ttydefaults.h is about all of NetBSD on all sorts of hardware, not just PCs and there are lots of keyboards as well as actual terminals. Ever since we moved beyond ASR33, CERASE has been 0177 (my Unix use more or less began with a VT52 and a Beehive CRT). xterm has a config to say "make the key where DEL ought to be generate the key that the tty has configured as ERASE". I suspect that the right approach is 1) choose what wscons generates for the "key where DEL belongs" 2) have the tty set so that the choice in (1) is 'stty erase'. I see the same kbs=^H on vt52. I think the first thing to answer is "what is kbs in terminfo supposed to mean". My other question is how kbs is used from terminfo. Is it about generating output sequences to move the active cursor one left? If so, it's right. Is it about "what should the user type to delete left", then for a vt52/vt220, that's wrong. If it is supposed to be both, that's an architectural bug as those aren't the same thing. signature.asc Description: PGP signature
Re: wsvt25 backspace key should match terminfo definition
r...@sdf.org (RVP) writes: >The kernel currently defines the backspace key as: >$ fgrep CERASE /usr/include/sys/ttydefaults.h >#define CERASE 0177 There is no 'defined as', in particular with emulated terminals that aren't even the same on all platforms. If you restrict yourself to PC hardware (i386/amd64 arch) then you probably have either a PS/2 keyboard -> the backspace key generates a DEL. a USB keyboard -> the backspace key generates a BS. That's something you cannot shoehorn into a single terminfo attribute and that's why many programs simply ignore terminfo here, in particular when you think about remote access. The more appropriate data source is the tty setting that is also most often inherited from the remote computer. Terminfo becomes more real when you actually talk to a specific hardware terminal, e.g. connected to a serial console. Terminal emulations again add a level of ambiguity to such 'definitions'.
Re: wsvt25 backspace key should match terminfo definition
On Tue, Nov 23, 2021 at 00:01:40 +, RVP wrote: > On Tue, 23 Nov 2021, Johnny Billquist wrote: > > > If something pretends to be a VT220, then the key that deletes > > characters to the left should send DEL, not BS... > > Just saying... > > That's fine with me too. As long as things are consistent. I suggested the > kernel change because both terminfo definitions (and the FreeBSD console) > go for ^H. Note that the pckbd_keydesc_us keymap maps the scancode of the <- key to KC(14), KS_Cmd_ResetEmul, KS_Delete, i.e. 0x7f (^?). terminfo is obviously incorrect here. Amazingly, the bug is actually in vt220 description! wsvt25 just inherits from it: $ infocmp -1 vt220 | grep kbs kbs=^H, I checkeed termcap.src from netbsd-4 and it's wrong there too. I have no idea htf that could have happened. -uwe
Re: wsvt25 backspace key should match terminfo definition
On Tue, 23 Nov 2021, Johnny Billquist wrote: If something pretends to be a VT220, then the key that deletes characters to the left should send DEL, not BS... Just saying... That's fine with me too. As long as things are consistent. I suggested the kernel change because both terminfo definitions (and the FreeBSD console) go for ^H. -RVP
Re: wsvt25 backspace key should match terminfo definition
If something pretends to be a VT220, then the key that deletes
characters to the left should send DEL, not BS...
Just saying...
Johnny
On 2021-11-23 00:48, RVP wrote:
The kernel currently defines the backspace key as:
$ fgrep CERASE /usr/include/sys/ttydefaults.h
#define CERASE 0177
$
This should probably be changed to CTRL('h') to match both the
NetBSD and GNU terminfo backspace key definitions, otherwise
the key doesn't work right after reset(1) or tset(1):
$ infocmp wsvt25 | tr ',' '\n' | fgrep kbs
# Reconstructed from /usr/share/misc/terminfo.cdb
wsvt25|NetBSD wscons in 25 line DEC VT220 mode,
[...]
kbs=^H
$ /opt/ncurses/bin/infocmp wsvt25 | tr ',' '\n' | fgrep kbs
# Reconstructed via infocmp from file:
/opt/ncurses/share/terminfo/w/wsvt25
wsvt25|NetBSD wscons in 25 line DEC VT220 mode,
[...]
kbs=^H
$
Thanks,
-RVP
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
