GNU bug report logs -
#24555
[PATCH] Remove unused variable `command-debug-status'
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24555 in the body.
You can then email your comments to 24555 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Wed, 28 Sep 2016 12:40:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Philippe Vaucher <philippe.vaucher <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 28 Sep 2016 12:40:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
For information, I did the procedure for copyright assignment to Emacs and
it is complete.
This patch removes the variable `command-debug-status', which really seems
to be unused since a long time to me (that's what "git -G
Vcommand-debug-status" says).
Philippe
[Message part 2 (text/html, inline)]
[0001-Remove-unused-variable-command-debug-status.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Wed, 28 Sep 2016 14:59:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 24555 <at> debbugs.gnu.org (full text, mbox):
> From: Philippe Vaucher <philippe.vaucher <at> gmail.com>
> Date: Wed, 28 Sep 2016 14:39:02 +0200
>
> For information, I did the procedure for copyright assignment to Emacs and it is complete.
Indeed, your assignment is on file.
> This patch removes the variable `command-debug-status', which really seems to be unused since a long time
> to me (that's what "git -G Vcommand-debug-status" says).
Thanks for bringing this up.
I looked into the history of this variable, and found that it was
still supported in Emacs 24.5, and was removed during development of
Emacs 25 by this commit:
commit 0e4857b7d84f958f66e726ed57b824427b272681
Author: Stefan Monnier <monnier <at> iro.umontreal.ca>
Date: Tue May 27 20:09:14 2014 -0400
* src/callint.c (Ffuncall_interactively): New function.
(Qfuncall_interactively): New var.
(Qcall_interactively): Remove.
(Fcall_interactively): Use it.
(syms_of_callint): Defsubr it.
* lisp/subr.el (internal--funcall-interactively): New.
(internal--call-interactively): Remove.
(called-interactively-p): Detect funcall-interactively instead of
call-interactively.
* lisp/simple.el (repeat-complex-command): Use funcall-interactively.
(repeat-complex-command--called-interactively-skip): Remove.
As you see, the commit log doesn't mention the removal of the
variable. Stefan, was it removed on purpose? If so, can you tell
why?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Wed, 28 Sep 2016 16:57:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 24555 <at> debbugs.gnu.org (full text, mbox):
> As you see, the commit log doesn't mention the removal of the
> variable. Stefan, was it removed on purpose? If so, can you tell
> why?
Hmm... I can't remember making such a conscious choice, no.
Must have been an oversight on my part.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Wed, 28 Sep 2016 17:26:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 24555 <at> debbugs.gnu.org (full text, mbox):
> > As you see, the commit log doesn't mention the removal of the
> > variable. Stefan, was it removed on purpose? If so, can you tell
> > why?
>
> Hmm... I can't remember making such a conscious choice, no.
> Must have been an oversight on my part.
What is/was the use of `command-debug-status' ? its docstring does not
really help figure much what data was stored there and what it was
used for.
Philippe
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Wed, 28 Sep 2016 20:07:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 24555 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Philippe Vaucher <philippe.vaucher <at> gmail.com>, 24555 <at> debbugs.gnu.org
> Date: Wed, 28 Sep 2016 12:14:24 -0400
>
> > As you see, the commit log doesn't mention the removal of the
> > variable. Stefan, was it removed on purpose? If so, can you tell
> > why?
>
> Hmm... I can't remember making such a conscious choice, no.
> Must have been an oversight on my part.
That's what I thought.
So restoring the specbind call that was lost in that commit is TRT, do
you agree?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Wed, 28 Sep 2016 20:12:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 24555 <at> debbugs.gnu.org (full text, mbox):
> From: Philippe Vaucher <philippe.vaucher <at> gmail.com>
> Date: Wed, 28 Sep 2016 19:24:41 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 24555 <at> debbugs.gnu.org
>
> What is/was the use of `command-debug-status' ? its docstring does not
> really help figure much what data was stored there and what it was
> used for.
Which parts of the documentation are not clear?
In a nutshell, it's a variable provided for storing arbitrary data
that persists for the duration of the current interactive command.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Thu, 29 Sep 2016 00:13:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 24555 <at> debbugs.gnu.org (full text, mbox):
> So restoring the specbind call that was lost in that commit is TRT, do
> you agree?
Could be. At the same time, I have no recollection of ever noticing
this variable anywhere, and reading its docstring doesn't trigger any
recollection of a scenario where I could make use of it, so maybe it can
just be dropped.
What's the use case?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Thu, 29 Sep 2016 00:17:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 24555 <at> debbugs.gnu.org (full text, mbox):
> In a nutshell, it's a variable provided for storing arbitrary data
> that persists for the duration of the current interactive command.
Can't think of any situation where I'd want/need that. The name seems
to indicate it could be used that way in the context of debugging, but
even in that kind of scenario I'm unable to come up with a use-case.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Thu, 29 Sep 2016 06:51:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 24555 <at> debbugs.gnu.org (full text, mbox):
>> In a nutshell, it's a variable provided for storing arbitrary data
>> that persists for the duration of the current interactive command.
>
> Can't think of any situation where I'd want/need that. The name seems
> to indicate it could be used that way in the context of debugging, but
> even in that kind of scenario I'm unable to come up with a use-case.
That's why I asked what was the use of such variable... even if we
restore the code that sets it, it is not used anywhere else.
The commit history suggest it might have been useful near the start of
the development of Emacs, but I don't think it is anymore.
I vote for dropping it.
Philippe
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Thu, 29 Sep 2016 15:06:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 24555 <at> debbugs.gnu.org (full text, mbox):
> From: Philippe Vaucher <philippe.vaucher <at> gmail.com>
> Date: Thu, 29 Sep 2016 08:50:08 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 24555 <at> debbugs.gnu.org
>
> > Can't think of any situation where I'd want/need that. The name seems
> > to indicate it could be used that way in the context of debugging, but
> > even in that kind of scenario I'm unable to come up with a use-case.
>
> That's why I asked what was the use of such variable... even if we
> restore the code that sets it, it is not used anywhere else.
>
> The commit history suggest it might have been useful near the start of
> the development of Emacs, but I don't think it is anymore.
>
> I vote for dropping it.
I don't think we can drop features just because no use case presents
itself for the moment. IME, a debugging aid could be of no use until
you are in a situation where it is something to kill for.
But we don't need to argue about this now, because the way we remove
features from Emacs is by first declaring them obsolete, and keeping
them like that for a few releases; we don't just drop them without a
previous notice.
So I'm okay with declaring this variable obsolete, and even removing
its documentation from the manual, but we do need to restore the
specbind call that was deleted.
Philippe, can you do this, please? It should be done on the emacs-25
branch, since the specbind was deleted in 25.1.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Fri, 30 Sep 2016 09:10:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 24555 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> So I'm okay with declaring this variable obsolete, and even removing
> its documentation from the manual, but we do need to restore the
> specbind call that was deleted.
>
> Philippe, can you do this, please? It should be done on the emacs-25
> branch, since the specbind was deleted in 25.1.
>
Okay, I'll start working on this.
Philippe
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Sat, 01 Oct 2016 13:11:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 24555 <at> debbugs.gnu.org (full text, mbox):
>> Philippe, can you do this, please? It should be done on the emacs-25
>> branch, since the specbind was deleted in 25.1.
Okay, here we go.
https://github.com/Silex/emacs/compare/emacs-25~2...Silex:emacs-25
https://github.com/Silex/emacs/commit/c8566ff77a347e7efc4cb2819cd7f58b68876e6f.patch
https://github.com/Silex/emacs/commit/e34b40dc4d12a0d806e59ccbf682b0980480ff88.patch
What is your prefered way to receive patches?
---
src/callint.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/callint.c b/src/callint.c
index 053ee6c..4652151 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 (Vcommand_debug_status, Qnil);
+
+ val = Ffuncall (nargs, args);
val = unbind_to (speccount, val);
SAFE_FREE ();
return val;
---
doc/lispref/debugging.texi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/doc/lispref/debugging.texi b/doc/lispref/debugging.texi
index 2f83b40..322acd0 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 should be removed in future versions.
@end defvar
@defun backtrace-frame frame-number
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Sat, 01 Oct 2016 15:51:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 24555 <at> debbugs.gnu.org (full text, mbox):
> From: Philippe Vaucher <philippe.vaucher <at> gmail.com>
> Date: Sat, 1 Oct 2016 15:09:33 +0200
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 24555 <at> debbugs.gnu.org
>
> >> Philippe, can you do this, please? It should be done on the emacs-25
> >> branch, since the specbind was deleted in 25.1.
>
> Okay, here we go.
>
> https://github.com/Silex/emacs/compare/emacs-25~2...Silex:emacs-25
>
> https://github.com/Silex/emacs/commit/c8566ff77a347e7efc4cb2819cd7f58b68876e6f.patch
> https://github.com/Silex/emacs/commit/e34b40dc4d12a0d806e59ccbf682b0980480ff88.patch
>
> What is your prefered way to receive patches?
Either "git diff" with the commit log message prepended, or
"git format-patch", whatever works best for you.
I think your patch lacks the call to make-obsolete-variable. We need
that to warn users of this variable about it being obsoleted.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Sat, 01 Oct 2016 16:13:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 24555 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Either "git diff" with the commit log message prepended, or
> "git format-patch", whatever works best for you.
Alright.
> I think your patch lacks the call to make-obsolete-variable. We need
> that to warn users of this variable about it being obsoleted.
Well, I thought about it but was not sure about various things, so I didn't
do it. Here are the things I'm unsure about:
(make-obsolete-variable OBSOLETE-NAME CURRENT-NAME WHEN
&optional ACCESS-TYPE)
Make the byte-compiler warn that OBSOLETE-NAME is obsolete.
The warning will say that CURRENT-NAME should be used instead.
If CURRENT-NAME is a string, that is the ‘use instead’ message.
WHEN should be a string indicating when the variable
was first made obsolete, for example a date or a release number.
1. Where should I make the `make-obsolete-variable` call (in which
file)? Given it's defined in callint.c it's not really obvious in which .el
it should go.
2. I don't have a "current name". Should I make CURRENT-NAME something
like "This variable will be removed in the future"? Should I pass "nil"?
3. What WHEN release number should I use? 25.2 ?
Thanks,
Philippe
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Sat, 01 Oct 2016 17:40:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 24555 <at> debbugs.gnu.org (full text, mbox):
> From: Philippe Vaucher <philippe.vaucher <at> gmail.com>
> Date: Sat, 1 Oct 2016 18:12:06 +0200
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 24555 <at> debbugs.gnu.org
>
> > I think your patch lacks the call to make-obsolete-variable. We need
> > that to warn users of this variable about it being obsoleted.
>
> Well, I thought about it but was not sure about various things, so I didn't do it. Here are the things I'm unsure
> about:
>
> (make-obsolete-variable OBSOLETE-NAME CURRENT-NAME WHEN &optional ACCESS-TYPE)
>
> Make the byte-compiler warn that OBSOLETE-NAME is obsolete.
> The warning will say that CURRENT-NAME should be used instead.
> If CURRENT-NAME is a string, that is the ‘use instead’ message.
> WHEN should be a string indicating when the variable
> was first made obsolete, for example a date or a release number.
>
> 1 Where should I make the `make-obsolete-variable` call (in which file)? Given it's defined in callint.c it's not
> really obvious in which .el it should go.
I'd say in subr.el; there's a bunch of those there already.
> 2 I don't have a "current name". Should I make CURRENT-NAME something like "This variable will be
> removed in the future"? Should I pass "nil"?
The former, but I think the string should start with a lower-case
letter, as it will be displayed after the standard text saying the
variable is obsolete. I suggest to experiment with different strings
and find the one which makes the most sense.
> 3 What WHEN release number should I use? 25.2 ?
Yes, 25.2.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Sun, 02 Oct 2016 17:10:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 24555 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hum.
I wanted to use `git send-email` and now of course it created 3 tickets.
So basically, I messed up. Sorry, is there a way I can close those 3
tickets myself?
Which brings me to a second question, can I use `git send-email` and send
it to 24555 <at> debbugs.gnu.org instead or should I really copy-paste the
patches?
Thanks,
Philippe
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Sun, 02 Oct 2016 18:33:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 24555 <at> debbugs.gnu.org (full text, mbox):
On Sun, Oct 2, 2016 at 1:08 PM, Philippe Vaucher
<philippe.vaucher <at> gmail.com> wrote:
> Hum.
>
> I wanted to use `git send-email` and now of course it created 3 tickets.
>
> So basically, I messed up. Sorry, is there a way I can close those 3 tickets
> myself?
Send email to <control <at> debbugs.gnu.org> with contents
merge xxxxx yyyyy zzzzz
quit
Where x, y, and z are the 3 bug numbers.
>
> Which brings me to a second question, can I use `git send-email` and send it
> to 24555 <at> debbugs.gnu.org instead or should I really copy-paste the patches?
Both should work, the problem with using "git send-email" is that the
mails sometimes arrive out of order. I usually use "git format-patch"
and send as attachments.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Sun, 02 Oct 2016 18:49:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 24555 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> > So basically, I messed up. Sorry, is there a way I can close those 3
> tickets
> > myself?
>
> Send email to <control <at> debbugs.gnu.org> with contents
>
> merge xxxxx yyyyy zzzzz
> quit
>
> Where x, y, and z are the 3 bug numbers.
Will do, thanks!
> > Which brings me to a second question, can I use `git send-email` and
> send it
> > to 24555 <at> debbugs.gnu.org instead or should I really copy-paste the
> patches?
>
> Both should work, the problem with using "git send-email" is that the
> mails sometimes arrive out of order. I usually use "git format-patch"
> and send as attachments.
>
Okay, I'll attach them from now on.
Thanks,
Philippe
[Message part 2 (text/html, inline)]
Forcibly Merged 24555 24588 24589 24590.
Request was from
Philippe Vaucher <philippe.vaucher <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Sun, 02 Oct 2016 19:36:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Sun, 02 Oct 2016 19:42:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 24555 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> > 1 Where should I make the `make-obsolete-variable` call (in which file)?
> Given it's defined in callint.c it's not
> > really obvious in which .el it should go.
>
> I'd say in subr.el; there's a bunch of those there already.
>
> > 2 I don't have a "current name". Should I make CURRENT-NAME something
> like "This variable will be
> > removed in the future"? Should I pass "nil"?
>
> The former, but I think the string should start with a lower-case
> letter, as it will be displayed after the standard text saying the
> variable is obsolete. I suggest to experiment with different strings
> and find the one which makes the most sense.
>
> > 3 What WHEN release number should I use? 25.2 ?
>
> Yes, 25.2.
>
Okay, here attached are the patches.
Philippe
[Message part 2 (text/html, inline)]
[0001-Restore-command-debug-status-functionality.patch (text/x-patch, attachment)]
[0002-Deprecate-variable-command-debug-status.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Mon, 03 Oct 2016 07:14:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 24555 <at> debbugs.gnu.org (full text, mbox):
> From: Philippe Vaucher <philippe.vaucher <at> gmail.com>
> Date: Sun, 2 Oct 2016 21:41:18 +0200
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 24555 <at> debbugs.gnu.org
>
> diff --git a/doc/lispref/debugging.texi b/doc/lispref/debugging.texi
> index 2f83b40..322acd0 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 should be removed in future versions.
I think "will be removed" is better here.
> diff --git a/lisp/subr.el b/lisp/subr.el
> index e9e19d3..271cd2f 100644
> --- a/lisp/subr.el
> +++ b/lisp/subr.el
> @@ -1377,6 +1377,8 @@ 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 "should be removed in future versions" "25.2")
And here I'd reword the message:
"; expect it to be removed in a future version"
Can someone please push this to the emacs-25 branch in Philippe's
name?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Mon, 03 Oct 2016 07:38:01 GMT)
Full text and
rfc822 format available.
Message #67 received at 24555 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> > +This variable is obsolete and should be removed in future versions.
>
> I think "will be removed" is better here.
>
> > +(make-obsolete-variable 'command-debug-status "should be removed in
> future versions" "25.2")
>
> And here I'd reword the message:
>
> "; expect it to be removed in a future version"
>
Here are the new patches with your modifications.
Also viewable at
https://github.com/Silex/emacs/compare/emacs-25~2...Silex:emacs-25
Philippe
[Message part 2 (text/html, inline)]
[0001-Restore-command-debug-status-functionality.patch (text/x-patch, attachment)]
[0002-Deprecate-variable-command-debug-status.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Mon, 03 Oct 2016 07:43:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 24555 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> Here are the new patches with your modifications.
>
> Also viewable at https://github.com/Silex/emacs/compare/emacs-25~2...
> Silex:emacs-25
>
And again new patches without a typo :-)
Philippe
[Message part 2 (text/html, inline)]
[0001-Restore-command-debug-status-functionality.patch (text/x-patch, attachment)]
[0002-Deprecate-variable-command-debug-status.patch (text/x-patch, attachment)]
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Tue, 04 Oct 2016 14:44:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Philippe Vaucher <philippe.vaucher <at> gmail.com>
:
bug acknowledged by developer.
(Tue, 04 Oct 2016 14:44:02 GMT)
Full text and
rfc822 format available.
Message #75 received at 24555-done <at> debbugs.gnu.org (full text, mbox):
> From: Philippe Vaucher <philippe.vaucher <at> gmail.com>
> Date: Mon, 3 Oct 2016 09:42:14 +0200
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 24555 <at> debbugs.gnu.org
>
> And again new patches without a typo :-)
Thanks, I pushed this to the emacs-25 branch, and I'm marking this
bug done.
Please note that your patch had a fatal flaw: specbind needs a
(quoted) symbol, not its value. Using Vcommand_debug_status there
produced a broken binary that would display an error message and
become unresponsive. See what I actually committed for the details.
Also, the obsolescence warning needed some minor tweaks (it turns out
that my advice to prepend a semi-colon was a bad idea, as a semi-colon
and a newline are produced by Emacs automatically).
Please always test the build after you patch it, to make sure the
behavior is correct and no bugs creep in.
Finally, in the future please provide commit log messages for the
changes formatted in the ChanegLog style, as described in CONTRIBUTE.
I wrote them for this commit, please see the commit for the details of
the formatting we use.
Thanks a lot for working on this.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Tue, 04 Oct 2016 14:44:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Philippe Vaucher <philippe.vaucher <at> gmail.com>
:
bug acknowledged by developer.
(Tue, 04 Oct 2016 14:44:02 GMT)
Full text and
rfc822 format available.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Tue, 04 Oct 2016 14:44:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
Philippe Vaucher <philippe.vaucher <at> gmail.com>
:
bug acknowledged by developer.
(Tue, 04 Oct 2016 14:44:03 GMT)
Full text and
rfc822 format available.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Tue, 04 Oct 2016 14:44:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
Philippe Vaucher <philippe.vaucher <at> gmail.com>
:
bug acknowledged by developer.
(Tue, 04 Oct 2016 14:44:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Tue, 04 Oct 2016 15:20:03 GMT)
Full text and
rfc822 format available.
Message #93 received at 24555-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> Please note that your patch had a fatal flaw: specbind needs a
> (quoted) symbol, not its value. Using Vcommand_debug_status there
> produced a broken binary that would display an error message and
> become unresponsive. See what I actually committed for the details.
>
Ah, you're right I missread the patch that removed Vcommand_debug_status
and assumed "Q" variables got renamed to "V" in the emacs 25 transition. I
understand now that variables and symbols are different things :-) I should
have verified.
> Please always test the build after you patch it, to make sure the
> behavior is correct and no bugs creep in.
>
Yes, I should have. Sorry.
> Finally, in the future please provide commit log messages for the
> changes formatted in the ChanegLog style, as described in CONTRIBUTE.
> I wrote them for this commit, please see the commit for the details of
> the formatting we use.
>
Well, the commit f2144eef does not contain any ChangeLog entries... maybe
you forgot to stage these changes? But yes, I understand what you mean.
Regards,
Philippe
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Tue, 04 Oct 2016 15:47:02 GMT)
Full text and
rfc822 format available.
Message #96 received at 24555-done <at> debbugs.gnu.org (full text, mbox):
> From: Philippe Vaucher <philippe.vaucher <at> gmail.com>
> Date: Tue, 4 Oct 2016 17:18:23 +0200
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 24555-done <at> debbugs.gnu.org
>
> Finally, in the future please provide commit log messages for the
> changes formatted in the ChanegLog style, as described in CONTRIBUTE.
> I wrote them for this commit, please see the commit for the details of
> the formatting we use.
>
> Well, the commit f2144eef does not contain any ChangeLog entries... maybe you forgot to stage these
> changes? But yes, I understand what you mean.
Not ChangeLog entries, but commit log message formatted as ChangeLog.
IOW, this:
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#24555
; Package
emacs
.
(Tue, 04 Oct 2016 15:56:02 GMT)
Full text and
rfc822 format available.
Message #99 received at 24555-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> > Well, the commit f2144eef does not contain any ChangeLog entries...
> maybe you forgot to stage these
> > changes? But yes, I understand what you mean.
>
> Not ChangeLog entries, but commit log message formatted as ChangeLog.
>
Ah, right. That is indeed a very complete change description!
Thanks,
Philippe
[Message part 2 (text/html, inline)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 02 Nov 2016 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 8 years and 226 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.