* bug#8680: Cocoa Emacs not mapping Clear key on aluminum keyboards. @ 2011-05-17 5:07 Michael Marchionna 2011-05-17 17:34 ` bug#8680: nsterm.m does not distinguish key on the key pad Michael Marchionna ` (2 more replies) 0 siblings, 3 replies; 27+ messages in thread From: Michael Marchionna @ 2011-05-17 5:07 UTC (permalink / raw) To: 8680 The newer Mac aluminum keyboards have a "clear" on the keypad group where the Num-Lock typically lives. This key generates: keyCode: 71 (0x47), and character: 0xf739. The character 0xf739 maps to the NSClearLineFunctionKey defined in NSEvent.h. Since this symbol is not listed in the nsterm.m translation table the clear key becomes a dead key. It can be mapped to emacs [clear] key with the following change. diff --git a/src/nsterm.m b/src/nsterm.m index 91f0cbb..119327d 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -87,6 +87,7 @@ static unsigned convert_ns_to_X_keysym[] = NSBeginFunctionKey, 0x58, NSSelectFunctionKey, 0x60, NSPrintFunctionKey, 0x61, + NSClearLineFunctionKey, 0x0B, NSExecuteFunctionKey, 0x62, NSInsertFunctionKey, 0x63, NSUndoFunctionKey, 0x65, This change makes the key respond as it did in Carbon Emacs. ^ permalink raw reply related [flat|nested] 27+ messages in thread
* bug#8680: nsterm.m does not distinguish key on the key pad 2011-05-17 5:07 bug#8680: Cocoa Emacs not mapping Clear key on aluminum keyboards Michael Marchionna @ 2011-05-17 17:34 ` Michael Marchionna 2012-11-04 3:34 ` Chong Yidong 2011-05-23 20:11 ` bug#8680: emacs 24.0 OS X keypad patch Michael Marchionna 2013-12-10 22:13 ` bug#8680: Bug #8680 Andrew Stein 2 siblings, 1 reply; 27+ messages in thread From: Michael Marchionna @ 2011-05-17 17:34 UTC (permalink / raw) To: 8680 In addition to the clear/NumLock key not being mapped the rest of the keypad keys do not seem to be translated as well, and hence can not be distinguished from keys on the main keyboard. What follows is a patch that remaps the keypad keys. at least on a aluminum apple keyboard, to the appropriate X11 virtual key codes. Note the Clear/NumLock key is hardcoded to XK_Clear. There should probably be a way to make it possible to configure it so that it translates to XK_Num_Lock. diff --git a/src/nsterm.m b/src/nsterm.m index 91f0cbb..322c9d9 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -87,6 +87,7 @@ static unsigned convert_ns_to_X_keysym[] = NSBeginFunctionKey, 0x58, NSSelectFunctionKey, 0x60, NSPrintFunctionKey, 0x61, + NSClearLineFunctionKey, 0x0B, NSExecuteFunctionKey, 0x62, NSInsertFunctionKey, 0x63, NSUndoFunctionKey, 0x65, @@ -131,7 +132,24 @@ static unsigned convert_ns_to_X_keysym[] = NSNewlineCharacter, 0x0D, NSEnterCharacter, 0x8D, - 0x1B, 0x1B /* escape */ + 0x1B, 0x1B, /* escape */ + + 0x41, 0xAE, /* KP_Decimal */ + 0x43, 0xAA, /* KP_Multiply */ + 0x45, 0xAB, /* KP_Add */ + 0x4B, 0xAF, /* KP_Divide */ + 0x4E, 0xAD, /* KP_Subtract */ + 0x51, 0xBD, /* KP_Equal */ + 0x52, 0xB0, /* KP_0 */ + 0x53, 0xB1, /* KP_1 */ + 0x54, 0xB2, /* KP_2 */ + 0x55, 0xB3, /* KP_3 */ + 0x56, 0xB4, /* KP_4 */ + 0x57, 0xB5, /* KP_5 */ + 0x58, 0xB6, /* KP_6 */ + 0x59, 0xB7, /* KP_7 */ + 0x5B, 0xB8, /* KP_8 */ + 0x5C, 0xB9 /* KP_9 */ }; @@ -4503,10 +4521,10 @@ ns_term_shutdown (int sig) Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (emacsframe); int code; unsigned fnKeysym = 0; - int flags; static NSMutableArray *nsEvArray; static BOOL firstTime = YES; int left_is_none; + unsigned int flags = [theEvent modifierFlags]; NSTRACE (keyDown); @@ -4550,9 +4568,13 @@ ns_term_shutdown (int sig) code = ([[theEvent charactersIgnoringModifiers] length] == 0) ? 0 : [[theEvent charactersIgnoringModifiers] characterAtIndex: 0]; /* (Carbon way: [theEvent keyCode]) */ + /* is it a "function key"? */ - fnKeysym = ns_convert_key (code); + if ( code < 0x00ff && (flags&NSNumericPadKeyMask) ) + fnKeysym = ns_convert_key([theEvent keyCode]); + else + fnKeysym = ns_convert_key (code); if (fnKeysym) { /* COUNTERHACK: map 'Delete' on upper-right main KB to 'Backspace', @@ -4565,7 +4587,6 @@ ns_term_shutdown (int sig) /* are there modifiers? */ emacs_event->modifiers = 0; - flags = [theEvent modifierFlags]; if (flags & NSHelpKeyMask) emacs_event->modifiers |= hyper_modifier; ^ permalink raw reply related [flat|nested] 27+ messages in thread
* bug#8680: nsterm.m does not distinguish key on the key pad 2011-05-17 17:34 ` bug#8680: nsterm.m does not distinguish key on the key pad Michael Marchionna @ 2012-11-04 3:34 ` Chong Yidong 0 siblings, 0 replies; 27+ messages in thread From: Chong Yidong @ 2012-11-04 3:34 UTC (permalink / raw) To: Michael Marchionna; +Cc: 8680 Michael Marchionna <tralfaz@pacbell.net> writes: > In addition to the clear/NumLock key not being mapped the rest of the > keypad keys do not seem to be translated as well, and hence can not be > distinguished from keys on the main keyboard. What follows is a patch > that remaps the keypad keys. at least on a aluminum apple keyboard, to > the appropriate X11 virtual key codes. Note the Clear/NumLock key is > hardcoded to XK_Clear. There should probably be a way to make it > possible to configure it so that it translates to XK_Num_Lock. I've committed your patch to the trunk. Sorry for the long delay. ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#8680: emacs 24.0 OS X keypad patch 2011-05-17 5:07 bug#8680: Cocoa Emacs not mapping Clear key on aluminum keyboards Michael Marchionna 2011-05-17 17:34 ` bug#8680: nsterm.m does not distinguish key on the key pad Michael Marchionna @ 2011-05-23 20:11 ` Michael Marchionna 2011-07-04 17:42 ` Stefan Monnier 2013-12-10 22:13 ` bug#8680: Bug #8680 Andrew Stein 2 siblings, 1 reply; 27+ messages in thread From: Michael Marchionna @ 2011-05-23 20:11 UTC (permalink / raw) To: 8680 [-- Attachment #1: Type: text/plain, Size: 240 bytes --] Adding keypad keycodes to the existing translation table leads to some keys being wrongly interpreted as keypad keys. To avoid that, this patch uses a separate translation table exclusively for keys that generate a NSNumericPadKeyMask. [-- Attachment #2: emacs-24-src-nsterm.m.patch --] [-- Type: application/octet-stream, Size: 4345 bytes --] diff --git a/src/nsterm.m b/src/nsterm.m index 91f0cbb..d537ee3 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -87,6 +87,7 @@ static unsigned convert_ns_to_X_keysym[] = NSBeginFunctionKey, 0x58, NSSelectFunctionKey, 0x60, NSPrintFunctionKey, 0x61, + NSClearLineFunctionKey, 0x0B, NSExecuteFunctionKey, 0x62, NSInsertFunctionKey, 0x63, NSUndoFunctionKey, 0x65, @@ -134,6 +135,35 @@ static unsigned convert_ns_to_X_keysym[] = 0x1B, 0x1B /* escape */ }; +static unsigned convert_nskeypad_to_X_keysym[] = +{ + /* Arrow keys are both function and keypad keys */ + NSLeftArrowFunctionKey, 0x51, + NSUpArrowFunctionKey, 0x52, + NSRightArrowFunctionKey, 0x53, + NSDownArrowFunctionKey, 0x54, + + 0x41, 0xAE, /* KP_Decimal */ + 0x43, 0xAA, /* KP_Multiply */ + 0x45, 0xAB, /* KP_Add */ + 0x4B, 0xAF, /* KP_Divide */ + 0x4E, 0xAD, /* KP_Subtract */ + 0x51, 0xBD, /* KP_Equal */ + 0x52, 0xB0, /* KP_0 */ + 0x53, 0xB1, /* KP_1 */ + 0x54, 0xB2, /* KP_2 */ + 0x55, 0xB3, /* KP_3 */ + 0x56, 0xB4, /* KP_4 */ + 0x57, 0xB5, /* KP_5 */ + 0x58, 0xB6, /* KP_6 */ + 0x59, 0xB7, /* KP_7 */ + 0x5B, 0xB8, /* KP_8 */ + 0x5C, 0xB9, /* KP_9 */ + + // The enter key is on the keypad but modifier isnt set + NSEnterCharacter, 0x8D +}; + static Lisp_Object Qmodifier_value; Lisp_Object Qalt, Qcontrol, Qhyper, Qmeta, Qsuper, Qnone; @@ -1924,13 +1954,33 @@ ns_convert_key (unsigned code) unsigned keysym; /* An array would be faster, but less easy to read. */ for (keysym = 0; keysym < last_keysym; keysym += 2) - if (code == convert_ns_to_X_keysym[keysym]) - return 0xFF00 | convert_ns_to_X_keysym[keysym+1]; + + if (code == convert_ns_to_X_keysym[keysym]) { + return 0xFF00 | convert_ns_to_X_keysym[keysym+1]; + } return 0; /* if decide to use keyCode and Carbon table, use this line: return code > 0xff ? 0 : 0xFF00 | ns_keycode_to_xkeysym_table[code]; */ } +static unsigned +ns_convert_keypad (unsigned code) +/* -------------------------------------------------------------------------- + Internal call used by NSView-keyDown. + -------------------------------------------------------------------------- */ +{ + const unsigned last_keysym = (sizeof (convert_nskeypad_to_X_keysym) + / sizeof (convert_nskeypad_to_X_keysym[0])); + unsigned keysym; + /* An array would be faster, but less easy to read. */ + for (keysym = 0; keysym < last_keysym; keysym += 2) { + if (code == convert_nskeypad_to_X_keysym[keysym]) { + return 0xFF00 | convert_nskeypad_to_X_keysym[keysym+1]; + } + } + return 0; +} + char * x_get_keysym_name (int keysym) @@ -4503,10 +4553,10 @@ ns_term_shutdown (int sig) Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (emacsframe); int code; unsigned fnKeysym = 0; - int flags; static NSMutableArray *nsEvArray; static BOOL firstTime = YES; int left_is_none; + unsigned int flags = [theEvent modifierFlags]; NSTRACE (keyDown); @@ -4550,9 +4600,13 @@ ns_term_shutdown (int sig) code = ([[theEvent charactersIgnoringModifiers] length] == 0) ? 0 : [[theEvent charactersIgnoringModifiers] characterAtIndex: 0]; /* (Carbon way: [theEvent keyCode]) */ + /* is it a "function key"? */ - fnKeysym = ns_convert_key (code); + if (code < 0x00ff && (flags & NSNumericPadKeyMask) ) + fnKeysym = ns_convert_keypad([theEvent keyCode]); + else + fnKeysym = ns_convert_key(code); if (fnKeysym) { /* COUNTERHACK: map 'Delete' on upper-right main KB to 'Backspace', @@ -4565,7 +4619,6 @@ ns_term_shutdown (int sig) /* are there modifiers? */ emacs_event->modifiers = 0; - flags = [theEvent modifierFlags]; if (flags & NSHelpKeyMask) emacs_event->modifiers |= hyper_modifier; ^ permalink raw reply related [flat|nested] 27+ messages in thread
* bug#8680: emacs 24.0 OS X keypad patch 2011-05-23 20:11 ` bug#8680: emacs 24.0 OS X keypad patch Michael Marchionna @ 2011-07-04 17:42 ` Stefan Monnier 2011-07-07 3:04 ` Adrian Robert 0 siblings, 1 reply; 27+ messages in thread From: Stefan Monnier @ 2011-07-04 17:42 UTC (permalink / raw) To: 8680; +Cc: Adrian Robert reassign 8680 emacs,ns tags 8680 +patch thanks Could someone familiar with the MacOSX code take a look at this bug report? Stefan >>>>> "Michael" == Michael Marchionna <tralfaz@pacbell.net> writes: > Adding keypad keycodes to the existing translation table leads to some keys > being wrongly interpreted as keypad keys. To avoid that, this patch > uses a separate translation table exclusively for keys that > generate a NSNumericPadKeyMask. > diff --git a/src/nsterm.m b/src/nsterm.m > index 91f0cbb..d537ee3 100644 > --- a/src/nsterm.m > +++ b/src/nsterm.m > @@ -87,6 +87,7 @@ static unsigned convert_ns_to_X_keysym[] = > NSBeginFunctionKey, 0x58, > NSSelectFunctionKey, 0x60, > NSPrintFunctionKey, 0x61, > + NSClearLineFunctionKey, 0x0B, > NSExecuteFunctionKey, 0x62, > NSInsertFunctionKey, 0x63, > NSUndoFunctionKey, 0x65, > @@ -134,6 +135,35 @@ static unsigned convert_ns_to_X_keysym[] = > 0x1B, 0x1B /* escape */ > }; > +static unsigned convert_nskeypad_to_X_keysym[] = > +{ > + /* Arrow keys are both function and keypad keys */ > + NSLeftArrowFunctionKey, 0x51, > + NSUpArrowFunctionKey, 0x52, > + NSRightArrowFunctionKey, 0x53, > + NSDownArrowFunctionKey, 0x54, > + > + 0x41, 0xAE, /* KP_Decimal */ > + 0x43, 0xAA, /* KP_Multiply */ > + 0x45, 0xAB, /* KP_Add */ > + 0x4B, 0xAF, /* KP_Divide */ > + 0x4E, 0xAD, /* KP_Subtract */ > + 0x51, 0xBD, /* KP_Equal */ > + 0x52, 0xB0, /* KP_0 */ > + 0x53, 0xB1, /* KP_1 */ > + 0x54, 0xB2, /* KP_2 */ > + 0x55, 0xB3, /* KP_3 */ > + 0x56, 0xB4, /* KP_4 */ > + 0x57, 0xB5, /* KP_5 */ > + 0x58, 0xB6, /* KP_6 */ > + 0x59, 0xB7, /* KP_7 */ > + 0x5B, 0xB8, /* KP_8 */ > + 0x5C, 0xB9, /* KP_9 */ > + > + // The enter key is on the keypad but modifier isnt set > + NSEnterCharacter, 0x8D > +}; > + > static Lisp_Object Qmodifier_value; > Lisp_Object Qalt, Qcontrol, Qhyper, Qmeta, Qsuper, Qnone; > @@ -1924,13 +1954,33 @@ ns_convert_key (unsigned code) > unsigned keysym; > /* An array would be faster, but less easy to read. */ > for (keysym = 0; keysym < last_keysym; keysym += 2) > - if (code == convert_ns_to_X_keysym[keysym]) > - return 0xFF00 | convert_ns_to_X_keysym[keysym+1]; > + > + if (code == convert_ns_to_X_keysym[keysym]) { > + return 0xFF00 | convert_ns_to_X_keysym[keysym+1]; > + } > return 0; > /* if decide to use keyCode and Carbon table, use this line: > return code > 0xff ? 0 : 0xFF00 | ns_keycode_to_xkeysym_table[code]; */ > } > +static unsigned > +ns_convert_keypad (unsigned code) > +/* -------------------------------------------------------------------------- > + Internal call used by NSView-keyDown. > + -------------------------------------------------------------------------- */ > +{ > + const unsigned last_keysym = (sizeof (convert_nskeypad_to_X_keysym) > + / sizeof (convert_nskeypad_to_X_keysym[0])); > + unsigned keysym; > + /* An array would be faster, but less easy to read. */ > + for (keysym = 0; keysym < last_keysym; keysym += 2) { > + if (code == convert_nskeypad_to_X_keysym[keysym]) { > + return 0xFF00 | convert_nskeypad_to_X_keysym[keysym+1]; > + } > + } > + return 0; > +} > + > char * > x_get_keysym_name (int keysym) > @@ -4503,10 +4553,10 @@ ns_term_shutdown (int sig) > Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (emacsframe); > int code; > unsigned fnKeysym = 0; > - int flags; > static NSMutableArray *nsEvArray; > static BOOL firstTime = YES; > int left_is_none; > + unsigned int flags = [theEvent modifierFlags]; > NSTRACE (keyDown); > @@ -4550,9 +4600,13 @@ ns_term_shutdown (int sig) > code = ([[theEvent charactersIgnoringModifiers] length] == 0) ? > 0 : [[theEvent charactersIgnoringModifiers] characterAtIndex: 0]; > /* (Carbon way: [theEvent keyCode]) */ > + > /* is it a "function key"? */ > - fnKeysym = ns_convert_key (code); > + if (code < 0x00ff && (flags & NSNumericPadKeyMask) ) > + fnKeysym = ns_convert_keypad([theEvent keyCode]); > + else > + fnKeysym = ns_convert_key(code); > if (fnKeysym) > { > /* COUNTERHACK: map 'Delete' on upper-right main KB to 'Backspace', > @@ -4565,7 +4619,6 @@ ns_term_shutdown (int sig) > /* are there modifiers? */ emacs_event-> modifiers = 0; > - flags = [theEvent modifierFlags]; > if (flags & NSHelpKeyMask) emacs_event-> modifiers |= hyper_modifier; ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#8680: emacs 24.0 OS X keypad patch 2011-07-04 17:42 ` Stefan Monnier @ 2011-07-07 3:04 ` Adrian Robert 2011-07-07 14:55 ` Michael Marchionna 0 siblings, 1 reply; 27+ messages in thread From: Adrian Robert @ 2011-07-07 3:04 UTC (permalink / raw) To: Stefan Monnier; +Cc: 8680, tralfaz The code looks reasonable, but could the author explain why [theEvent keyCode] needs to be used in the keypad conversion instead of code? The code would be more understandable if ns_convert_kaypad() and ns_convert_key() used the same argument. Also this patch should be tested for correct behavior wrt this issue: http://www.cocoabuilder.com/archive/cocoa/73306-workaround-for-broken-numlock-support.html#73306 thanks, Adrian On 2011/07/04, at 13:42, Stefan Monnier wrote: > reassign 8680 emacs,ns > tags 8680 +patch > thanks > > Could someone familiar with the MacOSX code take a look at this > bug report? > > > Stefan > > >>>>>> "Michael" == Michael Marchionna <tralfaz@pacbell.net> writes: > >> Adding keypad keycodes to the existing translation table leads to some keys >> being wrongly interpreted as keypad keys. To avoid that, this patch >> uses a separate translation table exclusively for keys that >> generate a NSNumericPadKeyMask. > > >> diff --git a/src/nsterm.m b/src/nsterm.m >> index 91f0cbb..d537ee3 100644 >> --- a/src/nsterm.m >> +++ b/src/nsterm.m >> @@ -87,6 +87,7 @@ static unsigned convert_ns_to_X_keysym[] = >> NSBeginFunctionKey, 0x58, >> NSSelectFunctionKey, 0x60, >> NSPrintFunctionKey, 0x61, >> + NSClearLineFunctionKey, 0x0B, >> NSExecuteFunctionKey, 0x62, >> NSInsertFunctionKey, 0x63, >> NSUndoFunctionKey, 0x65, >> @@ -134,6 +135,35 @@ static unsigned convert_ns_to_X_keysym[] = >> 0x1B, 0x1B /* escape */ >> }; > >> +static unsigned convert_nskeypad_to_X_keysym[] = >> +{ >> + /* Arrow keys are both function and keypad keys */ >> + NSLeftArrowFunctionKey, 0x51, >> + NSUpArrowFunctionKey, 0x52, >> + NSRightArrowFunctionKey, 0x53, >> + NSDownArrowFunctionKey, 0x54, >> + >> + 0x41, 0xAE, /* KP_Decimal */ >> + 0x43, 0xAA, /* KP_Multiply */ >> + 0x45, 0xAB, /* KP_Add */ >> + 0x4B, 0xAF, /* KP_Divide */ >> + 0x4E, 0xAD, /* KP_Subtract */ >> + 0x51, 0xBD, /* KP_Equal */ >> + 0x52, 0xB0, /* KP_0 */ >> + 0x53, 0xB1, /* KP_1 */ >> + 0x54, 0xB2, /* KP_2 */ >> + 0x55, 0xB3, /* KP_3 */ >> + 0x56, 0xB4, /* KP_4 */ >> + 0x57, 0xB5, /* KP_5 */ >> + 0x58, 0xB6, /* KP_6 */ >> + 0x59, 0xB7, /* KP_7 */ >> + 0x5B, 0xB8, /* KP_8 */ >> + 0x5C, 0xB9, /* KP_9 */ >> + >> + // The enter key is on the keypad but modifier isnt set >> + NSEnterCharacter, 0x8D >> +}; >> + > >> static Lisp_Object Qmodifier_value; >> Lisp_Object Qalt, Qcontrol, Qhyper, Qmeta, Qsuper, Qnone; >> @@ -1924,13 +1954,33 @@ ns_convert_key (unsigned code) >> unsigned keysym; >> /* An array would be faster, but less easy to read. */ >> for (keysym = 0; keysym < last_keysym; keysym += 2) >> - if (code == convert_ns_to_X_keysym[keysym]) >> - return 0xFF00 | convert_ns_to_X_keysym[keysym+1]; >> + >> + if (code == convert_ns_to_X_keysym[keysym]) { >> + return 0xFF00 | convert_ns_to_X_keysym[keysym+1]; >> + } >> return 0; >> /* if decide to use keyCode and Carbon table, use this line: >> return code > 0xff ? 0 : 0xFF00 | ns_keycode_to_xkeysym_table[code]; */ >> } > >> +static unsigned >> +ns_convert_keypad (unsigned code) >> +/* -------------------------------------------------------------------------- >> + Internal call used by NSView-keyDown. >> + -------------------------------------------------------------------------- */ >> +{ >> + const unsigned last_keysym = (sizeof (convert_nskeypad_to_X_keysym) >> + / sizeof (convert_nskeypad_to_X_keysym[0])); >> + unsigned keysym; >> + /* An array would be faster, but less easy to read. */ >> + for (keysym = 0; keysym < last_keysym; keysym += 2) { >> + if (code == convert_nskeypad_to_X_keysym[keysym]) { >> + return 0xFF00 | convert_nskeypad_to_X_keysym[keysym+1]; >> + } >> + } >> + return 0; >> +} >> + > >> char * >> x_get_keysym_name (int keysym) >> @@ -4503,10 +4553,10 @@ ns_term_shutdown (int sig) >> Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (emacsframe); >> int code; >> unsigned fnKeysym = 0; >> - int flags; >> static NSMutableArray *nsEvArray; >> static BOOL firstTime = YES; >> int left_is_none; >> + unsigned int flags = [theEvent modifierFlags]; > >> NSTRACE (keyDown); > >> @@ -4550,9 +4600,13 @@ ns_term_shutdown (int sig) >> code = ([[theEvent charactersIgnoringModifiers] length] == 0) ? >> 0 : [[theEvent charactersIgnoringModifiers] characterAtIndex: 0]; >> /* (Carbon way: [theEvent keyCode]) */ >> + > >> /* is it a "function key"? */ >> - fnKeysym = ns_convert_key (code); >> + if (code < 0x00ff && (flags & NSNumericPadKeyMask) ) >> + fnKeysym = ns_convert_keypad([theEvent keyCode]); >> + else >> + fnKeysym = ns_convert_key(code); >> if (fnKeysym) >> { >> /* COUNTERHACK: map 'Delete' on upper-right main KB to 'Backspace', >> @@ -4565,7 +4619,6 @@ ns_term_shutdown (int sig) > >> /* are there modifiers? */ > emacs_event-> modifiers = 0; >> - flags = [theEvent modifierFlags]; > >> if (flags & NSHelpKeyMask) > emacs_event-> modifiers |= hyper_modifier; ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#8680: emacs 24.0 OS X keypad patch 2011-07-07 3:04 ` Adrian Robert @ 2011-07-07 14:55 ` Michael Marchionna 0 siblings, 0 replies; 27+ messages in thread From: Michael Marchionna @ 2011-07-07 14:55 UTC (permalink / raw) To: Adrian Robert; +Cc: 8680 The reason for split between non-keypad keys and keypad keys, was that the code generated by the following code produced coincident values that produced non-unique results. code = ([[theEvent charactersIgnoringModifiers] length] == 0) ? 0 : [[theEvent charactersIgnoringModifiers] characterAtIndex: 0]; Using the first character of key event would not distinguish a "=" on the main keyboard from a "=" on the keypad. Using the [theEvent keyCode] in the older ns_convert_key function would mean verifying and possibly altering all the translation values in the older table. It may be the case that this change does not properly toggle between numeric keypad, and movement keypad, but on newer mac keyboards the num-lock key is actually a "Clear" key, and Num-Lock behavior is synthesized. Not sure what the best solution for making the "Clear" key behave like a physical Num-Lock key is, but this change does allow key event from the keypad to at least be mapped to something. Michael Marchionna On Jul 6, 2011, at 8:04 PM, Adrian Robert wrote: > The code looks reasonable, but could the author explain why [theEvent keyCode] needs to be used in the keypad conversion instead of code? The code would be more understandable if ns_convert_kaypad() and ns_convert_key() used the same argument. Also this patch should be tested for correct behavior wrt this issue: > > http://www.cocoabuilder.com/archive/cocoa/73306-workaround-for-broken-numlock-support.html#73306 > > > thanks, > Adrian > > > On 2011/07/04, at 13:42, Stefan Monnier wrote: > >> reassign 8680 emacs,ns >> tags 8680 +patch >> thanks >> >> Could someone familiar with the MacOSX code take a look at this >> bug report? >> >> >> Stefan >> >> >>>>>>> "Michael" == Michael Marchionna <tralfaz@pacbell.net> writes: >> >>> Adding keypad keycodes to the existing translation table leads to some keys >>> being wrongly interpreted as keypad keys. To avoid that, this patch >>> uses a separate translation table exclusively for keys that >>> generate a NSNumericPadKeyMask. >> >> >>> diff --git a/src/nsterm.m b/src/nsterm.m >>> index 91f0cbb..d537ee3 100644 >>> --- a/src/nsterm.m >>> +++ b/src/nsterm.m >>> @@ -87,6 +87,7 @@ static unsigned convert_ns_to_X_keysym[] = >>> NSBeginFunctionKey, 0x58, >>> NSSelectFunctionKey, 0x60, >>> NSPrintFunctionKey, 0x61, >>> + NSClearLineFunctionKey, 0x0B, >>> NSExecuteFunctionKey, 0x62, >>> NSInsertFunctionKey, 0x63, >>> NSUndoFunctionKey, 0x65, >>> @@ -134,6 +135,35 @@ static unsigned convert_ns_to_X_keysym[] = >>> 0x1B, 0x1B /* escape */ >>> }; >> >>> +static unsigned convert_nskeypad_to_X_keysym[] = >>> +{ >>> + /* Arrow keys are both function and keypad keys */ >>> + NSLeftArrowFunctionKey, 0x51, >>> + NSUpArrowFunctionKey, 0x52, >>> + NSRightArrowFunctionKey, 0x53, >>> + NSDownArrowFunctionKey, 0x54, >>> + >>> + 0x41, 0xAE, /* KP_Decimal */ >>> + 0x43, 0xAA, /* KP_Multiply */ >>> + 0x45, 0xAB, /* KP_Add */ >>> + 0x4B, 0xAF, /* KP_Divide */ >>> + 0x4E, 0xAD, /* KP_Subtract */ >>> + 0x51, 0xBD, /* KP_Equal */ >>> + 0x52, 0xB0, /* KP_0 */ >>> + 0x53, 0xB1, /* KP_1 */ >>> + 0x54, 0xB2, /* KP_2 */ >>> + 0x55, 0xB3, /* KP_3 */ >>> + 0x56, 0xB4, /* KP_4 */ >>> + 0x57, 0xB5, /* KP_5 */ >>> + 0x58, 0xB6, /* KP_6 */ >>> + 0x59, 0xB7, /* KP_7 */ >>> + 0x5B, 0xB8, /* KP_8 */ >>> + 0x5C, 0xB9, /* KP_9 */ >>> + >>> + // The enter key is on the keypad but modifier isnt set >>> + NSEnterCharacter, 0x8D >>> +}; >>> + >> >>> static Lisp_Object Qmodifier_value; >>> Lisp_Object Qalt, Qcontrol, Qhyper, Qmeta, Qsuper, Qnone; >>> @@ -1924,13 +1954,33 @@ ns_convert_key (unsigned code) >>> unsigned keysym; >>> /* An array would be faster, but less easy to read. */ >>> for (keysym = 0; keysym < last_keysym; keysym += 2) >>> - if (code == convert_ns_to_X_keysym[keysym]) >>> - return 0xFF00 | convert_ns_to_X_keysym[keysym+1]; >>> + >>> + if (code == convert_ns_to_X_keysym[keysym]) { >>> + return 0xFF00 | convert_ns_to_X_keysym[keysym+1]; >>> + } >>> return 0; >>> /* if decide to use keyCode and Carbon table, use this line: >>> return code > 0xff ? 0 : 0xFF00 | ns_keycode_to_xkeysym_table[code]; */ >>> } >> >>> +static unsigned >>> +ns_convert_keypad (unsigned code) >>> +/* -------------------------------------------------------------------------- >>> + Internal call used by NSView-keyDown. >>> + -------------------------------------------------------------------------- */ >>> +{ >>> + const unsigned last_keysym = (sizeof (convert_nskeypad_to_X_keysym) >>> + / sizeof (convert_nskeypad_to_X_keysym[0])); >>> + unsigned keysym; >>> + /* An array would be faster, but less easy to read. */ >>> + for (keysym = 0; keysym < last_keysym; keysym += 2) { >>> + if (code == convert_nskeypad_to_X_keysym[keysym]) { >>> + return 0xFF00 | convert_nskeypad_to_X_keysym[keysym+1]; >>> + } >>> + } >>> + return 0; >>> +} >>> + >> >>> char * >>> x_get_keysym_name (int keysym) >>> @@ -4503,10 +4553,10 @@ ns_term_shutdown (int sig) >>> Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (emacsframe); >>> int code; >>> unsigned fnKeysym = 0; >>> - int flags; >>> static NSMutableArray *nsEvArray; >>> static BOOL firstTime = YES; >>> int left_is_none; >>> + unsigned int flags = [theEvent modifierFlags]; >> >>> NSTRACE (keyDown); >> >>> @@ -4550,9 +4600,13 @@ ns_term_shutdown (int sig) >>> code = ([[theEvent charactersIgnoringModifiers] length] == 0) ? >>> 0 : [[theEvent charactersIgnoringModifiers] characterAtIndex: 0]; >>> /* (Carbon way: [theEvent keyCode]) */ >>> + >> >>> /* is it a "function key"? */ >>> - fnKeysym = ns_convert_key (code); >>> + if (code < 0x00ff && (flags & NSNumericPadKeyMask) ) >>> + fnKeysym = ns_convert_keypad([theEvent keyCode]); >>> + else >>> + fnKeysym = ns_convert_key(code); >>> if (fnKeysym) >>> { >>> /* COUNTERHACK: map 'Delete' on upper-right main KB to 'Backspace', >>> @@ -4565,7 +4619,6 @@ ns_term_shutdown (int sig) >> >>> /* are there modifiers? */ >> emacs_event-> modifiers = 0; >>> - flags = [theEvent modifierFlags]; >> >>> if (flags & NSHelpKeyMask) >> emacs_event-> modifiers |= hyper_modifier; > ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#8680: Bug #8680 2011-05-17 5:07 bug#8680: Cocoa Emacs not mapping Clear key on aluminum keyboards Michael Marchionna 2011-05-17 17:34 ` bug#8680: nsterm.m does not distinguish key on the key pad Michael Marchionna 2011-05-23 20:11 ` bug#8680: emacs 24.0 OS X keypad patch Michael Marchionna @ 2013-12-10 22:13 ` Andrew Stein 2013-12-10 22:40 ` bug#8680: Glenn Morris 2 siblings, 1 reply; 27+ messages in thread From: Andrew Stein @ 2013-12-10 22:13 UTC (permalink / raw) To: 8680 [-- Attachment #1: Type: text/plain, Size: 861 bytes --] I am inquiring about gnu emacs bug #8680. I apologize if I am not using the correct channels. According to the bug report at http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8680 you closed this bug in November 2012 by fixing it by committing the patch to trunk. (Actually there are two patches.) My problem is that I cannot see the effect of this fix in the version of emacs that I am using, namely 24.3.1 from http://emacsformacosx.com/, built in March of 2013. Also when I browse the source at http://git.savannah.gnu.org/cgit/emacs.git/tree/src/nsterm.m?h=emacs-24 I cannot see either patch. Perhaps I am using a wrong version of emacs. If not, could you verify that the patches made it into emacs 24. BTW, there is more info out in Stack Overflow: http://stackoverflow.com/questions/5739974/binding-numeric-keypad-keys-with-emacs-24-and-os-x Andrew Stein [-- Attachment #2: Type: text/html, Size: 1923 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#8680: 2013-12-10 22:13 ` bug#8680: Bug #8680 Andrew Stein @ 2013-12-10 22:40 ` Glenn Morris 2013-12-10 22:54 ` bug#8680: Andrew Stein 0 siblings, 1 reply; 27+ messages in thread From: Glenn Morris @ 2013-12-10 22:40 UTC (permalink / raw) To: Andrew Stein; +Cc: 8680 The patch is in the Emacs trunk, not the emacs-24 branch, which means it will first appear in Emacs 24.4 when it comes out. It was not in 24.3. (I've previously encourage people to include the fixed version when they close bugs, but many still do not.) ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#8680: 2013-12-10 22:40 ` bug#8680: Glenn Morris @ 2013-12-10 22:54 ` Andrew Stein 2013-12-11 4:53 ` bug#8680: Stefan Monnier 0 siblings, 1 reply; 27+ messages in thread From: Andrew Stein @ 2013-12-10 22:54 UTC (permalink / raw) To: Glenn Morris; +Cc: 8680 [-- Attachment #1: Type: text/plain, Size: 490 bytes --] Hi Glenn, Thank you very much for the quick reply. I guess I will wait for the release of emacs 24.4. When can we expect the happy event? Andrew Stein On Tue, Dec 10, 2013 at 4:40 PM, Glenn Morris <rgm@gnu.org> wrote: > > The patch is in the Emacs trunk, not the emacs-24 branch, which means it > will first appear in Emacs 24.4 when it comes out. It was not in 24.3. > > (I've previously encourage people to include the fixed version when they > close bugs, but many still do not.) > [-- Attachment #2: Type: text/html, Size: 861 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#8680: 2013-12-10 22:54 ` bug#8680: Andrew Stein @ 2013-12-11 4:53 ` Stefan Monnier 2013-12-12 0:48 ` bug#8680: Leo Liu 0 siblings, 1 reply; 27+ messages in thread From: Stefan Monnier @ 2013-12-11 4:53 UTC (permalink / raw) To: Andrew Stein; +Cc: 8680 > Thank you very much for the quick reply. I guess I will wait for the > release of emacs 24.4. When can we expect the happy event? Hopefully before Xmas 2014. Stefan ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#8680: 2013-12-11 4:53 ` bug#8680: Stefan Monnier @ 2013-12-12 0:48 ` Leo Liu 2013-12-13 21:50 ` bug#8680: releases Juri Linkov 0 siblings, 1 reply; 27+ messages in thread From: Leo Liu @ 2013-12-12 0:48 UTC (permalink / raw) To: Stefan Monnier; +Cc: 8680, Andrew Stein On 2013-12-11 12:53 +0800, Stefan Monnier wrote: > Hopefully before Xmas 2014. > > > Stefan How time flies! I wonder if in future we could go a lighter-weight release process i.e. every 3 months. I have been using emacs 24.3 most of the time and it took me some time to absorb all the nice features in 24.4. I think the features that we put efforts to develop would be better received if delivered gradually. Leo ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#8680: releases 2013-12-12 0:48 ` bug#8680: Leo Liu @ 2013-12-13 21:50 ` Juri Linkov 2013-12-19 3:00 ` Leo Liu 0 siblings, 1 reply; 27+ messages in thread From: Juri Linkov @ 2013-12-13 21:50 UTC (permalink / raw) To: Leo Liu; +Cc: 8680, Andrew Stein > I wonder if in future we could go a lighter-weight release process i.e. > every 3 months. Want to catch up on the version numbers with Chrome and Firefox? :-) ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#8680: releases 2013-12-13 21:50 ` bug#8680: releases Juri Linkov @ 2013-12-19 3:00 ` Leo Liu 2013-12-19 13:43 ` Stefan Monnier 0 siblings, 1 reply; 27+ messages in thread From: Leo Liu @ 2013-12-19 3:00 UTC (permalink / raw) To: Juri Linkov; +Cc: 8680 On 2013-12-14 05:50 +0800, Juri Linkov wrote: > Want to catch up on the version numbers with Chrome and Firefox? :-) I mean point releases so we can't catch them. For example, have two or three point releases which isn't too many. Leo ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#8680: releases 2013-12-19 3:00 ` Leo Liu @ 2013-12-19 13:43 ` Stefan Monnier 2013-12-19 17:12 ` Glenn Morris 0 siblings, 1 reply; 27+ messages in thread From: Stefan Monnier @ 2013-12-19 13:43 UTC (permalink / raw) To: Leo Liu; +Cc: 8680 I'm all in favor of more frequent release cycles. Currently we run at about one-release per year, which isn't that bad. I wanted to bring this up to 2 releases per year, but noone had the energy to take care of the release management (basically, the amount of effort involved in a pretest did not seem worthwhile compared to the incremental improvement in features). BTW: since we're about to freeze and start a new pretest phase, we're looking for a volunteer to take care of rolling the pretests. Also, we'd welcome some help to update the manuals (most urgently, to integrate all the changes mentioned in NEWS into the manuals). Stefan ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#8680: releases 2013-12-19 13:43 ` Stefan Monnier @ 2013-12-19 17:12 ` Glenn Morris 2013-12-19 18:09 ` The next releases Stefan Monnier 0 siblings, 1 reply; 27+ messages in thread From: Glenn Morris @ 2013-12-19 17:12 UTC (permalink / raw) To: Stefan Monnier; +Cc: 8680 (A 2 year-old archived bug about Mac keyboards isn't the best place for this discussion, but I'm not going to bother to move it.) Stefan Monnier wrote: > I wanted to bring this up to 2 releases per year, but noone had the > energy to take care of the release management That's not how I recall it. IIRC, you wanted to freeze 24.4 ~ six weeks after 24.3 was released. This would have left very little time for people who had been concentrating on the release to develop any new features. > BTW: since we're about to freeze and start a new pretest phase, we're > looking for a volunteer to take care of rolling the pretests. Oh, are you? I would have been happy to do it again. But I see Chong Yidong is back (yay!), so if he wants to do it; or if someone else wants to have a go, it's fine by me. > Also, we'd welcome some help to update the manuals (most urgently, to > integrate all the changes mentioned in NEWS into the manuals). That, of course, is the hard part. Traditionally this large burden has fallen on a tiny number of people. If suddenly lots of people are going to start doing this, of course you can crank out more frequent releases. ^ permalink raw reply [flat|nested] 27+ messages in thread
* The next releases 2013-12-19 17:12 ` Glenn Morris @ 2013-12-19 18:09 ` Stefan Monnier 2013-12-19 21:22 ` Stefan Monnier 2013-12-20 7:25 ` Chong Yidong 0 siblings, 2 replies; 27+ messages in thread From: Stefan Monnier @ 2013-12-19 18:09 UTC (permalink / raw) To: emacs-devel > (A 2 year-old archived bug about Mac keyboards isn't the best place for > this discussion, but I'm not going to bother to move it.) Oops, indeed, thanks for staying alert. >> I wanted to bring this up to 2 releases per year, but noone had the >> energy to take care of the release management > That's not how I recall it. IIRC, you wanted to freeze 24.4 ~ six weeks > after 24.3 was released. This would have left very little time for > people who had been concentrating on the release to develop any new > features. I might indeed be looking at the past through those funny lenses. >> BTW: since we're about to freeze and start a new pretest phase, we're >> looking for a volunteer to take care of rolling the pretests. > Oh, are you? Very much so, yes. > I would have been happy to do it again. But I see Chong Yidong is > back (yay!), so if he wants to do it; or if someone else wants to have > a go, it's fine by me. Not sure if Yidong is volunteering, but in any case I'm very happy to see him back as well. But to tell you the truth, I'd welcome newer blood to roll the pretests. >> Also, we'd welcome some help to update the manuals (most urgently, to >> integrate all the changes mentioned in NEWS into the manuals). > That, of course, is the hard part. Traditionally this large burden has > fallen on a tiny number of people. If suddenly lots of people are going > to start doing this, of course you can crank out more frequent releases. I wish I knew the magic recipe to get people working on it. Stefan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The next releases 2013-12-19 18:09 ` The next releases Stefan Monnier @ 2013-12-19 21:22 ` Stefan Monnier 2013-12-19 22:31 ` Bastien 2013-12-22 0:54 ` Xue Fuqiao 2013-12-20 7:25 ` Chong Yidong 1 sibling, 2 replies; 27+ messages in thread From: Stefan Monnier @ 2013-12-19 21:22 UTC (permalink / raw) To: emacs-devel > But to tell you the truth, I'd welcome newer blood to roll > the pretests. Sean Sieger has volunteered to roll the pretests, and I thank him for that. So now we only need a dozen volunteers to update the manuals. Any takers? Stefan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The next releases 2013-12-19 21:22 ` Stefan Monnier @ 2013-12-19 22:31 ` Bastien 2013-12-20 2:12 ` Stefan Monnier 2013-12-22 0:54 ` Xue Fuqiao 1 sibling, 1 reply; 27+ messages in thread From: Bastien @ 2013-12-19 22:31 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > So now we only need a dozen volunteers to update the manuals. Any > takers? I'm in. Are there specific bugs related to that? Or is there any direction somewhere? Thanks! -- Bastien ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The next releases 2013-12-19 22:31 ` Bastien @ 2013-12-20 2:12 ` Stefan Monnier 0 siblings, 0 replies; 27+ messages in thread From: Stefan Monnier @ 2013-12-20 2:12 UTC (permalink / raw) To: Bastien; +Cc: emacs-devel >> So now we only need a dozen volunteers to update the manuals. Any >> takers? > I'm in. Are there specific bugs related to that? > Or is there any direction somewhere? Read the etc/NEWS file. All entries for "24.4" correspond to changes which should be reflected in the manuals. Those for which the manual has been updated are (or should be) marked with a "+++" or a "---" as explained at the beginning of the NEWS file. All others need work (sometimes, there's nothing to change in the manual, but someone needs to check, and after checking, she should add the +++ or ---). Stefan ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The next releases 2013-12-19 21:22 ` Stefan Monnier 2013-12-19 22:31 ` Bastien @ 2013-12-22 0:54 ` Xue Fuqiao 2013-12-23 0:57 ` Glenn Morris 1 sibling, 1 reply; 27+ messages in thread From: Xue Fuqiao @ 2013-12-22 0:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel On Fri, Dec 20, 2013 at 5:22 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> But to tell you the truth, I'd welcome newer blood to roll >> the pretests. > > Sean Sieger has volunteered to roll the pretests, and I thank him for that. > > So now we only need a dozen volunteers to update the manuals. Any takers? I'm in. -- http://www.gnu.org/software/emacs/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The next releases 2013-12-22 0:54 ` Xue Fuqiao @ 2013-12-23 0:57 ` Glenn Morris 2013-12-23 1:37 ` Ted Zlatanov 0 siblings, 1 reply; 27+ messages in thread From: Glenn Morris @ 2013-12-23 0:57 UTC (permalink / raw) To: emacs-devel Great to see people helping out with the docs. If you want people to check what you've done, not adding the +++ marks to the NEWS file should ensure that someone else looks at it too. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The next releases 2013-12-23 0:57 ` Glenn Morris @ 2013-12-23 1:37 ` Ted Zlatanov 2013-12-23 3:11 ` Glenn Morris 0 siblings, 1 reply; 27+ messages in thread From: Ted Zlatanov @ 2013-12-23 1:37 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 360 bytes --] On Sun, 22 Dec 2013 19:57:55 -0500 Glenn Morris <rgm@gnu.org> wrote: GM> Great to see people helping out with the docs. GM> If you want people to check what you've done, not adding the +++ marks GM> to the NEWS file should ensure that someone else looks at it too. I'm not good with NEWS formatting and content; can you review the patch below? Thanks Ted [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: tzz-news-24.4.patch --] [-- Type: text/x-diff, Size: 2333 bytes --] === modified file 'etc/NEWS' --- etc/NEWS 2013-12-22 23:19:42 +0000 +++ etc/NEWS 2013-12-23 01:36:17 +0000 @@ -23,6 +23,9 @@ \f * Installation Changes in Emacs 24.4 +--- +** Emacs now detects and uses GnuTLS v3 features + ** Emacs can now be compiled with ACL support. This happens by default if a suitable support library is found at build time, like libacl on GNU/Linux. To prevent this, use the @@ -91,6 +94,12 @@ * Changes in Emacs 24.4 +++ +** Emacs can now reject invalid SSL/TLS certificates, as determined by +GnuTLS The new variable `gnutls-verify-error' can be customized. It +is off for now, but will be turned to reject invalid certificates by +default in the future. + ++++ ** Emacs now supports menus on text-mode terminals. If the terminal supports a mouse, clicking on the menu bar, or on sensitive portions of the mode line or header line, will drop down the @@ -393,6 +402,14 @@ *** CUA's rectangles can now be used via `cua-rectangle-mark-mode'. +** CFEngine mode + +*** CFEngine mode has completion and ElDoc support + +*** CFEngine mode can parse the current syntax from cf-promises + +*** CFEngine mode has Flycheck support for on-the-fly syntax checking + ** Delete Selection mode can now be used without `transient-mark-mode'. ** Desktop @@ -561,6 +578,17 @@ *** `describe-package' buffer uses the `:url' extra property to display a `Homepage' header, if it's present. ++++ +*** `describe-package' buffer uses the `:keywords extra property to +display keyword buttons. Clicking them shows the list of packages +that have that keyword. + ++++ +*** the list of packages now shows the archive + ++++ +*** the list of packages can now be filtered by a keyword + ** Prolog mode *** `prolog-use-smie' has been removed, along with the non-SMIE === modified file 'lisp/progmodes/cfengine.el' --- lisp/progmodes/cfengine.el 2013-12-16 15:49:25 +0000 +++ lisp/progmodes/cfengine.el 2013-12-23 01:01:31 +0000 @@ -1322,9 +1322,6 @@ nil nil nil beginning-of-defun)) (setq-local prettify-symbols-alist cfengine3--prettify-symbols-alist) - ;; `compile-command' is almost never a `make' call with CFEngine so - ;; we override it - (when cfengine-cf-promises (set (make-local-variable 'compile-command) (concat cfengine-cf-promises " -f " ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The next releases 2013-12-23 1:37 ` Ted Zlatanov @ 2013-12-23 3:11 ` Glenn Morris 2013-12-23 3:47 ` Glenn Morris 2013-12-23 13:05 ` Ted Zlatanov 0 siblings, 2 replies; 27+ messages in thread From: Glenn Morris @ 2013-12-23 3:11 UTC (permalink / raw) To: emacs-devel My general comment is: never hesitate to make a NEWS entry. Not giving it any +++/--- markup means someone will check it. Ted Zlatanov wrote: > +--- > +** Emacs now detects and uses GnuTLS v3 features Quibbling about language, but I'd say something like: ** Emacs now uses GnuTLS v3 features where available. But as a user, this tells me nothing, so I'm not sure I see the point of this entry as it stands. > +++ > +** Emacs can now reject invalid SSL/TLS certificates, as determined by > +GnuTLS The new variable `gnutls-verify-error' can be customized. It > +is off for now, but will be turned to reject invalid certificates by > +default in the future. [If this is a new option, it should have a :version tag.] ** New option `gnutls-verify-error', if non-nil, means that Emacs should reject SSL/TLS certificates that GnuTLS determines as invalid. (This option defaults to nil at present, but this is expected to change in a future release.) > + > ++++ > ** Emacs now supports menus on text-mode terminals. Did you mean to add that markup? It seems an unrelated change. > +** CFEngine mode It seems redundant to say "CFEngine mode..." in all the following, given that the whole section is about CFEngine mode. > + > +*** CFEngine mode has completion and ElDoc support [...] > +*** CFEngine mode has Flycheck support for on-the-fly syntax checking *** Support for completion, ElDoc, and Flycheck has been added. > +*** CFEngine mode can parse the current syntax from cf-promises I have no idea what that means, but I'm not a CFEngine user, so that may be expected. > ++++ > +*** `describe-package' buffer uses the `:keywords extra property to > +display keyword buttons. Clicking them shows the list of packages > +that have that keyword. *** In the buffer produced by `describe-package', there are now buttons listing the keywords related to that package. You can click on them to see other packages related to any given keyword. > ++++ > +*** the list of packages now shows the archive *** The output of `list-packages' now includes the archive providing each package. [Though this will be self-evident, so I'm not sure it is worth mentioning.] > ++++ > +*** the list of packages can now be filtered by a keyword I don't understand what this really means. The wording makes me think it's somehow related to the list-packages command, but it does not seem to be. Second general comment is that NEWS entries should be grammatical: start with a capital, end with a full-stop. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The next releases 2013-12-23 3:11 ` Glenn Morris @ 2013-12-23 3:47 ` Glenn Morris 2013-12-23 13:05 ` Ted Zlatanov 1 sibling, 0 replies; 27+ messages in thread From: Glenn Morris @ 2013-12-23 3:47 UTC (permalink / raw) To: emacs-devel Glenn Morris wrote: >> ++++ >> ** Emacs now supports menus on text-mode terminals. > > Did you mean to add that markup? It seems an unrelated change. That was just me misreading the diff. Although, that means you're saying gnutls-verify-error is documented, and I can't see that it is. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The next releases 2013-12-23 3:11 ` Glenn Morris 2013-12-23 3:47 ` Glenn Morris @ 2013-12-23 13:05 ` Ted Zlatanov 1 sibling, 0 replies; 27+ messages in thread From: Ted Zlatanov @ 2013-12-23 13:05 UTC (permalink / raw) To: emacs-devel On Sun, 22 Dec 2013 22:11:43 -0500 Glenn Morris <rgm@gnu.org> wrote: GM> Quibbling about language, but I'd say something like: GM> ** Emacs now uses GnuTLS v3 features where available. GM> But as a user, this tells me nothing, so I'm not sure I see the point of GM> this entry as it stands. OK; removed. >> +++ >> +** Emacs can now reject invalid SSL/TLS certificates, as determined by >> +GnuTLS The new variable `gnutls-verify-error' can be customized. It >> +is off for now, but will be turned to reject invalid certificates by >> +default in the future. GM> [If this is a new option, it should have a :version tag.] GM> ** New option `gnutls-verify-error', if non-nil, means that Emacs GM> should reject SSL/TLS certificates that GnuTLS determines as invalid. GM> (This option defaults to nil at present, but this is expected to change GM> in a future release.) Thanks, used this. GM> Although, that means you're saying gnutls-verify-error is documented, GM> and I can't see that it is. Right, fixed. >> +** CFEngine mode GM> It seems redundant to say "CFEngine mode..." in all the following, given GM> that the whole section is about CFEngine mode. I was following the pattern above: #+begin_src text ** CUA mode *** CUA mode was changed to make use of delete-selection-mode and #+end_src I fixed up the CFEngine-related and package.el things. >> ++++ >> +*** the list of packages now shows the archive GM> *** The output of `list-packages' now includes the archive providing GM> each package. GM> [Though this will be self-evident, so I'm not sure it is worth GM> mentioning.] OK, omitted. >> +*** the list of packages can now be filtered by a keyword GM> I don't understand what this really means. The wording makes me think GM> it's somehow related to the list-packages command, but it does not seem GM> to be. OK, fixed. GM> Second general comment is that NEWS entries should be grammatical: start GM> with a capital, end with a full-stop. Thanks for the review! I pushed my changes as you suggested and hope they are OK. Ted ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: The next releases 2013-12-19 18:09 ` The next releases Stefan Monnier 2013-12-19 21:22 ` Stefan Monnier @ 2013-12-20 7:25 ` Chong Yidong 1 sibling, 0 replies; 27+ messages in thread From: Chong Yidong @ 2013-12-20 7:25 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> writes: >> I would have been happy to do it again. But I see Chong Yidong is >> back (yay!), so if he wants to do it; or if someone else wants to have >> a go, it's fine by me. > > Not sure if Yidong is volunteering, but in any case I'm very happy to > see him back as well. Thanks. I am back in the capacity of an ordinary contributor. Unfortunately, I will not have time to roll the pretests or help with other aspects of the release management process. But I will help work on the manuals. ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2013-12-23 13:05 UTC | newest] Thread overview: 27+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-05-17 5:07 bug#8680: Cocoa Emacs not mapping Clear key on aluminum keyboards Michael Marchionna 2011-05-17 17:34 ` bug#8680: nsterm.m does not distinguish key on the key pad Michael Marchionna 2012-11-04 3:34 ` Chong Yidong 2011-05-23 20:11 ` bug#8680: emacs 24.0 OS X keypad patch Michael Marchionna 2011-07-04 17:42 ` Stefan Monnier 2011-07-07 3:04 ` Adrian Robert 2011-07-07 14:55 ` Michael Marchionna 2013-12-10 22:13 ` bug#8680: Bug #8680 Andrew Stein 2013-12-10 22:40 ` bug#8680: Glenn Morris 2013-12-10 22:54 ` bug#8680: Andrew Stein 2013-12-11 4:53 ` bug#8680: Stefan Monnier 2013-12-12 0:48 ` bug#8680: Leo Liu 2013-12-13 21:50 ` bug#8680: releases Juri Linkov 2013-12-19 3:00 ` Leo Liu 2013-12-19 13:43 ` Stefan Monnier 2013-12-19 17:12 ` Glenn Morris 2013-12-19 18:09 ` The next releases Stefan Monnier 2013-12-19 21:22 ` Stefan Monnier 2013-12-19 22:31 ` Bastien 2013-12-20 2:12 ` Stefan Monnier 2013-12-22 0:54 ` Xue Fuqiao 2013-12-23 0:57 ` Glenn Morris 2013-12-23 1:37 ` Ted Zlatanov 2013-12-23 3:11 ` Glenn Morris 2013-12-23 3:47 ` Glenn Morris 2013-12-23 13:05 ` Ted Zlatanov 2013-12-20 7:25 ` Chong Yidong
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.