Hi Robert,
Ar an cúigiú lá de mí Méan Fómhair, scríobh Robert Pluim:
> did this [remap] syntax in define-key do anything before? Because after
> this commit eg the latest gnus message.el is failing, since that does a
> [remap] using a function that has not been defined yet:
>
> (define-key message-mode-map [remap split-line] 'message-split-line)
>
> with message-split-line defined later in the file. This causes 'commandp'
> to throw an error.
Right. My implementation isn’t entirely compatible with GNU’s, but it
certainly needs to be compatible with it in the common stuff; thanks for the
pointer, I’ve committed the below to address it.
APPROVE COMMIT
NOTE: This patch has been committed
# HG changeset patch
# User Aidan Kehoe <kehoea(a)parhasard.net>
# Date 1346873878 -3600
# Node ID 4af5a3435c94358798bcd2e56c51eaebbc5f36d2
# Parent 8a2ac78cb97d31a39208d1c6c5081477daac61eb
Don't sanity-check commands with (define-key KEYMAP [remap COMMAND1] COMMAND2).
lisp/ChangeLog addition:
2012-09-05 Aidan Kehoe <kehoea(a)parhasard.net>
* keymap.c:
* keymap.c (Fdefine_key):
* keymap.c (remap_command):
* keymap.c (Fremap_command):
Don't sanity-check commands to be remapped with the (define-key
KEYMAP [remap COMMAND1] COMMAND2) syntax, for better compatibility
with GNU Emacs. Thank you Robert Pluim!
diff -r 8a2ac78cb97d -r 4af5a3435c94 src/ChangeLog
--- a/src/ChangeLog Sun Sep 02 17:36:47 2012 +0100
+++ b/src/ChangeLog Wed Sep 05 20:37:58 2012 +0100
@@ -1,3 +1,13 @@
+2012-09-05 Aidan Kehoe <kehoea(a)parhasard.net>
+
+ * keymap.c:
+ * keymap.c (Fdefine_key):
+ * keymap.c (remap_command):
+ * keymap.c (Fremap_command):
+ Don't sanity-check commands to be remapped with the (define-key
+ KEYMAP [remap COMMAND1] COMMAND2) syntax, for better compatibility
+ with GNU Emacs. Thank you Robert Pluim!
+
2012-09-02 Aidan Kehoe <kehoea(a)parhasard.net>
* regex.c (re_search_2):
diff -r 8a2ac78cb97d -r 4af5a3435c94 src/keymap.c
--- a/src/keymap.c Sun Sep 02 17:36:47 2012 +0100
+++ b/src/keymap.c Wed Sep 05 20:37:58 2012 +0100
@@ -195,8 +195,9 @@
EXFUN (Fkeymap_fullness, 1);
EXFUN (Fset_keymap_name, 2);
EXFUN (Fsingle_key_description, 1);
-EXFUN (Fremap_command, 3);
-
+
+static Lisp_Object remap_command (Lisp_Object keymap, Lisp_Object old,
+ Lisp_Object new_);
static void describe_command (Lisp_Object definition, Lisp_Object buffer);
static void describe_map (Lisp_Object keymap, Lisp_Object elt_prefix,
void (*elt_describer) (Lisp_Object, Lisp_Object),
@@ -1939,12 +1940,6 @@
GCPRO3 (keymap, keys, def);
- /* Allow access to any keys named remap, use our uninterned symbol. */
- if (2 == len && VECTORP (keys) && EQ (Qremap, XVECTOR_DATA (keys) [0]))
- {
- return Fremap_command (keymap, XVECTOR_DATA (keys) [1], def);
- }
-
/* ASCII grunge.
When the user defines a key which, in a strictly ASCII world, would be
produced by two different keys (^J and linefeed, or ^H and backspace,
@@ -1958,6 +1953,13 @@
keymap = get_keymap (keymap, 1, 1);
+ /* Allow access to any keys named remap, use our uninterned symbol. For
+ compatibility, don't sanity-check (aref KEYS 1) or DEF. */
+ if (2 == len && VECTORP (keys) && EQ (Qremap, XVECTOR_DATA (keys) [0]))
+ {
+ RETURN_UNGCPRO (remap_command (keymap, XVECTOR_DATA (keys) [1], def));
+ }
+
idx = 0;
while (1)
{
@@ -2066,22 +2068,11 @@
}
}
-DEFUN ("remap-command", Fremap_command, 3, 3, 0, /*
-Ensure that NEW is called when previously OLD would be, in KEYMAP.
-
-NEW and OLD are both command symbols. KEYMAP is a keymap object.
-
-This is equivalent to `(define-key KEYMAP [remap OLD] NEW])'. See also
-`substitute-key-definition', an older way of doing a similar thing.
-*/
- (keymap, old, new_))
+static Lisp_Object
+remap_command (Lisp_Object keymap, Lisp_Object old, Lisp_Object new_)
{
+ Lisp_Key_Data parsed;
Lisp_Object cmd;
- Lisp_Key_Data parsed;
-
- keymap = get_keymap (keymap, 1, 1);
- CHECK_COMMAND (old);
- CHECK_COMMAND (new_);
define_key_parser (Qxemacs_command_remapping, &parsed);
cmd = keymap_lookup_1 (keymap, &parsed, 0);
@@ -2099,6 +2090,24 @@
return new_;
}
+
+DEFUN ("remap-command", Fremap_command, 3, 3, 0, /*
+Ensure that NEW is called when previously OLD would be, in KEYMAP.
+
+NEW and OLD are both command symbols. KEYMAP is a keymap object.
+
+This is equivalent to `(define-key KEYMAP [remap OLD] NEW])'. See also
+`substitute-key-definition', an older way of doing a similar thing.
+*/
+ (keymap, old, new_))
+{
+ keymap = get_keymap (keymap, 1, 1);
+ CHECK_COMMAND (old);
+ CHECK_COMMAND (new_);
+
+ return remap_command (keymap, old, new_);
+}
+
static Lisp_Object
command_remapping (Lisp_Object definition, int nmaps, Lisp_Object *maps)
{
--
‘Liston operated so fast that he once accidentally amputated an assistant’s
fingers along with a patient’s leg, […] The patient and the assistant both
died of sepsis, and a spectator reportedly died of shock, resulting in the
only known procedure with a 300% mortality.’ (Atul Gawande, NEJM, 2012)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
It looks like Emacs is going to deprecate outline-mode in favor of
org-mode. Getting org-mode into packages is looking more pressing.
Volunteers welcome. (I think Mats is already working on this.)
Steve
Karl Fogel writes on emacs-devel:
> Stefan Monnier <monnier(a)iro.umontreal.ca> writes:
> >or even make outline-mode into an alias for org-mode.
>
> +1
>
> At least, I never use plain outline mode anymore; org-mode seems to be
> the right superset.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
ACTIVITY SUMMARY (2012-08-28 - 2012-09-04)
XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
551 open ( +3) / 289 closed ( +0) / 840 total ( +3)
Open issues with patches: 13
Average duration of open issues: 1215 days.
Median duration of open issues: 1291 days.
Open Issues Breakdown
new 224 ( +3)
deferred 6 ( +0)
napping 3 ( +0)
verified 56 ( +0)
assigned 153 ( +0)
committed 19 ( +0)
documented 3 ( +0)
done/needs work 18 ( +0)
Issues Created Or Reopened (3)
______________________________
initial frame glitches 2012-09-01
http://tracker.xemacs.org/XEmacs/its/issue840 created stephen
Implement proper face inheritance 2012-09-01
http://tracker.xemacs.org/XEmacs/its/issue841 created stephen
Some parts of frame missed in redisplay 2012-09-01
http://tracker.xemacs.org/XEmacs/its/issue842 created stephen
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Raymond Toy writes:
> Thanks for the info. This is interesting. I set initial-frame-plist and
> default-frame-plist to be the same. I start xemacs and the initial frame
> is the same size as if I did xemacs -vanilla. After a bit it shrinks to
> some smaller size because I set my default font. Then I click on the
> splash screen and it grows to the expected size. This doesn't really
> bother me.
That still bothers me. Something is "strange and overly complexified"[1]
here.
> That's probably it. (face-font 'default) says DejaVu Sans Mono-10, but
> (face-font 'bold) says -12. So I actually have to specify the bold face
> too? I had thought that the other fonts where derived from the default if
> it wasn't specified.
Well, sort of. What we *should* have is face inheritance. Then 'bold
would inherit font family from 'default. Unfortunately, in the old X
bitmap font model faces like bold and italic had to be provided as
separate font files, and many fonts didn't provide them. So finding a
bold font for any given font often required search beyond merely
changing the weight parameter. Since code needed to be called
dynamically, it kind of needs to be done explicitly, and it isn't
always done.
> And setting the bold and italic fonts appropriately makes the splash screen
> come out neatly in columns.
Yay!
I'll set a bug for trying to make this more automatic so users don't
need to do it. It really shouldn't be necessary with OpenType, and
true inheritance should be fairly easy to implement.
> Another display glitch: When the initial frame is resized, the Help
> menu button is not displayed. If I resize the frame slightly (in
> any direction), the Help menu is displayed again.
OK, there are some redisplay glitches where some parts of XEmacs think
the frame is of a different size than others do. This is probably
just a another manifestation.
Footnotes:
[1] Ben Wing quote from a comment in redisplay. ;-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta