🚀 go-pugleaf

The following region of code in keyboard.c does a nasty thing under certain
conditions:
(From function read_key_sequence, file keyboard.c)

      /* If C is not defined in either keymap
	 and it is an uppercase letter, try corresponding lowercase.  */

      if (NULL (global) && NULL (local) && UPPERCASEP (c))
	{
	  global = !NULL (nextglobal)
	    ? get_keyelt (access_keymap (nextglobal, DOWNCASE (c)))
	      : Qnil;

	  local = !NULL (nextlocal)
	    ? get_keyelt (access_keymap (nextlocal, DOWNCASE (c)))
	      : Qnil;

	  /* If that has worked better that the original char,
	     downcase it permanently.  */

	  if (!NULL (global) || !NULL (local))
	    {
	      keybuf[i] = c = DOWNCASE (c);
	    }
	}


I have commented out this entire region of code to no ill effect.

Here is what is bad about it:
This has the effect of folding upper to lower case when you least expect it.
When redefining a key say ^XN (which in the default bindings is unbound),
using the (global-set-key) function interactively will rebind the ^Xn key
and not the ^XN key as expected.  This all works correctly of course when
done from e-lisp.

It is plain wrong to call this kind of code out of a routine that gets called
when interactively binding keys.

I don't think there's any win anyway in folding case like this in an otherwise
case sensitive editor.  Please consider removing it in the next official
release of Emacs.  If people do actually use upper and lower case identically
when using prefix keymaps, then perhaps you want to use two versions of this
routine, the second being one that is only called out of global-set-key.

I am most pleased that in 2 years of (about) daily use this is the only
place where Emacs has bitten me with an actual bug.

Thank you.
-- 
steve@romulus.SEDD.TRW.COM	baur