From: Stefan Kangas <stefan@marxist.se>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Mohammed Sadik <sadiqpkp@gmail.com>, 24224-done@debbugs.gnu.org
Subject: bug#24224: Enable 'h, j, k, l' key navigation where ever possible
Date: Thu, 1 Oct 2020 05:38:30 -0700 [thread overview]
Message-ID: <CADwFkmnsV6O=oOZ8ptFr2TieyhcYC9ytbc_gb-ht=d9ec1ftFQ@mail.gmail.com> (raw)
In-Reply-To: <CADwFkmkFTC3+xfsy_jNk19uxpJ8QEeTGhhO99m2TiQ-a7DYu1A@mail.gmail.com> (Stefan Kangas's message of "Sat, 22 Aug 2020 14:45:05 -0400")
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.
prev parent reply other threads:[~2020-10-01 12:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-14 6:52 bug#24224: Enable 'h, j, k, l' key navigation where ever possible Mohammed Sadik
2016-08-14 17:24 ` Eli Zaretskii
2016-08-14 18:10 ` npostavs
2020-08-22 18:45 ` Stefan Kangas
2020-10-01 12:38 ` Stefan Kangas [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CADwFkmnsV6O=oOZ8ptFr2TieyhcYC9ytbc_gb-ht=d9ec1ftFQ@mail.gmail.com' \
--to=stefan@marxist.se \
--cc=24224-done@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=sadiqpkp@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.