[Top][All Lists]

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

Re: Key-binding clash between gnus and calc

From: Sascha Wilde
Subject: Re: Key-binding clash between gnus and calc
Date: Thu, 17 Nov 2005 10:51:19 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Miles Bader <address@hidden> wrote:

> 2005/11/17, Juri Linkov <address@hidden>:
>> I doubt that `M-#' in gnus is used too much, because it has one
>> inconvenience which is not fixed for a long time.  Unlike `#' which
>> advances to the next article, `M-#' stays on the same article.
> Unmarking commands in Gnus follow a fairly regular pattern -- if key
> "foo" marks, then "M-foo" unmarks.  This correspondence is _extremely_
> useful, because one uses unmarking commands more rarely than the
> corresponding marking command, so a regular naming convention makes it
> easy to remember what they're bound to.

I agree, that the correspondence is quite use full, but I also do
agree with Juri, that the slightly different behavior of M-# is
extremely inconvenient.  IMO this should be fixed, by making M-#
advance to (like M-u does!).

>> There is another key binding in gnus that conflicts with the global
>> key binding.  It is `M-g'.
> Yeah, so what?  Another notable non-tragedy.

I agree, in this special case, that it is not tragic:

  Global Bindings Starting With M-g:
  key             binding
  ---             -------

  M-g p           previous-error
  M-g n           next-error
  M-g g           goto-line
  M-g ESC         Prefix Command

  M-g M-p         previous-error
  M-g M-n         next-error
  M-g M-g         goto-line

previous-error and next-error just don't make any sense in gnus.  (In
fact, I'm not sure why they are global bindings anyway.)  And
goto-line isn't particularly use full in gnus buffers either.

BUT, in general I think, that Emacs as a whole should be as consistent
as possible.  That is one reason why global bindings should be
approved by Richard, and I thin that is a good thing[tm]. ;-)


reply via email to

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