Re: Raw keys in C-h k and C-h c

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/address@hidden> writes:

> RMS:
> > Can you arrange to suppress the "(translated from ...)" output
> > in that case?
> 
> I don't have any idea for how to tell the difference between the
> cases for `DEL (translated from <backspace>)'
> and `<f1> a (translated from ESC O P a)'.  Also I'd still want to be
> able to find this `ESC O P a' for those cases where I'm trying to fix
> my function-key-map.

What about letting C-h k work as it has always done, and only
let it report 'translated from' if given a C-u prefix argument?

Alternatively, always report the translations if both sequences are of
length 1 (like <bs> to DEL), but only report the more complex
translations if C-u is given.
 
> RMS:
> > Aside from that, the implementation is really ugly.  Maybe it could be
> > much cleaner if read_key_sequence recorded the actual keys read, or
> > some info about them.
> 
> It could be improved with a bit of help from the C code, indeed.
> F.ex. a `raw-event-counter' would do the trick since the "ugly"
> part of the code just tries to figure out how many raw events
> belong to the curent key sequence.
> 

Doesn't the function this-single-command-raw-keys do what you want?
AFAICS, it returns the raw keys read by the most recent
call to read-key-sequence -- including (interactive "k").

E.g. if I bind the following function to both [f1 a] and [f1 b],
and enter f1 a f1 b, it reports ESC O P b (rather than ESC O P a):

(defun f1x (arg)
  (interactive "kEnter key: ")
  (message (key-description (this-single-command-raw-keys))))

But if this is really what it is also expected to do, then the
documentation for the function is not correct as it doesn't mention
the implications of using read-key-sequence.  Eli?

-- 
Kim F. Storm <address@hidden> http://www.cua.dk