GNU bug report logs -
#14085
24.3.50; regression `C-c C-c' in `report-emacs-bug' no longer closes the report window
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 14085 in the body.
You can then email your comments to 14085 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#14085; Package
emacs.
(Fri, 29 Mar 2013 05:46:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Drew Adams" <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Fri, 29 Mar 2013 05:46:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Until recently, when you hit `C-c C-c' in the report buffer that buffer
was buried, and you were returned to the buffer that was shown when you
did `M-x report-emacs-bug'. This is no longer the case. (Well, the
buffer *sent...* is shown instead of *unsent...*, but it is the same
report. The point is that the report remains visible, instead of the
buffer you were working in before creating the bug report.)
(I use a mail client - Outlook, if that makes any difference.)
Note, BTW, that there is no change in the default value of
`message-kill-buffer-on-exit' - it is still nil, as it was in Emacs 24.3. And
the definition of `message-send-and-exit' (which is bound to `C-c C-c') has not
changed. Something else has introduced this regression in behavior.
Ah, it seems that this is perhaps the culprit: a change to `message-bury'.
It used to do this:
(defun message-bury (buffer)
"Bury this mail BUFFER."
(if message-return-action
(progn
(bury-buffer buffer)
(apply (car message-return-action) (cdr message-return-action)))
(with-current-buffer buffer (bury-buffer))))
And now it does this:
(defun message-bury (buffer)
"Bury this mail BUFFER."
(bury-buffer buffer)
(when message-return-action
(apply (car message-return-action) (cdr message-return-action))))
In my case, at least, `message-return-action' is nil. This means that the
`with-current-buffer buffer' is no longer used, so it seems like the wrong
buffer gets buried.
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
of 2013-03-23 on VBOX
Bzr revision: 112115 eliz <at> gnu.org-20130323093300-rjs0dgskxm9u0ya4
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (4.7) --no-opt --enable-checking --cflags
-IC:/emacs/libs/libXpm-3.5.10/include -IC:/emacs/libs/libXpm-3.5.10/src
-IC:/emacs/libs/libpng-dev_1.4.3-1_win32/include
-IC:/emacs/libs/zlib-dev_1.2.5-2_win32/include
-IC:/emacs/libs/giflib-4.1.4-1-lib/include
-IC:/emacs/libs/jpeg-6b-4-lib/include
-IC:/emacs/libs/tiff-3.8.2-1-lib/include
-IC:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
-IC:/emacs/libs/gnutls-3.1.10-w32/include
-IC:/emacs/libs/libiconv-1.14-2-mingw32-dev/include'
Merged 14085 14117.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Tue, 16 Apr 2013 19:36:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14085; Package
emacs.
(Thu, 25 Apr 2013 15:29:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 14085 <at> debbugs.gnu.org (full text, mbox):
Replying to the later, merged bug, #14117, Thierry V. wrote this on 4/16 about a
submitted patch:
> Tested and works fine.
Great. So when can we expect this regression fix to actually be applied?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14085; Package
emacs.
(Fri, 26 Apr 2013 07:45:01 GMT)
Full text and
rfc822 format available.
Message #13 received at submit <at> debbugs.gnu.org (full text, mbox):
"Drew Adams" <drew.adams <at> oracle.com> writes:
> Replying to the later, merged bug, #14117, Thierry V. wrote this on 4/16 about a
> submitted patch:
>
>> Tested and works fine.
>
> Great. So when can we expect this regression fix to actually be applied?
For facility, I resend the patch here, hope it will be applied.
diff --git a/lisp/gnus/message.el b/lisp/gnus/message.el
index 2b2a0a9..be2f671 100644
--- a/lisp/gnus/message.el
+++ b/lisp/gnus/message.el
@@ -4047,7 +4047,7 @@ It should typically alter the sending method in some way or other."
(actions message-exit-actions))
(when (and (message-send arg)
(buffer-name buf))
- (message-bury buf)
+ (message-bury)
(if message-kill-buffer-on-exit
(kill-buffer buf))
(message-do-actions actions)
@@ -4095,7 +4095,7 @@ Instead, just auto-save the buffer and then bury it."
(message-disassociate-draft)))
(message-do-actions actions))))
-(defun message-bury (buffer)
+(defun message-bury (&optional buffer)
"Bury this mail BUFFER."
(bury-buffer buffer)
(when message-return-action
--
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14085; Package
emacs.
(Sat, 04 May 2013 19:36:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 14085-done <at> debbugs.gnu.org (full text, mbox):
> For facility, I resend the patch here, hope it will be applied.
Installed,
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14085; Package
emacs.
(Sat, 04 May 2013 20:43:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 14085 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier wrote:
>> For facility, I resend the patch here, hope it will be applied.
>
> Installed,
The problem was already fixed. I don't see the point of this change.
What if message-send changes the buffer?
The rest of message-send-and-exit seems to be coded with that
possibility in mind. Since it runs message-send-actions, it can do
anything.
*** lisp/gnus/message.el 2013-04-26 07:59:32 +0000
--- lisp/gnus/message.el 2013-05-04 19:34:19 +0000
***************
*** 4047,4053 ****
(actions message-exit-actions))
(when (and (message-send arg)
(buffer-name buf))
! (message-bury buf)
(if message-kill-buffer-on-exit
(kill-buffer buf))
(message-do-actions actions)
--- 4047,4053 ----
(actions message-exit-actions))
(when (and (message-send arg)
(buffer-name buf))
! (message-bury)
(if message-kill-buffer-on-exit
(kill-buffer buf))
(message-do-actions actions)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14085; Package
emacs.
(Tue, 14 May 2013 14:29:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 14085 <at> debbugs.gnu.org (full text, mbox):
The bug thread suggests that this bug has been fixed, but it has not.
(Yes, I see that it is still classified as open.)
Just a reminder that it is still broken, as of this build:
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
of 2013-05-10 on ODIEONE
Bzr revision: 112542 rgm <at> gnu.org-20130510102119-fklj7xlajezey0tr
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (4.7) --no-opt --enable-checking --cflags
-IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib'
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
message-bury()
message-send-and-exit(nil)
call-interactively(message-send-and-exit nil nil)
command-execute(message-send-and-exit)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14085; Package
emacs.
(Tue, 14 May 2013 14:35:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 14085 <at> debbugs.gnu.org (full text, mbox):
> The bug thread suggests that this bug has been fixed, but it has not.
> (Yes, I see that it is still classified as open.)
I was wrong about thinking that it was still open. Glenn apparently closed it.
If the build I cited reflects the "fix", then please reopen and actually fix it.
It is still the case (in that build) that (a) the message buffer is not buried,
and (b) an error is raised because `message-bury' tries to treat nil as a
string.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14085; Package
emacs.
(Tue, 14 May 2013 17:23:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 14085 <at> debbugs.gnu.org (full text, mbox):
"Drew Adams" wrote:
> Just a reminder that it is still broken, as of this build:
>
> In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
> of 2013-05-10 on ODIEONE
> Bzr revision: 112542 rgm <at> gnu.org-20130510102119-fklj7xlajezey0tr
No, it isn't. Your build is either broken, or not the one you think.
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
> message-bury()
> message-send-and-exit(nil)
> call-interactively(message-send-and-exit nil nil)
> command-execute(message-send-and-exit)
Not possible since
http://lists.gnu.org/archive/html/emacs-diffs/2013-05/msg00063.html
Please make the modest investment to learn how to build Emacs.
It is a really small price for a project you are so invested it.
Until you do, you will repeatedly waste your time, and everyone else's.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14085; Package
emacs.
(Tue, 14 May 2013 18:15:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 14085 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> > Just a reminder that it is still broken, as of this build:
^^^^^^^^^^^^^^^^
> >
> > In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
> > of 2013-05-10 on ODIEONE
> > Bzr revision: 112542 rgm <at> gnu.org-20130510102119-fklj7xlajezey0tr
>
> No, it isn't. Your build is either broken, or not the one you think.
I'm guessing that the build is broken, then (see below).
I used that build to submit a new bug report this morning: #14398.
And the bug was manifested.
And I just now repeated it from `emacs -Q' using the same build.
Created a bug report, then C-c C-c.
1. I get the "Wrong type argument: stringp, nil" error.
2. The buffer *sent mail to bug-gnu-emacs <at> gnu.org* is still visible (not
buried).
(#2 is no doubt due to #1.)
> > Debugger entered--Lisp error: (wrong-type-argument stringp nil)
> > message-bury()
> > message-send-and-exit(nil)
> > call-interactively(message-send-and-exit nil nil)
> > command-execute(message-send-and-exit)
>
> Not possible since
> http://lists.gnu.org/archive/html/emacs-diffs/2013-05/msg00063.html
Happens. Everytime. With the build reported.
And please stop with the arrogant sermons.
It is 100% reproducible with this build, which post-dates the change you cite by
four days:
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
of 2013-05-10 on ODIEONE
Bzr revision: 112542 rgm <at> gnu.org-20130510102119-fklj7xlajezey0tr
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (4.7) --no-opt --enable-checking --cflags
-IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib'
The attached screenshot shows that the change you cite was NOT included in this
build (the arg for `message-bury' is still &optional), even though the URL you
cite lists the change as r112485 and this build uses r112542 (if I read these
things correctly).
However, if I visit message.el in this build, I see that the source-code change
WAS applied. I thought that might mean that the file was not recompiled for the
build. But the date/times for message.el[c] are identical (per `ls', at least).
So both the actual behavior and the doc (`C-h f') suggest that the fix was NOT
applied, but the source file shows it WAS. If you click the `message.el' link
from `C-h f message-bury' you get to the source file, where the signature
contradicts what is shown by `C-h f'.
So perhaps, as you so politely suggested ;-), the build is in some way broken.
I will test again with the next binary I get my hands on. Looking forward to
the fix. Thx.
[throw-emacs-bug-14085.PNG (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14085; Package
emacs.
(Tue, 14 May 2013 19:38:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 14085 <at> debbugs.gnu.org (full text, mbox):
> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Tue, 14 May 2013 11:14:22 -0700
>
> The attached screenshot shows that the change you cite was NOT included in this
> build (the arg for `message-bury' is still &optional), even though the URL you
> cite lists the change as r112485 and this build uses r112542 (if I read these
> things correctly).
>
> However, if I visit message.el in this build, I see that the source-code change
> WAS applied. I thought that might mean that the file was not recompiled for the
> build. But the date/times for message.el[c] are identical (per `ls', at least).
This is a tempest in a teapot.
The time stamp of the Lisp files in the binary zip are of no
significance, because making the zip copies all the Lisp files, and
thus changes their time stamp. (It should be clear to anyone that
real time stamps cannot be almost identical for all the Lisp files,
and certainly cannot follow one another in strict alphabetical order.)
Moreover, it is almost certain that message.el was not compiled after
the change, because message.elc has the wrong size: its size should be
232330, not 232320. Drew can make this sure himself by compiling
message.el and comparing the result with message.elc that came with
the zip file. I'm surprised such a simple test was not already done.
> I will test again with the next binary I get my hands on. Looking forward to
> the fix. Thx.
Another tempest in the same teapot: message.elc is not preloaded, so
you don't need to wait at all. Just byte compile and load it, and
then test.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14085; Package
emacs.
(Tue, 14 May 2013 20:05:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 14085 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> Moreover, it is almost certain that message.el was not compiled after
> the change, because message.elc has the wrong size: its size should be
> 232330, not 232320.
Like I said, a broken build.
If someone is distributing non-bootstrapped binaries of Emacs for public
consumption, please stop.
> I'm surprised such a simple test was not already done.
Are you really surprised? Because I'm not in the least surprised.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14085; Package
emacs.
(Tue, 14 May 2013 20:21:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 14085 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Date: Tue, 14 May 2013 16:04:52 -0400
>
> > I'm surprised such a simple test was not already done.
>
> Are you really surprised?
Yes, really.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14085; Package
emacs.
(Tue, 14 May 2013 20:43:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 14085 <at> debbugs.gnu.org (full text, mbox):
Yes, byte-compiling message.el fixes the problem.
The problem was in the build.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14085; Package
emacs.
(Tue, 14 May 2013 21:02:01 GMT)
Full text and
rfc822 format available.
Message #46 received at 14085 <at> debbugs.gnu.org (full text, mbox):
> If someone is distributing non-bootstrapped binaries of Emacs
> for public consumption, please stop.
FYI -
Dani Moncayo used to distribute Windows binaries here:
https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8
But the last of those builds dates from 2013/04/21.
This particular build is one distributed by Juanma Barranquero, here:
https://www.dropbox.com/sh/3pgcb3iiy8s9irl/c171Xhsd99
Ccing Juanma for his info. I'm not sure whether these builds are intended for
public consumption, but they have been very helpful, including by leading to
identifying Emacs bugs, some of which have been fixed (including some involving
emacs_backtrace.txt files that Juanma translated).
I have not been aware in the past that the .elc files in a build were not
necessarily up to date. I have not encountered that before. I have assumed
that if .elc files are delivered along with .el then they are up to date.
When I retest a bug with a new executable, I do not automatically recompile all
of the distributed Lisp files, just in case...
HTH.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14085; Package
emacs.
(Tue, 14 May 2013 21:43:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 14085 <at> debbugs.gnu.org (full text, mbox):
On Tue, May 14, 2013 at 10:04 PM, Glenn Morris <rgm <at> gnu.org> wrote:
> If someone is distributing non-bootstrapped binaries of Emacs for public
> consumption, please stop.
That broken build is mine, and it is not being distributed for public
consumption. I haven't advertised it, thought the URL has been
mentioned in a few bug reports, I think.
I mainly build it as a service to Drew, who is (for whatever reasons)
unable to build his own Emacs; so it will continue to be available at
that URL.
I don't usually bootstrap Emacs for each build because it is usually
unnecessary. If it is necessary, as in this case, once the problem is
noticed I will bootstrap it. No harm done, other than a spurious bug
report, which isn't exactly something new; we've seen quite a few bug
reports from people who privately builds from trunk and does not
always bootstrap; this case is no different. It is not a consequence
of my building binaries for Drew; it is a consequence of the way Emacs
building/bootstrap procedure works.
J
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14085; Package
emacs.
(Wed, 15 May 2013 06:58:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 14085 <at> debbugs.gnu.org (full text, mbox):
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Tue, 14 May 2013 23:41:18 +0200
> Cc: 14085 <at> debbugs.gnu.org
>
> It is not a consequence of my building binaries for Drew; it is a
> consequence of the way Emacs building/bootstrap procedure works.
What exactly in the way this procedure works causes such problems?
In general, "make bzr-update" in the lisp directory should recompile
every Lisp file whose .elc file is outdated. If you are saying this
is unreliable, please tell the details.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14085; Package
emacs.
(Wed, 15 May 2013 09:45:03 GMT)
Full text and
rfc822 format available.
Message #55 received at 14085 <at> debbugs.gnu.org (full text, mbox):
On Wed, May 15, 2013 at 8:56 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> What exactly in the way this procedure works causes such problems?
I was referring to the fact that, after some changes, the only way to
have a working Emacs is bootstrapping. The thing that exactly causes
such problems is that our build procedure does not always bootstrap to
save time... ;-)
> In general, "make bzr-update" in the lisp directory should recompile
> every Lisp file whose .elc file is outdated. If you are saying this
> is unreliable, please tell the details.
I'm saying that apparently in this case it failed, because the script
that I use to make Drew's binaries certainly runs "make bzr-update"
before "make dist". As for how it failed, I don't know because I
didn't keep the logs, alas.
J
Forcibly Merged 14085 14117 14386.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Sat, 08 Jun 2013 18:25:01 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 07 Jul 2013 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 11 years and 354 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.