Date: Mon, 11 Jun 2001 11:09:57 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: "Mark E." cc: djgpp-workers AT delorie DOT com Subject: Re: old archived termios submission In-Reply-To: <3B23A7E9.663.2BC22F@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sun, 10 Jun 2001, Mark E. wrote: > The enhanced keyboard support looks very much like that in Bash's version of > tminit.c. For one, it has the second queue that I don't care for. Right. I can't say I like this implementation. First, there are several changes lumped together here, some of which have nothing to do with the issue at hand (like signal handling and the surprising addition of FSEXT support, I cannot in the world figure out what for). More importantly, all this seems excessive to me: why not just have a table with an escape sequence for each extended key we want to support, and be done with it? (A simple example of such approach is something I wrote for info.exe, see the file pcterm.c in the Texinfo distribution.) And when we generate more than one character for a keystroke, they should be put into the same queue that already exists in tminit.c. One other thing which I think we should be careful not to stumble upon is that some scan codes are mapped into different characters on different national keyboards. We should try very hard not to include such scan codes in termios, to avoid the need for having separate translations for each type of keyboard, which is a mess to get right. (I'm not saying that the code Mark posted does use these scan codes; I simply didn't look at it well enough to tell.)