From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Weiner Newsgroups: gmane.emacs.orgmode,gmane.emacs.devel Subject: Re: Key binding popup interface Date: Wed, 13 Dec 2017 11:25:34 -0500 Message-ID: References: <87r2s3ctxh.fsf@ericabrahamsen.net> <87d13m3jt2.fsf@gmx.us> <87efo2wf0s.fsf@ericabrahamsen.net> <87y3m8s7ym.fsf@gmx.us> <87fu8gwfbr.fsf@nicolasgoaziou.fr> <87k1xs2h0h.fsf@gmx.us> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114c95865f689505603b39d5" X-Trace: blaine.gmane.org 1513182400 23822 195.159.176.226 (13 Dec 2017 16:26:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 13 Dec 2017 16:26:40 +0000 (UTC) Cc: Oleh Krehel , emacs-org list , Stefan Monnier , emacs-devel To: Kaushal Modi Original-X-From: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Wed Dec 13 17:26:36 2017 Return-path: Envelope-to: geo-emacs-orgmode@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eP9re-0005t6-Js for geo-emacs-orgmode@m.gmane.org; Wed, 13 Dec 2017 17:26:34 +0100 Original-Received: from localhost ([::1]:36198 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eP9rl-0002p6-JQ for geo-emacs-orgmode@m.gmane.org; Wed, 13 Dec 2017 11:26:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eP9rH-0002oz-RR for emacs-orgmode@gnu.org; Wed, 13 Dec 2017 11:26:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eP9rC-0002VR-ML for emacs-orgmode@gnu.org; Wed, 13 Dec 2017 11:26:11 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39480) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eP9rC-0002V5-I5; Wed, 13 Dec 2017 11:26:06 -0500 Original-Received: from mail-qk0-f180.google.com ([209.85.220.180]:43567) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1eP9rB-0006jT-Sb; Wed, 13 Dec 2017 11:26:06 -0500 Original-Received: by mail-qk0-f180.google.com with SMTP id j207so2645261qke.10; Wed, 13 Dec 2017 08:26:05 -0800 (PST) X-Gm-Message-State: AKGB3mJVnmLxSZpkL4O0Cw4CytLCGx8H+hnTsvUBAdje0qZ7+gS+kEfZ E00G2qZ+SPmtCggY+QvxadoZjOry8gimVqVLc5o= X-Google-Smtp-Source: ACJfBos9oJQ5xu9IQ/xGvUTpXsAJiMqpoL5KPTvKsOUdpbINJqpYL75Y3ZbjHjP6knO8xqPjqcXyRThwovPw3Wm84KI= X-Received: by 10.55.5.143 with SMTP id 137mr7897949qkf.231.1513182365442; Wed, 13 Dec 2017 08:26:05 -0800 (PST) Original-Received: by 10.200.55.124 with HTTP; Wed, 13 Dec 2017 08:25:34 -0800 (PST) In-Reply-To: X-Gmail-Original-Message-ID: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Original-Sender: "Emacs-orgmode" Xref: news.gmane.org gmane.emacs.orgmode:117490 gmane.emacs.devel:221007 Archived-At: --001a114c95865f689505603b39d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 13, 2017 at 10:40 AM, Kaushal Modi wrote: > On Tue, Dec 12, 2017 at 6:51 PM Robert Weiner wrote: > >> >> =E2=80=8BOne limitation of hydra right now is that it doesn't interface = with the >> standard way of showing help for key bindings since its keys aren't >> actually bound but handled via internal hydra event handling. With a bi= t >> of thought though, I think it could be integrated well. >> > > I don't follow what the functional limitations are of what you said. How > does your concern affect a package author or the end user? > =E2=80=8BC-h k shows the documentation for a key binding in a help buffer r= ather than just a laid out summary of all the keys in a particular hydra map. C-h k is important to know the details of what individual keys do, so hydra needs a way of integrating with standard key documentation lookup capabilities if it gets integrated with core Emacs, which I would like to see. Personally, I also think the red, blue, etc. color notation should change t= o something more descriptive of what they do and then the particular colors associated could be customized to suit any particular visual theme. Bob --001a114c95865f689505603b39d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 13, 2= 017 at 10:40 AM, Kaushal Modi <kaushal.modi@gmail.com> wrote:
On Tue, Dec 12, 2017 at= 6:51 PM Robert Weiner <rsw@gnu.org> wrote:

=E2=80=8BOne limitation of hydra ri= ght now is that it doesn't interface with the standard way of showing h= elp for key bindings since its keys aren't actually bound but handled v= ia internal hydra event handling.=C2=A0 With a bit of thought though, I thi= nk it could be integrated well.
I don't follow what the functional limitations are = of what you said. How does your concern affect a package author or the end = user?

=E2=80=8BC-h k shows the= documentation for a key binding in a help buffer rather
than just a laid = out summary of all the keys in a particular hydra map.
C-h k is important = to know the details of what individual keys do, so
hydra needs a way of in= tegrating with standard key documentation lookup
capabilities if it gets i= ntegrated with core Emacs, which I would like to see.

Personally, I = also think the red, blue, etc. color notation should change to
something m= ore descriptive of what they do and then the particular colors
associated = could be customized to suit any particular visual theme.

Bob

--001a114c95865f689505603b39d5--