all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.





      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.