bug#14085: 24.3.50; regression `C-c C-c' in `report-emacs-bug' no longer closes the report window

bug#14085: 24.3.50; regression `C-c C-c' in `report-emacs-bug' no longer closes the report window

[Drew Adams]

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@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'
 

bug#14117: 24.3.50; message buffer is not deleted when sending email

[Thierry Volpiatto]

Hi,

when I do C-x m (compose mail) and I send my email (C-c C-c) the buffer
is not deleted.



In GNU Emacs 24.3.50.3 (x86_64-unknown-linux-gnu, X toolkit)
 of 2013-03-26 on dell-14z
Windowing system distributor `The X.Org Foundation', version 11.0.11103000
System Description:	Ubuntu 12.04.2 LTS

Configured using:
 `configure --with-x-toolkit=lucid --without-toolkit-scroll-bars'

Important settings:
  value of $LANG: fr_FR.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  recentf-mode: t
  winner-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  auto-image-file-mode: t
  show-paren-mode: t
  display-time-mode: t
  savehist-mode: t
  minibuffer-depth-indicate-mode: t
  eldoc-mode: t
  diff-auto-refine-mode: t
  helm-mode: t
  shell-dirtrack-mode: t
  helm-adaptative-mode: t
  helm-match-plugin-mode: t
  tooltip-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<mouse-1> t é l é c h a r g e m e n t . <return> <return> 
