Gnus development mailing list
 help / color / mirror / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: jidanni@jidanni.org, 7727debbugs.gnu.org@pastel.home,
	yamaoka@jpl.org, bug-gnu-emacs@gnu.org, ding@gnus.org
Subject: Re: bug#7727: describe-key doesn't tell whole redirect sequence
Date: Mon, 24 Jan 2011 22:09:10 -0500	[thread overview]
Message-ID: <jwv62tdn1e6.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87aaiqota7.fsf@gnus.org> (Lars Ingebrigtsen's message of "Mon, 24 Jan 2011 14:01:36 -0800")

>> A cleaner could look like the following: add dynamic keymaps to Emacs,
>> where "dynamic keymaps" are represented as functions/objects a bit like
>> functional completion tables.
> Hm...  how would that work?

> The complicated run-summary-commands-from-the-article-buffer thing is
> quite, er, complicated, because some commands need to keep the window
> conf, while others shouldn't, and stuff.

I haven't worked it out, so I can't really answer.  In PCL-CVS I had
a similar situation, except that I used a prefix key, so <prefix> <key>
in a derived buffer would call the command bound to <prefix> in the main
buffer, so I didn't need to play tricks with the keymap.  But I had to
make the commands themselves work in "any" buffer, and indeed, that had
to be done differently for each command.

How would the dynamic keymap enter the picture: rather than substitute
"undefined => gnus-article-read-summary-keys" and fool around
describe-key and friends, you'd set article-mode's parent keymap to
a dynamic keymap, i.e. a function that takes the current key as argument
and needs to return the command to which this key is bound (or nil), so
this function can lookup summary mode's keymap and return a command that
performs <summary-command> but that works from the article buffer.
You can do this last step either by making all summary command work in
the article buffer (as I did in PCL-CVS) or by dynamically wrapping the
command into a new command (which would do something similar to
gnus-article-read-summary-keys, except it takes the <summary-command>
as argument rather than a key-sequence).

The main benefit is that the keymapping is made clear to describe-key,
so you wouldn't need gnus-article-describe-key and friends.  Of course,
all this is hypothetical since we don't have dynamic keymaps.
As for me, the main reason why I want dynamic keymaps is for use in
function-key-map where I'd move most of the "fallback" thingies from
read-key-sequence (e.g. A => a, double-mouse-2 => mouse-2, down-mouse-2
=> nil, ...) and where we could place generic remappings like "any
modifiers + mouse-4 => same modifiers + wheel-up".


        Stefan



  reply	other threads:[~2011-01-25  3:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-24  2:40 (put 'gnus-summary-edit-article 'disabled t) doesn't work in *Article* buffer jidanni
2010-12-24 12:00 ` Katsumi Yamaoka
2010-12-24 15:22   ` describe-key doesn't tell whole redirect sequence jidanni
2011-01-02  5:58     ` Lars Magne Ingebrigtsen
2011-01-23  0:02     ` bug#7727: " Chong Yidong
2011-01-23  1:19       ` Lars Ingebrigtsen
2011-01-24  1:04     ` Lars Ingebrigtsen
2011-01-24  1:24       ` Lars Ingebrigtsen
2011-01-24 16:31         ` bug#7727: " Stefan Monnier
2011-01-24 22:01           ` Lars Ingebrigtsen
2011-01-25  3:09             ` Stefan Monnier [this message]
2011-01-25  9:31               ` Lars Ingebrigtsen

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=jwv62tdn1e6.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=7727debbugs.gnu.org@pastel.home \
    --cc=bug-gnu-emacs@gnu.org \
    --cc=ding@gnus.org \
    --cc=jidanni@jidanni.org \
    --cc=larsi@gnus.org \
    --cc=yamaoka@jpl.org \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).