[PATCH] Remove unused variable `command-debug-status'

[PATCH] Remove unused variable `command-debug-status'

[Philippe Vaucher]

Hello,

This is my first attempt at submitting a patch, so keep that in mind
in case I messed up somewhere.

I already did the copyright assignment dance and it was accepted &
sent to me the 2016-09-07, do I need to send the confirmation to
someone in order to post here?

Just to be sure, I should send emails to emacs-devel as plain text
right? no html?

Anyway, back to the subject: 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).

I fell on it while looking to solve another problem (which will be
discussed in another email).

Thanks,
Philippe

---
 doc/lispref/debugging.texi | 12 ------------
 src/callint.c              |  6 ------
 2 files changed, 18 deletions(-)

diff --git a/doc/lispref/debugging.texi b/doc/lispref/debugging.texi
index 2f83b40..f4e63ae 100644
--- a/doc/lispref/debugging.texi
+++ b/doc/lispref/debugging.texi
@@ -644,18 +644,6 @@ the debugger.
 This function is used only by the debugger.
 @end defun

-@defvar command-debug-status
-This variable records the debugging status of the current interactive
-command.  Each time a command is called interactively, this variable is
-bound to @code{nil}.  The debugger can set this variable to leave
-information for future debugger invocations during the same command
-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.
-@end defvar
-
 @defun backtrace-frame frame-number
 The function @code{backtrace-frame} is intended for use in Lisp
 debuggers.  It returns information about what computation is happening