E n SPC c r o i s a n t SPC l e s SPC d o i g t s SPC 
p o u r SPC q u e SPC c e SPC s o i t SPC l e SPC b 
o n SPC p i l o t e . <return> <return> E n s u i t 
e SPC t u SPC c o p i e s SPC l e SPC f i c h i e r 
SPC t é l é c h a r g é SPC s u r SPC u n e SPC c l 
é , SPC e t SPC t u SPC l e SPC c o p i e s SPC s u 
r SPC l a SPC v i e l l e SPC <backspace> <backspace> 
<backspace> <backspace> i l l e SPC m a c h i n e SPC 
M-( s u r SPC l e SPC b u r e a u <right> SPC e t SPC 
t u SPC d o u b l e SPC c l i q u e SPC d e s s u s 
SPC p o u r SPC i n s t a l l e r SPC l e SPC p i l 
o t e . C-c C-c <down> <down> <down> <up> <up> <up> 
<up> <down> <down> <down> <down> <down> <down> <down> 
C-c C-k C-x m t h i e r r y <tab> <down> <down> <down> 
<return> <down> <return> t e s t <down> <down> <down> 
<down> t e s t C-c C-c C-c C-k M-x r e p o r t <re
turn>

Recent messages:
Delivering message to flash.capinfo@gmail.com...done
Beginning of buffer
Gnus not running; using plain Message mode
Mark set [2 times]
Sending...
Mark set [2 times]
Sending via mail...
Delivering message to tvolpiatto@yahoo.fr...
Sending...done
Delivering message to tvolpiatto@yahoo.fr...done

Load-path shadows:
/usr/local/share/emacs/24.3.50/lisp/gnus/.dir-locals hides ~/elisp/magit/.dir-locals
~/elisp/auctex/lpath hides ~/elisp/emacs-wget/lpath
/usr/local/share/emacs/24.3.50/lisp/emacs-lisp/tq hides ~/elisp/emms/lisp/tq

Features:
(shadow emacsbug canlock flow-fill flyspell ispell url-handlers
helm-command conf-mode cc-langs cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs qp epa-mail
help-mode gnus-fun gnus-html url-http url-gw url-auth gnus-gravatar
gravatar url-cache smiley gnus-cite mm-archive mail-extr gnus-async
gnus-bcklg gnus-ml nndraft nnmh utf-7 nnimap utf7 nnml nnfolder
parse-time netrc network-stream starttls tls gnus-agent gnus-srvr
gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view
mml-smime smime dig nntp gnus-cache gnus-dired nnir gnus-sum gnus-group
gnus-undo nnmail mail-source nnoo gnus-start gnus-spec gnus-int
gnus-range gnus-win view recentf ido make-mode vc-rcs sh-script smie
executable vc-git naquadah-theme em-smart em-unix em-script em-prompt
em-ls em-hist em-pred em-glob em-dirs em-cmpl em-basic em-banner
em-alias esh-var esh-io esh-cmd esh-opt esh-ext esh-proc esh-arg
esh-groups eshell esh-module esh-mode esh-util align-let git-gutter
server winner net-utils undo-tree diff slime-xref-browser slime-banner
slime-tramp slime-asdf slime-fancy slime-fontifying-fu slime-package-fu
slime-references slime-scratch slime-presentations slime-fuzzy
slime-fancy-inspector slime-c-p-c slime-editing-commands slime-autodoc
slime-parse slime-repl image-file newsticker newst-treeview tree-widget
newst-plainview newst-reader newst-ticker newst-backend xdvi-search
preview-latex pcomplete-extension em-term term disp-table ehelp electric
helm-ipython helm-elisp helm-eval python rx whitespace paren time avoid
savehist wicd-mode dbus smtpmail-async smtpmail sendmail helm-async
persistent-sessions config-w3m w3m doc-view jka-compr image-mode
timezone w3m-hist w3m-fb bookmark-w3m w3m-ems w3m-ccl ccl w3m-favicon
w3m-image w3m-proc w3m-util w3m-load boxquote markdown-mode iterator
google-maps google-maps-static google-maps-geocode google-maps-base json
simple-call-tree iedit-rect rect iedit iedit-lib zop-to-char smallurl
mm-url gnus gnus-ems nnheader rectangle-utils tv-utils async pcvs
pcvs-parse pcvs-info pcvs-defs ewoc mb-depth ioccur cl-info slime
hyperspec slime-autoloads tex-site auto-loads esh-toggle flymake
eldoc-eval eldoc no-word dired-extension emms-mpd-config
emms-playlist-limit emms-volume emms-volume-amixer emms-i18n
emms-history emms-score emms-stream-info emms-metaplaylist-mode
emms-bookmarks emms-cue emms-mode-line-icon emms-browser sort
emms-playlist-sort emms-last-played emms-player-xine emms-player-mpd tq
emms-playing-time emms-lyrics emms-url hl-line emms-tag-editor emms-mark
emms-mode-line emms-cache emms-info-ogginfo emms-info-mp3info
emms-playlist-mode emms-player-vlc emms-player-mplayer emms-info
emms-streams later-do emms-source-playlist emms-source-file
emms-player-simple emms-setup emms emms-compat magit-blame magit-stgit
magit-bisect magit-key-mode magit diff-mode log-edit pcvs-util add-log
htmlize-hack htmlize muse-colors muse-docbook muse-texinfo texnfo-upd
texinfo muse-latex muse-html muse-xml-common muse-wiki cus-edit
cus-start cus-load muse-publish muse-project muse-protocols muse-regexps
wid-edit muse muse-nested-tags muse-mode muse-autoloads
org-config-thierry ob-sh org-crypt cal-china lunar solar cal-dst
cal-bahai cal-islam cal-hebrew holidays hol-loaddefs vc-hg org-wl
org-w3m org-vm org-rmail org-mhe org-mew org-irc org-jsinfo org-infojs
org-html org-exp ob-exp org-exp-blocks org-info org-gnus org-docview
org-bibtex bibtex org-bbdb org-agenda appt diary-lib diary-loaddefs
org-annotation-helper org-capture org-mks remember org-remember
org-datetree addressbook-bookmark message rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums
mailabbrev mail-utils gmm-utils mailheader firefox-protocol
bookmark-firefox-handler bookmark-extensions org ob-tangle ob-ref ob-lob
ob-table org-footnote org-src ob-comint ob-keys org-pcomplete org-list
org-faces org-entities noutline outline easy-mmode org-version
ob-emacs-lisp ob org-compat org-macs ob-eval org-loaddefs find-func
cal-menu calendar cal-loaddefs bookmark pp init-helm-thierry helm-mode
helm-ls-git helm-descbinds helm-ls-hg helm-files image-dired tramp
tramp-compat tramp-loaddefs trampver shell pcomplete format-spec dired-x
dired-aux ffap thingatpt helm-buffers helm-elscreen helm-tags
helm-bookmark helm-adaptative helm-info helm-net browse-url xml url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util url-parse url-vars mailcap helm-plugin helm-help
helm-match-plugin helm-grep wgrep-helm wgrep helm-regexp grep
helm-external helm-utils warnings dired compile comint ansi-color ring
helm-locate helm advice help-fns helm-config helm-aliases epa-file epa
derived epg epg-config auth-source eieio byte-opt bytecomp byte-compile
cconv gnus-util time-date mm-util mail-prsvr password-cache usage-memo
w3m-wget info easymenu cl-macs gv edmacro kmacro cl nadvice cl-lib
tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
register page menu-bar rfn-eshadow timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face macroexp files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind inotify
dynamic-setting system-font-setting font-render-setting x-toolkit x
multi-tty emacs)

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#14117: 24.3.50; message buffer is not deleted when sending email

[Drew Adams]

> when I do C-x m (compose mail) and I send my email (C-c C-c) 
> the buffer is not deleted.

Dunno, but this sounds a bit like bug #14085.

(But at least in the case of bug #14085 the buffer should not be killed but just
buried.  IOW, the previous behavior should be restored.)

bug#14117: 24.3.50; message buffer is not deleted when sending email

[Thierry Volpiatto]

"Drew Adams" <drew.adams@oracle.com> writes:

>> when I do C-x m (compose mail) and I send my email (C-c C-c) 
>> the buffer is not deleted.
>
> Dunno, but this sounds a bit like bug #14085.
>
> (But at least in the case of bug #14085 the buffer should not be killed but just
> buried.  IOW, the previous behavior should be restored.)

It is (was) maybe buried, I never verify this.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#14117: 24.3.50; message buffer is not deleted when sending email

[Thierry Volpiatto]

"Drew Adams" <drew.adams@oracle.com> writes:

>> when I do C-x m (compose mail) and I send my email (C-c C-c) 
>> the buffer is not deleted.
>
> Dunno, but this sounds a bit like bug #14085.
>
> (But at least in the case of bug #14085 the buffer should not be killed but just
> buried.  IOW, the previous behavior should be restored.)

Looks like for some reasons, `burry-buffer' called with no BUFFER arg in
`message-bury' fix the problem.

diff --git a/lisp/gnus/message.el b/lisp/gnus/message.el
index 2b2a0a9..bd9a1a7 100644
--- a/lisp/gnus/message.el
+++ b/lisp/gnus/message.el
@@ -4097,7 +4097,7 @@ Instead, just auto-save the buffer and then bury it."
 
 (defun message-bury (buffer)
   "Bury this mail BUFFER."
-  (bury-buffer buffer)
+  (bury-buffer)
   (when message-return-action
     (apply (car message-return-action) (cdr message-return-action))))


-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#14117: 24.3.50; message buffer is not deleted when sending email

[Glenn Morris]

Thierry Volpiatto wrote:

> Looks like for some reasons, `burry-buffer' called with no BUFFER arg in
> `message-bury' fix the problem.
>
> diff --git a/lisp/gnus/message.el b/lisp/gnus/message.el
> index 2b2a0a9..bd9a1a7 100644
> --- a/lisp/gnus/message.el
> +++ b/lisp/gnus/message.el
> @@ -4097,7 +4097,7 @@ Instead, just auto-save the buffer and then bury it."
>  
>  (defun message-bury (buffer)
>    "Bury this mail BUFFER."
> -  (bury-buffer buffer)
> +  (bury-buffer)
>    (when message-return-action
>      (apply (car message-return-action) (cdr message-return-action))))

That can't be the right solution, given that message-bury takes a BUFFER
argument.

Presumably the 2013-03-18 "minor cleanup" isn't (a cleanup). Why not
just revert it?

http://thread.gmane.org/gmane.emacs.gnus.general/83058

bug#14117: 24.3.50; message buffer is not deleted when sending email

[Thierry Volpiatto]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> "Drew Adams" <drew.adams@oracle.com> writes:
>
>>> when I do C-x m (compose mail) and I send my email (C-c C-c) 
>>> the buffer is not deleted.
>>
>> Dunno, but this sounds a bit like bug #14085.
>>
>> (But at least in the case of bug #14085 the buffer should not be killed but just
>> buried.  IOW, the previous behavior should be restored.)
>
> Looks like for some reasons, `burry-buffer' called with no BUFFER arg in
> `message-bury' fix the problem.
>
> diff --git a/lisp/gnus/message.el b/lisp/gnus/message.el
> index 2b2a0a9..bd9a1a7 100644
> --- a/lisp/gnus/message.el
> +++ b/lisp/gnus/message.el
> @@ -4097,7 +4097,7 @@ Instead, just auto-save the buffer and then bury it."
>  
>  (defun message-bury (buffer)
>    "Bury this mail BUFFER."
> -  (bury-buffer buffer)
> +  (bury-buffer)
>    (when message-return-action
>      (apply (car message-return-action) (cdr message-return-action))))

And the old definition of 24.3 seems to confirm that:

(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))))
                                 ^^^^^^^^^^^

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#14117: 24.3.50; message buffer is not deleted when sending email

