uppercase->lowercase and function-key-map

uppercase->lowercase and function-key-map

[Stefan Monnier]

When ESC O H fails to be found in function-key-map and the `H' is
turned into `h' should `ESC O h' be looked up in function-key-map again ?

My gut feeling says no and a comment in read_key_sequence agrees:

      /* If the sequence is unbound, see if we can hang a function key
	 off the end of it.  We only want to scan real keyboard input
	 for function key sequences, so if mock_input says that we're
	 re-reading old events, don't examine it.  */

but further down in the same function, when we downcase the `H'
the code does:

	  /* We have to do this unconditionally, regardless of whether
	     the lower-case char is defined in the keymaps, because they
	     might get translated through function-key-map.  */
	  keybuf[t - 1] = new_key;
	  mock_input = max (t, mock_input);

	  fkey_map = prev_fkey_map;
	  fkey_start = prev_fkey_start;
	  fkey_end = prev_fkey_end;

	  keytran_map = prev_keytran_map;
	  keytran_start = prev_keytran_start;
	  keytran_end = prev_keytran_end;

	  goto replay_sequence;

where the `fkey_start = prev_fkey_start' implies that we might rescan
the new key sequence for function-key-map bindings (whether and
when this rescan actually happen, I don't really know because the
code is not the clearest ever).

Further more the above few lines come from the following two changes:

revision 1.357
date: 1995/08/08 05:12:31;  author: rms;  state: Exp;  lines: +61 -43
(read_key_sequence): Undo previous change.
Instead, put back the orig_uppercase event if key is not defined.
When downcasing, back up one step in key-translation processing.
----------------------------
revision 1.356
date: 1995/08/03 00:02:07;  author: rms;  state: Exp;  lines: +64 -20
(read_key_sequence): Don't downshift an event
if that fails to make it bound.
(follow_key): Don't alter contents of NEXT until the end.
----------------------------

which seem to indicate that Richard went through some amount of trouble
in order to make sure that the key-translation would be (at least
partly) redone.

Does anybody know why one would want to redo the key-translation ?


	Stefan

Re: uppercase->lowercase and function-key-map

[Richard Stallman]

    When ESC O H fails to be found in function-key-map and the `H' is
    turned into `h' should `ESC O h' be looked up in function-key-map again ?

    My gut feeling says no and a comment in read_key_sequence agrees:

	  /* If the sequence is unbound, see if we can hang a function key
	     off the end of it.  We only want to scan real keyboard input
	     for function key sequences, so if mock_input says that we're
	     re-reading old events, don't examine it.  */

I think that comment is inconclusive.  However, the manual says that
key-translation-map operates on the output from function-key-map
and not vice versa.  That suggests you are right.

    where the `fkey_start = prev_fkey_start' implies that we might rescan
    the new key sequence for function-key-map bindings (whether and
    when this rescan actually happen, I don't really know because the
    code is not the clearest ever).

That could be a bug.  The results of key-translation-map translations
should not be reprocessed through function-key-map.

Re: uppercase->lowercase and function-key-map

[Stefan Monnier]

>     When ESC O H fails to be found in function-key-map and the `H' is
>     turned into `h' should `ESC O h' be looked up in function-key-map again ?
> 
>     My gut feeling says no and a comment in read_key_sequence agrees:
> 
> 	  /* If the sequence is unbound, see if we can hang a function key
> 	     off the end of it.  We only want to scan real keyboard input
> 	     for function key sequences, so if mock_input says that we're
> 	     re-reading old events, don't examine it.  */
> 
> I think that comment is inconclusive.  However, the manual says that
> key-translation-map operates on the output from function-key-map
> and not vice versa.  That suggests you are right.
> 
>     where the `fkey_start = prev_fkey_start' implies that we might rescan
>     the new key sequence for function-key-map bindings (whether and
>     when this rescan actually happen, I don't really know because the
>     code is not the clearest ever).
> 
> That could be a bug.  The results of key-translation-map translations
> should not be reprocessed through function-key-map.

By "`H' is turned into `h'" above I meant "by the upper->lower mechanism"
rather than by key-translation-map.  More to the point, my question
completely disregarded key-translation-map (it's complex enough without it).

So to repeat it: if `ESC O H' is not found in the function-key-map
and neither in key-translation-map and neither in any active map,
Emacs will turn it into `ESC O h' and "try again".

Now should the "try again" include looking up function-key-map ?
And/or should the "try again" include looking up key-translation-map ?
Or should it only include looking up normal active keymaps ?


	Stefan

Re: uppercase->lowercase and function-key-map

[Richard Stallman]

    So to repeat it: if `ESC O H' is not found in the function-key-map
    and neither in key-translation-map and neither in any active map,
    Emacs will turn it into `ESC O h' and "try again".

This case conversion is a user-level feature--so that when a mode
defines letters as commands, upper case will work like lower case.

So this "second try" really should not include function-key-map or
key-translation-map.  Those maps should be totally case-sensitive.
The sequence ESC O h that results from conversion should be tested
only against the active keymaps, not against function-key-map or
key-translation-map.