diff --git a/src/callint.c b/src/callint.c
index 053ee6c..ccb5c6a 100644
--- a/src/callint.c
+++ b/src/callint.c
@@ -928,12 +928,6 @@ Maximum length of the history list is determined
by the value
 of `history-length', which see.  */);
   Vcommand_history = Qnil;

-  DEFVAR_LISP ("command-debug-status", Vcommand_debug_status,
-       doc: /* Debugging status of current interactive command.
-Bound each time `call-interactively' is called;
-may be set by the debugger as a reminder for itself.  */);
-  Vcommand_debug_status = Qnil;
-
   DEFVAR_LISP ("mark-even-if-inactive", Vmark_even_if_inactive,
        doc: /* Non-nil means you can use the mark even when inactive.
 This option makes a difference in Transient Mark mode.
-- 
2.10.0

Re: [PATCH] Remove unused variable `command-debug-status'

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]

On Wed, Sep 28, 2016, 6:47 AM Philippe Vaucher <philippe.vaucher@gmail.com>
wrote:

> Hello,
>
> This is my first attempt at submitting a patch, so keep that in mind
> in case I messed up somewhere.
>

Awesome! :)


> I already did the copyright assignment dance and it was accepted &
> sent to me the 2016-09-07, do I need to send the confirmation to
> someone in order to post here?
>

When I sent my first patch, I asked the person who helped commit that to
look up my name in the list of people who have assigned their copyright.


> Just to be sure, I should send emails to emacs-devel as plain text
> right? no html?
>

The patches should be sent as bug reports. That way, the patch and the
reasoning behind it stays together in a clean bug thread. Also the commit
to master can then refer to that (Bug#NNNNN). So, no guesswork is involved
if someone wants to understand why a particular commit was made.


> Anyway, back to the subject: this patch removes the variable ..
>

Do you want to take this discussion to a bug thread? Simply email the exact
same thing to bug-gnu-emacs@gnu.org.

> --

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 2282 bytes --]

Re: [PATCH] Remove unused variable `command-debug-status'

[Philippe Vaucher]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

>
> I already did the copyright assignment dance and it was accepted &
>> sent to me the 2016-09-07, do I need to send the confirmation to
>> someone in order to post here?
>>
>
> When I sent my first patch, I asked the person who helped commit that to
> look up my name in the list of people who have assigned their copyright.
>

Well, I had to do copyright assignements for ztree, but that was on github (
https://github.com/fourier/ztree/pull/33). Maybe @fourier will recognize
himself and warrant me then :-) (I'm Silex).



> The patches should be sent as bug reports. That way, the patch and the
> reasoning behind it stays together in a clean bug thread. Also the commit
> to master can then refer to that (Bug#NNNNN). So, no guesswork is involved
> if someone wants to understand why a particular commit was made.
>

Oh, I did that in the past but I thought that was meant for general bug
reporting. Do messages sent to bug-gnu-emacs@gnu.org also end on
emacs-devel? For information, messages like
https://lists.gnu.org/archive/html/emacs-devel/2016-09/msg00635.html don't
seem to follow this "patches as bug reports" philosophy.

Anyway, I found on
https://www.kernel.org/doc/Documentation/email-clients.txt that GMail's UI
is not good to send inline patches, so I'll send them to
bug-gnu-emacs@gnu.org as attachment instead (that or setup another client).

Thanks!
Philippe

[-- Attachment #2: Type: text/html, Size: 2413 bytes --]

Re: [PATCH] Remove unused variable `command-debug-status'

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]

On Wed, Sep 28, 2016 at 7:25 AM Philippe Vaucher <philippe.vaucher@gmail.com>
wrote:

> Well, I had to do copyright assignements for ztree, but that was on github
> (https://github.com/fourier/ztree/pull/33).
>

If the copyright assignment was to FSF, then someone having a fencepost
account can confirm if you are on the list. I cannot.

Oh, I did that in the past but I thought that was meant for general bug
> reporting.
>

Based on some recent discussions, the bug report email is meant for
everything: bug reports, feature requests, patch submissions, etc


> Do messages sent to bug-gnu-emacs@gnu.org also end on emacs-devel?
>

No. Those end up on the bug-gnu-emacs mailing list. I believe almost all
core developers subscribe to that. Normally, when I submit a patch, I CC
one or two people whose code I am modifying. (The new vc-region-history
command in emacs 25.1 is really useful for that.) If you do not get a
feedback in about a week or so, it might be useful copying emacs-devel
mailing list and referring them to the bug thread to see if anyone can
review and commit it for you.


> For information, messages like
> https://lists.gnu.org/archive/html/emacs-devel/2016-09/msg00635.html
> don't seem to follow this "patches as bug reports" philosophy.
>

Yeah, the patch submitter needs to ping emacs-devel if they don't get any
response to their update.


> Anyway, I found on
> https://www.kernel.org/doc/Documentation/email-clients.txt that GMail's
> UI is not good to send inline patches, so I'll send them to
> bug-gnu-emacs@gnu.org as attachment instead (that or setup another
> client).
>

I have always sent patches via Google Inbox. They ended up fine. The only
instance where I had to send a patch as an attachment was when it contained
both tab and space characters (I was trying to not mess up the original
whitespace). In such cases, you need to send the patch as an attachment.
Nowadays, with recent commits you will rarely find the tab chars in the
patch diffs (which is a good thing!). So inline patches work just fine.

For reading sanity, I always send emails via Gmail/Inbox without any rich
text formatting.
-- 

Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 3997 bytes --]

Re: [PATCH] Remove unused variable `command-debug-status'

[Philippe Vaucher]

[-- Attachment #1: Type: text/plain, Size: 1467 bytes --]

>
> Based on some recent discussions, the bug report email is meant for
> everything: bug reports, feature requests, patch submissions, etc
>

I wonder what's left for emacs-devel then ;)



> Do messages sent to bug-gnu-emacs@gnu.org also end on emacs-devel?
>>
>
> No. Those end up on the bug-gnu-emacs mailing list. I believe almost all
> core developers subscribe to that. Normally, when I submit a patch, I CC
> one or two people whose code I am modifying. (The new vc-region-history
> command in emacs 25.1 is really useful for that.) If you do not get a
> feedback in about a week or so, it might be useful copying emacs-devel
> mailing list and referring them to the bug thread to see if anyone can
> review and commit it for you.
>

Alright, thanks for the detailed information! Very appreciated.
vc-region-history is nice! until now for that I used magit-blame &
git-timemachine.



> I have always sent patches via Google Inbox. They ended up fine. The only
> instance where I had to send a patch as an attachment was when it contained
> both tab and space characters (I was trying to not mess up the original
> whitespace). In such cases, you need to send the patch as an attachment.
> Nowadays, with recent commits you will rarely find the tab chars in the
> patch diffs (which is a good thing!). So inline patches work just fine.
>

Well, I guess as long as word-wrap does not mangle your patch you are fine
sending them inline.

Kind regards,
Philippe

[-- Attachment #2: Type: text/html, Size: 2552 bytes --]

Re: [PATCH] Remove unused variable `command-debug-status'

[Alexey Veretennikov]

Hi,

Philippe has signed papers and it is confirmed by JohnW.
Thanks!

Philippe Vaucher <philippe.vaucher@gmail.com> writes:

>  I already did the copyright assignment dance and it was accepted &
>  sent to me the 2016-09-07, do I need to send the confirmation to
>  someone in order to post here?
>
>
>  When I sent my first patch, I asked the person who helped commit that to look up my name in the
>  list of people who have assigned their copyright. 
>
>
> Well, I had to do copyright assignements for ztree, but that was on github
> (https://github.com/fourier/ztree/pull/33). Maybe @fourier will recognize himself and warrant me then :-)
> (I'm Silex).
>
>  The patches should be sent as bug reports. That way, the patch and the reasoning behind it stays
>  together in a clean bug thread. Also the commit to master can then refer to that (Bug#NNNNN). So,
>  no guesswork is involved if someone wants to understand why a particular commit was made. 
>
>
> Oh, I did that in the past but I thought that was meant for general bug reporting. Do messages sent to
> bug-gnu-emacs@gnu.org also end on emacs-devel? For information, messages like
> https://lists.gnu.org/archive/html/emacs-devel/2016-09/msg00635.html don't seem to follow this "patches
> as bug reports" philosophy.
>
> Anyway, I found on https://www.kernel.org/doc/Documentation/email-clients.txt that GMail's UI is not
> good to send inline patches, so I'll send them to bug-gnu-emacs@gnu.org as attachment instead (that
> or setup another client).
>
> Thanks!
> Philippe
>

-- 
Br,
/Alexey