Making ^J and ^H work in / (search)
Dmitry Alexandrov
321942 at gmail.com
Fri Jul 1 00:08:54 CEST 2016
Alexander Berntsen <alexander at plaimi.net> 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