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

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

bug#24224: Enable 'h, j, k, l' key navigation where ever possible


From: Stefan Kangas
Subject: bug#24224: Enable 'h, j, k, l' key navigation where ever possible
Date: Thu, 1 Oct 2020 05:38:30 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Stefan Kangas <stefan@marxist.se> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Mohammed Sadik <sadiqpkp@gmail.com>
>>> Date: Sun, 14 Aug 2016 12:22:38 +0530
>>>
>>> There are several buffers where alphabet keys have no effect.
>>> In such buffers, it would be nice to enable the keys h, j, k, and l, for
>>> navigation, and even further q for quit (or close the buffer), o for
>>> other window, etc.  This might also help resolve the pinky problem a little.
>>>
>>> The buffers that can include those key for navigation can be
>>> help-mode, apropos-mode, woman, package-menu-mode (package listings),
>>> compilation-mode, customize (Custom-mode), info-mode, and so on.
>>
>> Some of these keys are already bound in some of these modes.  For
>> example, h and l have bindings in help-mode.
>>
>> So I guess this could be some optional minor mode, off by default.
>
> (That was 4 years ago.)
>
> The request is to bind 'h', 'j', 'k' and 'l' where possible, presumably
> to be more like vim.  I think this use case is mostly covered by viper
> and/or the third-party evil.
>
> Eli pointed out that this would conflict with current key bindings, and
> I can only add that it would not be worth usurping these key bindings
> everywhere when we already have 'f', 'b', 'n' and 'p'.
>
> Eli also suggested that this could be an optional minor mode.  I don't
> see why we couldn't include such a package in GNU ELPA, but I don't
> think it makes sense to keep a request like this open in our bug tracker
> indefinitely if no one is actively working on it.
>
> Any other opinions?  And is anyone working on this?

No further comments within almost 6 weeks, so I'll assume that there are
no objections to the above.  I'm therefore closing this bug now.





reply via email to

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