bug#4709: 23.1; keyboard-translate not working with emacs daemon

bug#4709: 23.1; keyboard-translate not working with emacs daemon

[Ryo Furue]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

My ~/.emacs has "(keyboard-translate ?\C-h ?\C-?)".  I start an emacs
daemon with

  $ /usr/bin/env XMODIFIERS=@im=none /usr/bin/emacs23 --daemon

Then I start a client

  $ /usr/bin/emacsclient.emacs23 -c

But, "C-h" still invokes the emacs help system.

Next, I evaluate "(keyboard-translate ?\C-h ?\C-?)" on the client.
Then "C-h" starts to work as delete.

Finally, I invoke another client with
"/usr/bin/emacsclient.emacs23 -c", on which "C-h" works as delete
from the beginning.

I'm not sure if this is a bug.  I just wish there were a
"proper" mechanism to set a keyboard-translate-table globally.

(I tried many things, including reading etc/PROBLEMS, searching
 your bug tracking newsgroup, asking this question at gnu.emacs.help,
 reading the emacs info pages about reporting bugs, etc., but
 couldn't find this issue reported.)

Best regards,
Ryo

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/usr/share/emacs/23.1/etc/DEBUG for instructions.


In GNU Emacs 23.1.1 (i486-pc-linux-gnu, GTK+ Version 2.16.5)
 of 2009-09-13 on raven, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.10603901
configured using `configure  '--build=i486-linux-gnu' '--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.1/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: @im=none
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  show-paren-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-f C-f C-f C-f C-f C-f C-n C-n C-n C-n C-n C-n <return> 
u C-p C-p C-p C-p C-p C-p C-p u C-n <return> C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-f C-p C-f C-f C-f C-f 
<return> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-f C-f C-f C-f C-f C-f 
C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f 
C-f C-f C-f C-f C-f C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-v C-p C-p C-p u C-n C-f C-f C-f C-f 
<return> u C-n <return> C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f 
C-f C-f C-f C-f C-f C-n C-n C-f C-f C-f C-f C-f C-f 
C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f 
C-f C-n C-n C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b 
C-b C-b C-n C-n C-n C-n C-n C-n C-p C-f C-f C-f C-f 
C-f C-f C-f C-f C-f C-f C-f C-f C-n C-n C-n C-n C-n 
C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b C-b 
C-b C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n <escape> x e m a c s - v e r s i o n <return> C-x 
C-b C-n C-n C-n C-n <return> C-p C-p C-p C-SPC C-e 
<escape> x r e p o r TAB TAB b u TAB <return>

Recent messages:
Commands: m, u, t, RET, g, k, S, D, Q; q to quit; h for help
uncompressing emacs.gz...done
uncompressing emacs-6.gz...done
uncompressing emacs-1.gz...done
uncompressing emacs-6.gz...done
GNU Emacs 23.1.1 (i486-pc-linux-gnu, GTK+ Version 2.16.5) of 2009-09-13 on raven, modified by Debian
Updating buffer list...done
Commands: m, u, t, RET, g, k, S, D, Q; q to quit; h for help
Mark set
Making completion list...

bug#4709: 23.1; keyboard-translate not working with emacs daemon

[Stefan Monnier]

> My ~/.emacs has "(keyboard-translate ?\C-h ?\C-?)".  I start an emacs
> daemon with

>   $ /usr/bin/env XMODIFIERS=@im=none /usr/bin/emacs23 --daemon

> Then I start a client

>   $ /usr/bin/emacsclient.emacs23 -c

> But, "C-h" still invokes the emacs help system.

> Next, I evaluate "(keyboard-translate ?\C-h ?\C-?)" on the client.
> Then "C-h" starts to work as delete.

> Finally, I invoke another client with
> "/usr/bin/emacsclient.emacs23 -c", on which "C-h" works as delete
> from the beginning.

> I'm not sure if this is a bug.  I just wish there were a
> "proper" mechanism to set a keyboard-translate-table globally.

AFAIK, you cannot set it globally.  You can arrange to set it in every
terminal (by putting (keyboard-translate ?\C-h ?\C-?) on some hook whose
name escapes me), tho.

Still, I wonder: why would you want to set such a mapping everywhere?


        Stefan

bug#4709: 23.1; keyboard-translate not working with emacs daemon

[Ryo Furue]

Hi Stefan,

Thank you very much for your response.

| AFAIK, you cannot set it globally.
|
Then, could we make it a request for a new feature?
We could even say that the keyboard-translate functionality
is partially broken because it sometimes works and sometimes
doesn't (Please recall my example).

| You can arrange to set it in every
| terminal (by putting (keyboard-translate ?\C-h ?\C-?) on some
| hook whose name escapes me), tho.

That sounds promising.

| Still, I wonder: why would you want to set such a mapping
| everywhere?
| 
I'm not sure if I understand your question. . . .  If you want
a keyboard translation, you'd want it everywhere consistently,
wouldn't you?

In this particular case, I want C-h to delete the character
before the cursor anywhere and everywhere (when deleting
characters makes sense, that is.  You don't want to delete
characters on a webpage displayed by a webbrowser,
for example).  That's natural for a person like me
who instinctively types C-h to delete.

I used to use

 (global-set-key "\C-h" 'delete-backward-char)

instead of keyboard-translate.  But, as of emacs23, C-h invokes
a help-like feature in the incremental search even with the
setting above.

So, I think keyboard-translate is the cleanest,
once-and-for-all solution, if it works globally.

Best regards,
Ryo

bug#4709: 23.1; keyboard-translate not working with emacs daemon

[Stefan Monnier]

> | AFAIK, you cannot set it globally.
> Then, could we make it a request for a new feature?

Sure.

> We could even say that the keyboard-translate functionality
> is partially broken because it sometimes works and sometimes
> doesn't (Please recall my example).

To tell you the truth, it's the first time I hear of this feature being
actually used.  So that should give you the kind of priority this
feature request will "enjoy".  And of course it gets worse because of
the discussion below.

> | Still, I wonder: why would you want to set such a mapping
> | everywhere?
> I'm not sure if I understand your question. . . .  If you want
> a keyboard translation, you'd want it everywhere consistently,
> wouldn't you?
> In this particular case, I want C-h to delete the character
> before the cursor anywhere and everywhere (when deleting
> characters makes sense, that is.

But do you really also want C-x C-h to invoke the command bound
to C-x C-? 

> You don't want to delete characters on a webpage displayed by
> a webbrowser, for example).  That's natural for a person like me who
> instinctively types C-h to delete.

> I used to use
>  (global-set-key "\C-h" 'delete-backward-char)

That seems closer to what you want, yes.  But admittedly, C-h is
hardwired at many places, so you'd have to "fix" them one by one as you
bump into them.

> So, I think keyboard-translate is the cleanest,
> once-and-for-all solution, if it works globally.

Have you tried key-translation-map (which is global)?
I have never understand the existence of both key-translation-map and
keyboard-translate-table.


        Stefan

bug#4709: 23.1; keyboard-translate not working with emacs daemon

[Ryo Furue]

Stefan,

| > We could even say that the keyboard-translate functionality
| > is partially broken because it sometimes works and sometimes
| > doesn't (Please recall my example).
| 
| To tell you the truth, it's the first time I hear of this feature
| being actually used.  So that should give you the kind of priority
| this feature request will "enjoy".

I understand.  It's you developers who decide on priority.
All I can do is just to ask.  But, please google and
you'll find that keyboard translation is often suggested
as a solution to the "C-h" problem.  When I raised this
issue in gnu.emacs.help, there was another person who
was suffering from the lack of a truly global keyboard
translation.  I also found a posting on the net asking
the same question as mine (why doesn't keyboard translation
work with emacs daemon?).  For a user using a "strange"
keyboard (see below), keyboard translation is the cleanest
solution.  Finally, it's not good for emacs to leave
a feature broken.  Once you offer a feature, SOMEBODY
(like me) will use it even though YOU personally don't
think it's useful.

| And of course it gets worse because of
| the discussion below.
| 
| > | Still, I wonder: why would you want to set such a mapping
| > | everywhere?
| > I'm not sure if I understand your question. . . .  If you want
| > a keyboard translation, you'd want it everywhere consistently,
| > wouldn't you?
| > In this particular case, I want C-h to delete the character
| > before the cursor anywhere and everywhere (when deleting
| > characters makes sense, that is.
| 
| But do you really also want C-x C-h to invoke the command bound
| to C-x C-?

I've never been faced with such a situation.  But, if there is
ever such a situation, my answer must be "Yes, I would want C-x
C-h to invoke the command bound to C-x C-?".  Because the delete
key does "not exist" to me!

1) My delete key doesn't work in the first place.  I don't know
  what's wrong but it doesn't do anything on the bash prompt,
  for example, and it doesn't delete the character before the cursor
  on emacs (A message "End of Buffer" appears in the message line).

2) My delete key isn't easily accessible.  On my regular keyboards,
  it's only accessible by pressing a "fn" key and "~`" key at the
  same time; it's really awkward to type.

3) I can't press it on my other keyboard without looking for it.
   It's too far from the home position.

