function-key-map

function-key-map

[Richard Stallman]

Now that the original purpose of `function-key-map' is done
by `input-decode-map', what purposes should `function-key-map'
be used for?  Is it still useful?

Re: function-key-map

[Stefan Monnier]

> Now that the original purpose of `function-key-map' is done
> by `input-decode-map', what purposes should `function-key-map'
> be used for?  Is it still useful?

Yes, it's still very useful.  See for example how term/xterm.el uses both.
Or term/x-win.el.  I.e. it's useful to give optional remapping corresponding
to alternative key-names.

I think it'd even be worthwhile to extend the functionality of
function-key-map in the following ways:
- make it possible to specify a "set of keys" to remap via e.g. a predicate.
- apply function-key-map repeatedly (i.e. apply it to its output).

This way we could try and move all the ad-hoc C code in read-key-sequence
which:
- drops down-mouse-N events if they're not bound
- remaps triple-mouse-N to double-mouse-N if not bound
- remaps double-mouse-N to mouse-N if not bound
- remaps shift-<key> to <key> if not bound
- a few more along the same lines

we could also add

- remap all modifier combinations of mouse-4 to wheel-up (with the same
  modifiers), and similarly for wheel-down, wheel-left and wheel-right.

This would significantly help clean up the horrendously long
read_key_sequence function.


        Stefan

Re: function-key-map

[T. V. Raman]

I use it additionally to define special keys on the console like
ctrl+arrows which are otherwise only available under X -- see 
http://emacspeak.googlecode.com/svn/trunk/tvr/console.el
and 
http://emacspeak.googlecode.com/svn/trunk/tvr/console-keymaps/

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:
    >> Now that the original purpose of `function-key-map' is
    >> done by `input-decode-map', what purposes should
    >> `function-key-map' be used for?  Is it still useful?
    Stefan> 
    Stefan> Yes, it's still very useful.  See for example how
    Stefan> term/xterm.el uses both.  Or term/x-win.el.
    Stefan> I.e. it's useful to give optional remapping
    Stefan> corresponding to alternative key-names.
    Stefan> 
    Stefan> I think it'd even be worthwhile to extend the
    Stefan> functionality of function-key-map in the following
    Stefan> ways: - make it possible to specify a "set of keys"
    Stefan> to remap via e.g. a predicate.  - apply
    Stefan> function-key-map repeatedly (i.e. apply it to its
    Stefan> output).
    Stefan> 
    Stefan> This way we could try and move all the ad-hoc C code
    Stefan> in read-key-sequence which: - drops down-mouse-N
    Stefan> events if they're not bound - remaps triple-mouse-N
    Stefan> to double-mouse-N if not bound - remaps
    Stefan> double-mouse-N to mouse-N if not bound - remaps
    Stefan> shift-<key> to <key> if not bound - a few more along
    Stefan> the same lines
    Stefan> 
    Stefan> we could also add
    Stefan> 
    Stefan> - remap all modifier combinations of mouse-4 to
    Stefan> wheel-up (with the same modifiers), and similarly for
    Stefan> wheel-down, wheel-left and wheel-right.
    Stefan> 
    Stefan> This would significantly help clean up the
    Stefan> horrendously long read_key_sequence function.
    Stefan> 
    Stefan> 
    Stefan>         Stefan
    Stefan> 
    Stefan> 
    Stefan> _______________________________________________
    Stefan> Emacs-devel mailing list Emacs-devel@gnu.org
    Stefan> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: function-key-map

[Richard Stallman]

    Yes, it's still very useful.  See for example how term/xterm.el uses both.
    Or term/x-win.el.  I.e. it's useful to give optional remapping corresponding
    to alternative key-names.

Can you put something in the Lisp manual explaining when it is right
to use `function-key-map'?  Perhaps cite and explain this example.

    I think it'd even be worthwhile to extend the functionality of
    function-key-map in the following ways:
    - make it possible to specify a "set of keys" to remap via e.g. a predicate.
    - apply function-key-map repeatedly (i.e. apply it to its output).

The second one would be natural (though it might break something), but
I think there is no natural way to do the former.  Maybe we should
move read-key-sequence into Lisp, but I don't want to try to program
it thru a keymap.

Re: function-key-map

[Stefan Monnier]

