Making ^J and ^H work in / (search)

Dmitry Alexandrov 321942 at
Fri Jul 1 00:08:54 CEST 2016

Alexander Berntsen <alexander at> writes:

> On 30/06/16 23:03, Dmitry Alexandrov wrote:
>> Sorry, I’ve missed *when* did you try this suggestion (to use
>> ‘key-translation-map’).
> This is what I get for answering email in a hurry. (Twice!)
> Your suggestion works perfectly. Thank you. And double thank you for
> your patience in pointing out that I misread. (Twice!)

You are welcome.  :-)

Now about flies in the ointment.  Being a more low-level thing than
‘global-map’, ‘key-translation-map’ acts not on a whole key sequence,
but rather on every single key chord.  I. e. it affects not only ‘C-h’
and ‘C-j’ on their own, but also, for instance, ‘C-x C-h’ or ‘C-c C-j’
whatever and wherever they mean.

There is should not be any practical problem with ‘C-h’, since it almost
everywhere stands for ‘help’ and has ‘<f1>’ as a synonym.  But if you’ll
stick to ‘C-j’ mapped to ‘C-m’ / ‘RET’, you have to sort it out
somehow.  The laziest way is just to use ‘C-S-j’ (‘S’ stands for
shift) whenever the ‘real’ ‘C-j’ is required.

But I have to repeat that I would not consider giving up ‘C-j’ even on
its own a good idea — it is very useful to have ‘dumb’ and ‘smart’
return keys, at least for any sort of auto-completion — smart one
selects the most relevant completion, while dumb one applies exactly
what you’ve typed.  (Which chord is dumb and which is smart depends on
personal preference — there is no consistency through GNU Emacs
packages, for example in ‘icomplete’ ‘C-j’ is smart by default and ‘C-m’
/ ‘RET’ is dumb, while in ‘ido’ — exactly the way around.)

More information about the implementations-list mailing list