These things have been fine with me because I've never needed
the delete key.

The delete key exists as a physical entity but, considering the
situation above, you'll agree that it's as good as non-existent
to me.  So, if faced with a need for such a combination
as "C-x C-?", I would choose to use "C-x C-h".

| > I used to use
| >  (global-set-key "\C-h" 'delete-backward-char)
| 
| That seems closer to what you want, yes.  But admittedly, C-h is
| hardwired at many places, so you'd have to "fix" them one by one as
| you bump into them.

I agree that that's doable.  But, as I said (and as you seem
to admit), it's not the cleanest solution, especially for a user
like me who doesn't have a delete key in the first place :-)

| > So, I think keyboard-translate is the cleanest,
| > once-and-for-all solution, if it works globally.
| 
| Have you tried key-translation-map (which is global)?
| I have never understand the existence of both key-translation-map
| and keyboard-translate-table.

I've never heard of it.  I'll investigate.  Thank you for the
suggestion.

Regards,
Ryo

bug#4709: 23.1; keyboard-translate not working with emacs daemon

[Stefan Monnier]

> All I can do is just to ask.  But, please google and
> you'll find that keyboard translation is often suggested
> as a solution to the "C-h" problem.

I know about that.  But this is usually not a problem of keyboard, but
a problem of configuration of the xterm (or whatever other terminal
emulator is used).  So the answer (to use keyboard-translation) is
actually a bad answer, simply carried over from the years long past
where people used real text terminals where it was the only answer.
Nowadays, the right answer is to fix the xterm's config so that DEL
(aka "backspace") is not confused with C-h.

