From ec6e4b9d1e5a215d9dfe1026730dbb23f1935615 Mon Sep 17 00:00:00 2001 From: Eli Zaretskii Date: Tue, 4 Oct 2016 08:59:37 +0300 Subject: [PATCH 1/4] ; Minor addition to CONTRIBUTE * CONTRIBUTE (http): Mention that doc fixes should always go to the release branch. --- CONTRIBUTE | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/CONTRIBUTE b/CONTRIBUTE index a70682f29ab..a02acadc73f 100644 --- a/CONTRIBUTE +++ b/CONTRIBUTE @@ -189,6 +189,10 @@ If you are fixing a bug that exists in the current release, be sure to commit it to the release branch; it will be merged to the master branch later by the gitmerge function. +Documentation fixes (in doc strings, in manuals, and in comments) +should always go to the release branch, if the documentation to be +fixed exists and is relevant to the release-branch codebase. + However, if you know that the change will be difficult to merge to the master (e.g., because the code on master has changed a lot), you can apply the change to both master and branch yourself. It could also From f2144eef19611fb2189c44c055e1d539b7a53f08 Mon Sep 17 00:00:00 2001 From: Philippe Vaucher Date: Tue, 4 Oct 2016 17:34:51 +0300 Subject: [PATCH 2/4] Restore 'command-debug-status' functionality * src/callint.c (Fcall_interactively): Bind command-debug-status to nil. This restores functionality inadvertently removed in Emacs 25.1. (Bug#24555) * lisp/subr.el (command-debug-status): Declare obsolete. * doc/lispref/debugging.texi (Internals of Debugger): Document that 'command-debug-status' is obsolete. --- doc/lispref/debugging.texi | 2 ++ lisp/subr.el | 3 +++ src/callint.c | 6 +++++- 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/doc/lispref/debugging.texi b/doc/lispref/debugging.texi index 2f83b4040fa..c88a2fa60e0 100644 --- a/doc/lispref/debugging.texi +++ b/doc/lispref/debugging.texi @@ -654,6 +654,8 @@ invocation. The advantage of using this variable rather than an ordinary global variable is that the data will never carry over to a subsequent command invocation. + +This variable is obsolete and will be removed in future versions. @end defvar @defun backtrace-frame frame-number diff --git a/lisp/subr.el b/lisp/subr.el index 9c717e16b94..a3aef2e4a5c 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -1377,6 +1377,9 @@ is converted into a string by expressing it in decimal." (make-obsolete 'process-filter-multibyte-p nil "23.1") (make-obsolete 'set-process-filter-multibyte nil "23.1") +(make-obsolete-variable 'command-debug-status + "expect it to be removed in a future version." "25.2") + ;; Lisp manual only updated in 22.1. (define-obsolete-variable-alias 'executing-macro 'executing-kbd-macro "before 19.34") diff --git a/src/callint.c b/src/callint.c index 053ee6cdaa5..c0afc7b20bd 100644 --- a/src/callint.c +++ b/src/callint.c @@ -837,7 +837,10 @@ invoke it. If KEYS is omitted or nil, the return value of kset_last_command (current_kboard, save_last_command); { - Lisp_Object val = Ffuncall (nargs, args); + Lisp_Object val; + specbind (Qcommand_debug_status, Qnil); + + val = Ffuncall (nargs, args); val = unbind_to (speccount, val); SAFE_FREE (); return val; @@ -894,6 +897,7 @@ syms_of_callint (void) DEFSYM (Qhandle_shift_selection, "handle-shift-selection"); DEFSYM (Qread_number, "read-number"); DEFSYM (Qfuncall_interactively, "funcall-interactively"); + DEFSYM (Qcommand_debug_status, "command-debug-status"); DEFSYM (Qenable_recursive_minibuffers, "enable-recursive-minibuffers"); DEFSYM (Qmouse_leave_buffer_hook, "mouse-leave-buffer-hook"); From 01669ad9a67af27101decc387e44407e0a08bcf2 Mon Sep 17 00:00:00 2001 From: Eli Zaretskii Date: Tue, 4 Oct 2016 22:12:08 +0300 Subject: [PATCH 3/4] Avoid crashes when setting the cursor * src/xdisp.c (display_and_set_cursor): Don't index glyphs of a glyph row if hpos is out of valid bounds. This avoids crashes in some rare cases. (Bug#24614) --- src/xdisp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/xdisp.c b/src/xdisp.c index adbb6e5088b..42c6fb75efa 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -28486,8 +28486,7 @@ display_and_set_cursor (struct window *w, bool on, } glyph = NULL; - if (!glyph_row->exact_window_width_line_p - || (0 <= hpos && hpos < glyph_row->used[TEXT_AREA])) + if (0 <= hpos && hpos < glyph_row->used[TEXT_AREA]) glyph = glyph_row->glyphs[TEXT_AREA] + hpos; eassert (input_blocked_p ()); From 4b347fe5368aedc161e172bd110e05e2f7f37463 Mon Sep 17 00:00:00 2001 From: Karl Fogel Date: Tue, 4 Oct 2016 16:03:27 -0500 Subject: [PATCH 4/4] Clarify that doc fixes are okay in feature freeze * CONTRIBUTE (branches): Explain that doc fixes are always safe, even on a release branch in feature freeze. Tweak wording of paragraph after that to avoid a misleading contrast. --- CONTRIBUTE | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTE b/CONTRIBUTE index a02acadc73f..c12f0cc08db 100644 --- a/CONTRIBUTE +++ b/CONTRIBUTE @@ -191,9 +191,11 @@ branch later by the gitmerge function. Documentation fixes (in doc strings, in manuals, and in comments) should always go to the release branch, if the documentation to be -fixed exists and is relevant to the release-branch codebase. +fixed exists and is relevant to the release-branch codebase. Doc +fixes are always considered "safe" -- even when a release branch is in +feature freeze, it can still receive doc fixes. -However, if you know that the change will be difficult to merge to the +When you know that the change will be difficult to merge to the master (e.g., because the code on master has changed a lot), you can apply the change to both master and branch yourself. It could also happen that a change is cherry-picked from master to the release