> I use it additionally to define special keys on the console like
> ctrl+arrows which are otherwise only available under X -- see 
> http://emacspeak.googlecode.com/svn/trunk/tvr/console.el
> and 
> http://emacspeak.googlecode.com/svn/trunk/tvr/console-keymaps/

That's what input-decode-map is for.


        Stefan

Re: function-key-map

[T. V. Raman]

Oh I see -- will go learn that ;-)

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:
    >> I use it additionally to define special keys on the
    >> console like ctrl+arrows which are otherwise only
    >> available under X -- see
    >> http://emacspeak.googlecode.com/svn/trunk/tvr/console.el
    >> and
    >> http://emacspeak.googlecode.com/svn/trunk/tvr/console-keymaps/
    Stefan> 
    Stefan> That's what input-decode-map is for.
    Stefan> 
    Stefan> 
    Stefan>         Stefan
    Stefan> 
    Stefan> 
    Stefan> _______________________________________________
    Stefan> Emacs-devel mailing list Emacs-devel@gnu.org
    Stefan> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: function-key-map

[Richard Stallman]

	Stefan> Yes, it's still very useful.  See for example how
	Stefan> term/xterm.el uses both.  Or term/x-win.el.
	Stefan> I.e. it's useful to give optional remapping
	Stefan> corresponding to alternative key-names.

Is there a reason to use `function-key-map' for this,
rather than `key-translation-map'?  Is it so that they won't
be translated if they have bindings?

In any case, the name `function-key-map' doesn't fit this kind of
usage.  I gave it that name because its main purpose was to map escape
sequences into function keys, but that job is now done by
`input-decode-map'.

So perhaps we should rename the current `function-key-map' to
`default-key-translation-map', then rename the current
`input-decode-map' to `function-key-map'.

What do you think?

Re: function-key-map

[Stefan Monnier]

Stefan> Yes, it's still very useful.  See for example how
Stefan> term/xterm.el uses both.  Or term/x-win.el.
Stefan> I.e. it's useful to give optional remapping
Stefan> corresponding to alternative key-names.

> Is there a reason to use `function-key-map' for this,
> rather than `key-translation-map'?  Is it so that they won't
> be translated if they have bindings?

Yes.  Those mappings are "tentative".  E.g. mapping [f23] to [S-f11] is not
guaranteed to be correct, and even less so for [f13] -> [S-f1] if your
keyboard does have an key f13.
So it's a bit like giving those events several names rather than rewrite one
name to another.

function-key-map under X11 should also contain mappings from mouse-4 to
wheel-up, and here again this mapping is tentative: mouse-4 often is the
button that corresponds to the up movement of a mouse wheel, but sometimes
it is just a plain extra mouse button, so the reampping of mouse-4 to
wheel-up should only be done if mouse-4 has no binding.

> In any case, the name `function-key-map' doesn't fit this kind of
> usage.  I gave it that name because its main purpose was to map escape
> sequences into function keys, but that job is now done by
> `input-decode-map'.

> So perhaps we should rename the current `function-key-map' to
> `default-key-translation-map', then rename the current
> `input-decode-map' to `function-key-map'.

> What do you think?

I agree that function-key-map is a misnomer now.

The choice of `input-decode-map' was somewhat arbitrary.  It was based on
the fact that it is used by encoded-kb.el and also that the tty escape
sequences for function keys are a form of "encoding" of non-ascii events
onto an ascii stream.  I'm not wedded to this name, tho I think the name
makes sense and describes well what it does.

Renaming input-decode-map to function-key-map would be a bad idea because it
would introduce an incompatibility: the behavior of input-decode-map is
different, so while some uses of function-key-map are better moved to
input-decode-map, others (such as the ones mentioned at the beginning of
this message) need to stay on function-key-map.  Actually the name
function-key-map would also be bad because it would fail to describe what
the map does (and instead describes what it was meant for).

Renaming function-key-map to `default-key-translation-map' would also seem
like a bad idea:
- the name seems to imply that it's the global binding of "the
  buffer-local key-translation-map".