[Thierry Volpiatto]

Glenn Morris <rgm@gnu.org> writes:

> Thierry Volpiatto wrote:
>
>> Looks like for some reasons, `burry-buffer' called with no BUFFER arg in
>> `message-bury' fix the problem.
>>
>> diff --git a/lisp/gnus/message.el b/lisp/gnus/message.el
>> index 2b2a0a9..bd9a1a7 100644
>> --- a/lisp/gnus/message.el
>> +++ b/lisp/gnus/message.el
>> @@ -4097,7 +4097,7 @@ Instead, just auto-save the buffer and then bury it."
>>  
>>  (defun message-bury (buffer)
>>    "Bury this mail BUFFER."
>> -  (bury-buffer buffer)
>> +  (bury-buffer)
>>    (when message-return-action
>>      (apply (car message-return-action) (cdr message-return-action))))
>
> That can't be the right solution, given that message-bury takes a BUFFER
> argument.
You are right,
I thought just removing this arg, but it is needed in
`message-dont-send', where I think the buffer should not disappear from
window.
 
> Presumably the 2013-03-18 "minor cleanup" isn't (a cleanup). Why not
> just revert it?

Yes, I don't know why this have been changed, the 24.3 version works
just fine.

One other fix would be to leave `message-bury' as it is and call it in
`message-send-and-exit' with no arg (not tested but should work).

> http://thread.gmane.org/gmane.emacs.gnus.general/83058
Here using (with-current-buffer buffer ... just for not letting BUFFER
arg unused is not a solution IMO.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#14117: 24.3.50; message buffer is not deleted when sending email

[Thierry Volpiatto]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> One other fix would be to leave `message-bury' as it is and call it in
> `message-send-and-exit' with no arg (not tested but should work).
I meant `message-bury' nearly unchanged (use an optional arg)

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 

