lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Re: Changing the keymap code


From: dickey
Subject: Re: lynx-dev Re: Changing the keymap code
Date: Sat, 6 Feb 1999 07:04:51 -0500 (EST)

> On Fri, Feb 05, 1999, Doug Kaufman (address@hidden) said: 
> | 
> | I would plead with those proposing changes in the keymap code to do it 
> | carefully, since some of the recent patches are very likely to break 
> | the coding for DOS. Specifically, please do not INSERT a key into the 
> | mapping, as this will change all the mappings above. 
> | 
> | Since I did the patch that expanded the keymap[] array in LYKeymap.c 
> | with the #ifdefs to make it work for the different types of build 
> | under DOS, I will try to explain what I did as best as I understand 
> | it.  [...] 

ultimately it's my problem (to integrate the changes).  But I rely on
people testing with DJGPP to spot some of the problems (and I miss a few).
  
> I don't know if you are refering to the patch I posted earlier today 
> (which had several warnings about it not having been tested WRT non- 
> standard, weird key bindings), or to the patch that was made to -dev.7 
> that added a "key binding" for some bloody mouse thingy, which *broke* 
> -dev.8 and subsequent versions of lynx.  Or to something completely 
> different. 
>  
> In any case, all I was trying to do with today's patch was *fix* some- 
> thing that was working prior to -dev.8, but has been busted since. 
>  
> It is unfortunate that the problem introduced by an attempt to add some 
> kind of mouse support, went unrecognized for so long, but it did. 
>  
> If my attempt at providing a "correction" breaks other things, I would 
> suggest that the original code added to -dev.7 be backed out, until *it* 
> can be added in, in a way which does not break the prior, correct behavior. 
>  
> I've no idea what the "final solution" ought to look like.  Perhaps what 
> is needed is completely separate keymaps for all the various platforms, 
> compilers, and screen i/o libs, not to mention various keyboards, rodents, 
> and possibly the phase of the moon at compile time. 
>  
> I'm certainly not the one to try and tackle *that* job ...! 
>  
> /kim 


-- 
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey

reply via email to

[Prev in Thread] Current Thread [Next in Thread]