bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ryo Furue
Subject: bug#4709: 23.1; keyboard-translate not working with emacs daemon
Date: Wed, 14 Oct 2009 21:34:55 -1000 (HST)

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]