bug#14117: 24.3.50; message buffer is not deleted when sending email

[Thierry Volpiatto]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> One other fix would be to leave `message-bury' as it is and call it in
>> `message-send-and-exit' with no arg (not tested but should work).
> I meant `message-bury' nearly unchanged (use an optional arg)
>
> 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

Tested and works fine.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#14085: 24.3.50; regression `C-c C-c' in `report-emacs-bug' no longer closes thereport window

[Drew Adams]

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?

bug#14085: 24.3.50; regression `C-c C-c' in `report-emacs-bug' no longer closes thereport window

[Thierry Volpiatto]

"Drew Adams" <drew.adams@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 

bug#14117: 24.3.50; message buffer is not deleted when sending email

[Glenn Morris]

Glenn Morris wrote:

> Presumably the 2013-03-18 "minor cleanup" isn't (a cleanup). Why not
> just revert it?

Done.

bug#14085: 24.3.50; regression `C-c C-c' in `report-emacs-bug' no longer closes thereport window

[Stefan Monnier]

> For facility, I resend the patch here, hope it will be applied.

Installed,


        Stefan

bug#14085: 24.3.50; regression `C-c C-c' in `report-emacs-bug' no longer closes thereport window

[Glenn Morris]

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)

bug#14085: 24.3.50; regression `C-c C-c' in `report-emacs-bug' no longer closes thereportwindow

[Drew Adams]

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@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)

bug#14085: 24.3.50; regression `C-c C-c' in `report-emacs-bug' no longer closesthereportwindow

[Drew Adams]

> 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.

bug#14085: 24.3.50; regression `C-c C-c' in `report-emacs-bug' no longer closes thereportwindow

[Glenn Morris]

"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@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.

bug#14085: 24.3.50; regression `C-c C-c' in `report-emacs-bug' no longer closesthereportwindow

[Drew Adams]

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

> > 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@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@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@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.

[-- Attachment #2: throw-emacs-bug-14085.PNG --]
[-- Type: image/png, Size: 52702 bytes --]

bug#14085: 24.3.50; regression `C-c C-c' in `report-emacs-bug' no longer closesthereportwindow

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@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.

bug#14085: 24.3.50; regression `C-c C-c' in `report-emacs-bug' no longer closesthereportwindow

[Glenn Morris]

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.

bug#14085: 24.3.50; regression `C-c C-c' in `report-emacs-bug' no longer closesthereportwindow

[Eli Zaretskii]

> From: Glenn Morris <rgm@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.

bug#14085: 24.3.50; regression `C-c C-c' in `report-emacs-bug' no longer closesthereportwindow

[Drew Adams]

Yes, byte-compiling message.el fixes the problem.
The problem was in the build.

bug#14085: 24.3.50; regression `C-c C-c' in `report-emacs-bug' nolonger closesthereportwindow

[Drew Adams]

> 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.

bug#14085: 24.3.50; regression `C-c C-c' in `report-emacs-bug' no longer closesthereportwindow

[Juanma Barranquero]

On Tue, May 14, 2013 at 10:04 PM, Glenn Morris <rgm@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

bug#14085: 24.3.50; regression `C-c C-c' in `report-emacs-bug' no longer closesthereportwindow

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Tue, 14 May 2013 23:41:18 +0200
> Cc: 14085@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.

bug#14085: 24.3.50; regression `C-c C-c' in `report-emacs-bug' no longer closesthereportwindow

[Juanma Barranquero]

On Wed, May 15, 2013 at 8:56 AM, Eli Zaretskii <eliz@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