IOW, these are not uses but misuses of keyboard-translate.

> When I raised this
> issue in gnu.emacs.help, there was another person who
> was suffering from the lack of a truly global keyboard
> translation.  I also found a posting on the net asking
> the same question as mine (why doesn't keyboard translation
> work with emacs daemon?).  For a user using a "strange"
> keyboard (see below), keyboard translation is the cleanest
> solution.

Usually the way key presses get presented to Emacs depends a lot on
whether they come straight from X11/w32/ns for GUI frames, or from some
terminal emulator.  This is especially true for delete and backspace
keys.  So global settings are usually not the right answer.

> | But do you really also want C-x C-h to invoke the command bound
> | to C-x C-?

> I've never been faced with such a situation.  But, if there is
> ever such a situation, my answer must be "Yes, I would want C-x
> C-h to invoke the command bound to C-x C-?".  Because the delete
> key does "not exist" to me!

Good, then global-set-key is not the right answer.

> 1) My delete key doesn't work in the first place.  I don't know
>   what's wrong but it doesn't do anything on the bash prompt,
>   for example, and it doesn't delete the character before the cursor
>   on emacs (A message "End of Buffer" appears in the message line).

That looks like a problem in itself which you may want to fix.
What does C-h k <your delete key here> say?

> 2) My delete key isn't easily accessible.  On my regular keyboards,
>   it's only accessible by pressing a "fn" key and "~`" key at the
>   same time; it's really awkward to type.

Hmm... you're mapping C-h to C-? which is called DEL but which is really
the "backspace" key, not the "delete" key (tho there's been a lot of
confusion around this over the years since the terms were not used
consistently between keyboard manufacturers).  I.e. it's the key that
normally sits at the extreme right of the row which has the numbers
(the "top" row, if you ignore F1, F2, ... and such things).

The "delete" key (which deletes forward rather than backward), is
often placed together with things like "home", "end", "insert", "page
up" and "page down".  On Macs, IIRC, the delete key is only accessible
via some Fn combination.

So which physical key do you mean here?

> 3) I can't press it on my other keyboard without looking for it.
>    It's too far from the home position.

Clearly, not a key you want to use, yes.

> These things have been fine with me because I've never needed
> the delete key.

I never use the delete key either, basically (C-d is a lot more
convenient to delete forward).  I do you use the backspace key
heavily, tho.

> The delete key exists as a physical entity but, considering the
> situation above, you'll agree that it's as good as non-existent
> to me.  So, if faced with a need for such a combination
> as "C-x C-?", I would choose to use "C-x C-h".

That's good, yes.  It means that some form of keyboard-translation is
the right answer.