- the name suggests the behavior of that map will be the same as the behavior
  of `key-translation-map' although in reality it is different.

Right now, in the term/*.el files that I've changed to take advantage of
input-decode-map, I've used "foo-alternative-maps" for the keymaps that
hold bindings that need to be added to function-key-map, so maybe we could
rename function-key-map to alternative-input-names-map or
fallback-input-rename-map?


        Stefan

Re: function-key-map

[Richard Stallman]

    Renaming input-decode-map to function-key-map would be a bad idea because it
    would introduce an incompatibility: the behavior of input-decode-map is
    different, so while some uses of function-key-map are better moved to
    input-decode-map, others (such as the ones mentioned at the beginning of
    this message) need to stay on function-key-map.

Ok.

      Actually the name
    function-key-map would also be bad because it would fail to describe what
    the map does (and instead describes what it was meant for).

That is not necessarily a bad thing, but this map is not solely for
producing function keys.  So lt's stay with `input-decode-map'.

    Renaming function-key-map to `default-key-translation-map' would also seem
    like a bad idea:
    - the name seems to imply that it's the global binding of "the
      buffer-local key-translation-map".
    - the name suggests the behavior of that map will be the same as the behavior
      of `key-translation-map' although in reality it is different.

Those are valid arguments against the name `default-key-translation-map',
but not against renaming to a different name.

    Right now, in the term/*.el files that I've changed to take advantage of
    input-decode-map, I've used "foo-alternative-maps" for the keymaps that
    hold bindings that need to be added to function-key-map, so maybe we could
    rename function-key-map to alternative-input-names-map or
    fallback-input-rename-map?

"Alternative" does not clearly describe the functionality, but
"fallback" does.  (I used "default" for the same meaning.)

So how about `key-fallback-alias-map'?

Re: function-key-map

[Stefan Monnier]

> That is not necessarily a bad thing, but this map is not solely for
> producing function keys.  So lt's stay with `input-decode-map'.

OK.

> Those are valid arguments against the name `default-key-translation-map',
> but not against renaming to a different name.

Agreed.

>     Right now, in the term/*.el files that I've changed to take advantage of
>     input-decode-map, I've used "foo-alternative-maps" for the keymaps that
>     hold bindings that need to be added to function-key-map, so maybe we could
>     rename function-key-map to alternative-input-names-map or
>     fallback-input-rename-map?

> "Alternative" does not clearly describe the functionality, but
> "fallback" does.  (I used "default" for the same meaning.)

> So how about `key-fallback-alias-map'?

Sounds OK to me.  Should I rename input-decode-map to key-decode-map
as well?  I used `input' rather than `key' since it also applies to other
events (mouse events, etc...), but it probably makes more sense to
stay consistent.


        Stefan

Re: function-key-map

[Richard Stallman]

    Sounds OK to me.  Should I rename input-decode-map to key-decode-map
    as well?  I used `input' rather than `key' since it also applies to other
    events (mouse events, etc...), but it probably makes more sense to
    stay consistent.

Maybe it is better to move to names without `key'.
It is redundant, in this context.  So maybe `fallback-alias-map'?

Re: function-key-map

[Stefan Monnier]

>     Sounds OK to me.  Should I rename input-decode-map to key-decode-map
>     as well?  I used `input' rather than `key' since it also applies to other
>     events (mouse events, etc...), but it probably makes more sense to
>     stay consistent.

> Maybe it is better to move to names without `key'.
> It is redundant, in this context.  So maybe `fallback-alias-map'?

I'm not sure about that: I think it's important to keep some distinguishing
word in there to say that these are maps from keys to keys rather than from
keys to commands.  `key' used to be the magic word to indicate this fact.


        Stefan

Re: function-key-map

[Richard Stallman]

    I'm not sure about that: I think it's important to keep some distinguishing
    word in there to say that these are maps from keys to keys rather than from
    keys to commands.  `key' used to be the magic word to indicate this fact.

Actually I never thought it was supposed to mean that.  The name
`function-key-map' means that's where function keys are produced from
other events.  `key-translation-map' also has the word "key" in it,
but the grammatical function of "key" is different in the two names,
so I do not see them as parallel.

Re: function-key-map

[Stefan Monnier]

>     I'm not sure about that: I think it's important to keep some
>     distinguishing word in there to say that these are maps from keys to
>     keys rather than from keys to commands.  `key' used to be the magic
>     word to indicate this fact.

> Actually I never thought it was supposed to mean that.  The name
> `function-key-map' means that's where function keys are produced from
> other events.  `key-translation-map' also has the word "key" in it,
> but the grammatical function of "key" is different in the two names,
> so I do not see them as parallel.

I did not mean to imply that it was done on purpose, but I think it was
a good accident and I think we should preserve such a thing to make it clear
that these are keymaps of a different type ("keys -> keys" instead of
the usual "keys -> command").


        Stefan