Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

bug#12174: 24.1.50; C-h f and non-symbol remap targets

19 views
Skip to first unread message

Christopher Schmidt

unread,
Aug 10, 2012, 5:55:42 PM8/10/12
to 12...@debbugs.gnu.org
(global-set-key [remap write-file] (lambda () (interactive) 'rms))
C-h f write-file RET

This yields in an error because help-fns--key-bindings expects
(command-remapping 'write-file) to be a symbol.

Here is a patch that abbreviates non-symbol remap targets with "??".
This is consistent with what describe-bindings displays.
help-fns--key-bindings.diff

Christopher Schmidt

unread,
Aug 14, 2012, 2:12:38 PM8/14/12
to 12...@debbugs.gnu.org
Christopher Schmidt <chris...@ch.ristopher.com> writes:
> Here is a patch that abbreviates non-symbol remap targets with "??".
> This is consistent with what describe-bindings displays.

A sobering thought - ?? does not need to be quoted.
help-fns--key-bindings-2.diff

Stefan Monnier

unread,
Aug 14, 2012, 10:38:10 PM8/14/12
to 12...@debbugs.gnu.org
>> Here is a patch that abbreviates non-symbol remap targets with "??".
>> This is consistent with what describe-bindings displays.
> A sobering thought - ?? does not need to be quoted.

Actually, ?? is a bad choice, since it seems to imply that Emacs doesn't
even know what it's remapped to, whereas Emacs does know very well, it
just doesn't want to print it out in full because it would be ugly and
too verbose.
So I suggest we replace "??" with something like "an anonymous command".


Stefan



Christopher Schmidt

unread,
Aug 15, 2012, 4:33:41 AM8/15/12
to 12...@debbugs.gnu.org
help-fns--key-bindings-3.diff

Glenn Morris

unread,
Aug 22, 2012, 3:02:16 AM8/22/12
to 12174...@debbugs.gnu.org
Version: 24.3

Thanks; applied to trunk.



Dani Moncayo

unread,
Aug 22, 2012, 3:21:40 AM8/22/12
to 12...@debbugs.gnu.org, r...@gnu.org
On Wed, Aug 22, 2012 at 9:02 AM, Glenn Morris <r...@gnu.org> wrote:
> Version: 24.3

One question: If some other severe bug arises upon the (not yet)
released Emacs 24.2, so that a 24.3 release becomes necessary (from
the emacs-24 branch), then the above tag will be incorrect, won't it?

It seems that the current versioning pattern has this problem. We
don't know beforehand the version under which the current trunk code
will be released.

So, what about switching to a different pattern which doesn't have this problem?

For example: Name the next trunk's branch as "emacs-24.3", and every
release made from that branch would be labeled "emacs 24.3.x".

This way, we would know for sure that the trunk code would be released
as version "24.4" (or "25.1" -- what the maintainer's decide).

--
Dani Moncayo



Glenn Morris

unread,
Aug 22, 2012, 3:24:05 AM8/22/12
to Dani Moncayo, 12...@debbugs.gnu.org
Dani Moncayo wrote:

> On Wed, Aug 22, 2012 at 9:02 AM, Glenn Morris <r...@gnu.org> wrote:
>> Version: 24.3
>
> One question: If some other severe bug arises upon the (not yet)
> released Emacs 24.2, so that a 24.3 release becomes necessary (from
> the emacs-24 branch), then the above tag will be incorrect, won't it?

Yes, it's a (minor) problem. I suggest discussing it on emacs-devel
rather than here though.



0 new messages