> | > So, I think keyboard-translate is the cleanest,
> | > once-and-for-all solution, if it works globally.
> | Have you tried key-translation-map (which is global)?
> | I have never understand the existence of both key-translation-map
> | and keyboard-translate-table.
> I've never heard of it.  I'll investigate.  Thank you for the
> suggestion.

The invocation below:

   (define-key key-translation-map [?\C-h] [?\C-?])

should do the trick.


        Stefan

bug#4709: 23.1; keyboard-translate not working with emacs daemon

[Ryo Furue]

Hi Stefan,

Thank you.  You are so kind and patient.

| [. . . keyboard-translate is an obsolete feature . . .]
| 
OK.

Now, I'm totally confused about the so-called "delete" key.
My original problem was that I want to delete the character
before the cursor with C-h .  I thought emacs originally assigns
it to the "delete" key.  But, it seems there's a confusion
in terminology.  You see, I'm so ignorant about those "special"
keys :-) because I don't usually use them except for ESC
(which sits next to "1/!"), TAB, CTRL (which sits next to "A"),
and SHIFT.  I can't type arrow keys, BACKSPACE, ALT, or DELETE,
without searching for them, looking at the keyboard.

| > 1) My delete key doesn't work in the first place.  I don't know
| >   what's wrong but it doesn't do anything on the bash prompt,
| >   for example, and it doesn't delete the character before the cursor
| >   on emacs (A message "End of Buffer" appears in the message line).
| 
| That looks like a problem in itself which you may want to fix.
| What does C-h k <your delete key here> say?

The answer was surprising to me:

  C-d (translated from <delete>) runs the command delete-char, which is
  an interactive built-in function in `C source code'.

  It is bound to <deletechar>, C-d.

I don't know who translates my "delete" to C-d.  But, I've just
found that it does what C-d does.

I've also found that my BACKSPACE key seems to be what emacs
calls DEL:

  DEL (translated from <backspace>) runs the command
  backward-delete-char-untabify, which is an interactive compiled Lisp
  function.

  It is bound to DEL.

(By the way, I obtained these results on "/usr/bin/emacs23 -q", so
 they are not affected by my ~/.emacs .)

So . . . for so many years, I've had the wrong notion that emacs
used the DELETE key (the one below "Insert" and to the left of "End"
on a Dell keyboard which I don't use but happen to find here) to
delete the character before the cursor.  Because of this
misunderstanding, I was confusing you, I suppose.  Sorry.

In any case, my problem stands the same because I don't use
BACKSPACE either (and I'd like to avoid it, if at all
possible).

| The invocation below:
| 
|    (define-key key-translation-map [?\C-h] [?\C-?])
| 
| should do the trick.

Thank you very much for finding that out!  That's much
better than keyboard-translate:

$ emacs --daemon
$ emacsclient -c
 # key-translation is NOT effective.
 # Evaluate (define-key key-translation-map [?\C-h] [?\C-?]).
 # Exit.
$ emacsclient -c
 # key-translation IS effective.
$ emacsclient -c -nw
 # key-translation IS effective.

As you can see, the emacs daemon seems to ignore it
in your ~/.emacs and you still have to manually
evaluate it on an emacsclient.  But, once you've evaluated
it, it seems to stick.  That's a huge improvement.

Since my emacs daemon is sitting on my desktop for many
days, I can live with the current situation.  Maybe
in the future, I hope the emacs daemon recognizes
key-translation-map in ~/.emacs.

Thank you again for your help.

Regards,
Ryo

bug#4709: 23.1; keyboard-translate not working with emacs daemon

[Stefan Monnier]

> | [. . . keyboard-translate is an obsolete feature . . .]
> OK.

Actually, it hasn't been declared obsolete.  But the typical uses for it
(to work around `backspace' sending a C-h) are.  I've already several
times been tempted to declare it obsolete, but haven't resolved myself
to it yet.

> The answer was surprising to me:
>   C-d (translated from <delete>) runs the command delete-char, which is
>   an interactive built-in function in `C source code'.
>   It is bound to <deletechar>, C-d.
> I don't know who translates my "delete" to C-d.  But, I've just
> found that it does what C-d does.

It's done via function-key-map by normal-erase-is-backspace-mode.

> I've also found that my BACKSPACE key seems to be what Emacs
> calls DEL:
>   DEL (translated from <backspace>) runs the command
>   backward-delete-char-untabify, which is an interactive compiled Lisp
>   function.
>   It is bound to DEL.
> (By the way, I obtained these results on "/usr/bin/emacs23 -q", so
>  they are not affected by my ~/.emacs .)

Yes, these results look just fine to me.

> | The invocation below:
> |    (define-key key-translation-map [?\C-h] [?\C-?])
> | should do the trick.
> Thank you very much for finding that out!  That's much
> better than keyboard-translate:

Other than the fact that it works globally, I'm not sure that it is
better, but it should hopefully work about as well.

> As you can see, the emacs daemon seems to ignore it
> in your ~/.emacs and you still have to manually
> evaluate it on an emacsclient.

That doesn't sound right.  Can you check that the relevant code from
your .emacs is indeed executed?  E.g. add a (message "I'm here") and/or
a (setq my-test 'passed) right after the define-key.


        Stefan

bug#4709: 23.1; keyboard-translate not working with emacs daemon

[Ryo Furue]

Hi Stefan,

| > As you can see, the emacs daemon seems to ignore it
| > in your ~/.emacs and you still have to manually
| > evaluate it on an emacsclient.
| 
| That doesn't sound right.  Can you check that the relevant code from
| your .emacs is indeed executed?  E.g. add a (message "I'm here") and/or
| a (setq my-test 'passed) right after the define-key.

Thank you for debugging my problem and I'm sorry that that was
purely my mistake.  I was forgetting that I had a byte-compiled
version of .emacs !

So, by (define-key key-translation-map . . .), my original problem
has been solved.  I'll report this back to gnu.emacs.help .

The following is a digression.

I normally don't byte-compile my stuff and when I did it,
I didn't pay much attention to it because I had the misconception
that the newer is used if both .el and .elc are found.
I just byte-compiled it "from time to time".

I hadn't been interested in byte compilation before emacs23
because the startup of emacs22 (and emacs21 if I remember
correctly) was lightening quick.  emacs23's startup,
on the other hand, is crawlingly slow.  That's why
I tried byte-compilation (but that didn't help much)
and then the emacs daemon (which is a nice solution).

Regarding byte compilation, I found these conversations:

http://curiousprogrammer.wordpress.com/2009/03/04/compiling-at-emacs-startup/
http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2577

I understand there are two schools of thoughts:

1) The byte compiled version is a stable version
   and the source is a work in progress.  Therefore,
   the byte compiled version should be used.

2) The byte compiled version is just a faster version
   of the source.  Therefore, whichever is the newer
   should be used.

My guess is that view 1 is generally taken by elisp
developers and so that's the default behavior of emacs.
I guess most "ordinary" users would take View 2; they
don't have much elisp code in progress.  I'm wondering
if there is a simple way to switch between the two
behaviors easily and quickly.

Anyway, thank you again for your great help.

Best regards,
Ryo

bug#4709: 23.1; keyboard-translate not working with emacs daemon

[Stefan Monnier]

> | That doesn't sound right.  Can you check that the relevant code from
> | your .emacs is indeed executed?  E.g. add a (message "I'm here") and/or
> | a (setq my-test 'passed) right after the define-key.

> Thank you for debugging my problem and I'm sorry that that was
> purely my mistake.  I was forgetting that I had a byte-compiled
> version of .emacs !

Good, thanks.

> I hadn't been interested in byte compilation before emacs23
> because the startup of emacs22 (and emacs21 if I remember
> correctly) was lightening quick.  emacs23's startup,
> on the other hand, is crawlingly slow.  That's why
> I tried byte-compilation (but that didn't help much)
> and then the emacs daemon (which is a nice solution).

Emacs-23 is known to be generally slower because of the new font-engine
which considers many more font options at startup, but it is not
expected to be as much slower as you seem to indicate.  So maybe
a bug-report about it is in order.

> I understand there are two schools of thoughts:

> 1) The byte compiled version is a stable version
>    and the source is a work in progress.  Therefore,
>    the byte compiled version should be used.

> 2) The byte compiled version is just a faster version
>    of the source.  Therefore, whichever is the newer
>    should be used.

> My guess is that view 1 is generally taken by elisp
> developers and so that's the default behavior of emacs.
> I guess most "ordinary" users would take View 2; they
> don't have much elisp code in progress.  I'm wondering
> if there is a simple way to switch between the two
> behaviors easily and quickly.

No there isn't.  Please make it a separate M-x report-emacs-bug if you
want such a feature.


        Stefan

bug#4709: 23.1; keyboard-translate not working with emacs daemon

[Glenn Morris]

Stefan Monnier wrote:

> No there isn't.  Please make it a separate M-x report-emacs-bug if you
> want such a feature.

Please don't, since we already have such a wishlist item:

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2061