Messages in this thread |  | | From | zefram@fysh ... | Subject | Re: [PATCH] tty canonical mode: nicer erase behaviour | Date | Mon, 24 Sep 2001 03:17:31 +0100 |
| |
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: >Which is why they have termcap, terminfo, and x keyboard maps. The kernel >is not there to cover up for usermode programmers inability to get >things right.
Aha, I believe I now see a substantive difference of opinion. You argue that the tty line discipline depends on being configured for the terminal by usermode code, and that it should remain so, whereas I am proposing that it adopt a strategy with some additional logic so that it doesn't require usermode configuration. Please correct me if this is not a fair representation of your position. I'm now going to switch from correcting inaccurate statements to an attempt to persuade you on this underlying disagreement.
Most of the tty's control characters are perfectly simple user choices. The user can sensibly choose to use ^R or ^L to invoke the REPRINT function, or indeed not to have any such control character, and such choices can be executed by a very simple invocation of stty. This kind of choice is not affected by what terminal the user is using, because the ^R or whatever keystroke is just the same on any terminal. This kind of choice extends to the ERASE character, provided that the user is picking something like the traditional #. But uniquely among the tty control characters, the most commonly desired setting for ERASE is not a particular character, but rather "whatever my backspace key sends".
Theoretically, a user could set up the ERASE key to whatever their backspace key sends by doing "stty erase $(echotc kd)". In practice this doesn't work nearly as well as it should -- it relies on having echotc, and on the terminfo database being sufficiently complete and accurate for the current terminal, which is made particularly difficult by things like the xterm variations previously mentioned. It is true that this is principally a usermode problem, and indeed I would like to see the usermode improvements that would make this a viable solution.
However, this usermode approach, of using terminfo, seems out of character with the tty canonical mode code. In every other aspect, it is terminal-independent. For output, the only control characters it uses are ^G, ^M, ^J and ^H, which behave the same way on pretty much any terminal. (Actually, because of this policy of using only terminal-independent control characters, backspacing past a line wrap doesn't display correctly on most terminals.) For input, with the default control character settings, the only special keys used are Return and Backspace.
When handling the Return key, under default settings, the tty line discipline accepts both ^M and ^J as indicating the end of the line. (Actually, internally it translates ^M to ^J.) This allows for some variation in terminal behaviour and in translations that might occur before the input gets to the tty. The internal translation can be turned off or modified, but the particular characters that can be accepted are hardcoded, and the default behaviour is to accept both.
What I propose is that this manner of handling the Return key -- accepting both possible characters that can result from the key, without requiring usermode configuration to tell it which one to use -- be extended to the Backspace key when used for its normal function. (Obviously the mechanism is a little different, since the ERASE character is more configurable than the end-of-line character.) By doing this, the tty line discipline code would become fully terminal-independent under its default settings, which seems a worthwhile goal for a program that is so nearly there already.
I accept that we have here an issue about which reasonable people can disagree, and so if the disagreement now persists then I don't intend to pursue it much further in this forum.
-zefram - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |