Date: Tue, 12 Jun 2001 11:49:02 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: "Mark E." <snowball3 AT bigfoot DOT com>
cc: djgpp-workers AT delorie DOT com
Subject: Re: old archived termios submission
In-Reply-To: <3B25001A.18075.735B29@localhost>
Message-ID: <Pine.SUN.3.91.1010612114840.1700M-100000@is>
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 Mon, 11 Jun 2001, Mark E. wrote:

> > 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?
> 
> I think "trans_mapping_chras_at" is that table. It's used by 
> "__direct_check_extened_keystroke_at" on the scan code. But it does seem (at 
> first glance) to be more complicated than it needs to be and hard to follow.

That's what I meant: it's too complicated.  The multiple indirection
that goes through several tables is hard to understand, and the
rationale behind the particular encoding of the values in the table
(before applying the shift modifiers) is unclear.

> (and btw, the spelling of the symbols is correct.)

Yeah, I know ;-)

> And what encoding for the extended keys should be used? The one used by Bash 
> has been in use for a while now. Should we use it or design a new one?

If you mean the values in trans_mapping_chras_at, then I simply don't
understand them.  If you do, perhaps you could explain; I tend to
dislike any code I cannot understand ;-)