GNU bug report logs - #10134
24.0.91; Typo, (elisp) `Text from Minibuffer'

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 10134 in the body.
You can then email your comments to 10134 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.91; Typo, (elisp) `Text from Minibuffer'
Date: Fri, 25 Nov 2011 06:45:59 -0800

 -- Variable: minibuffer-local-map
     This
 
     is the default local keymap for reading from the minibuffer.  By
     default, it makes the following bindings:
 
... The bug is the extra newlines after "This".

In GNU Emacs 24.0.91.1 (i386-mingw-nt5.1.2600) of 2011-11-21 on MARVIN
 Windowing system distributor `Microsoft Corp.', version 5.1.2600
 configured using `configure --with-gcc (4.6) --no-opt --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-2.10.1/include --ldflags
 -LD:/devel/emacs/libs/gnutls-2.10.1/lib'
 

Message #8 received at 10134 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 10134 <at> debbugs.gnu.org
Subject: Re: 24.0.91; Typo, (elisp) `Text from Minibuffer'
Date: Sat, 24 Dec 2011 13:05:42 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Fri, 25 Nov 2011 06:45:59 -0800
> 
>  -- Variable: minibuffer-local-map
>      This
>  
>      is the default local keymap for reading from the minibuffer.  By
>      default, it makes the following bindings:
>  
> ... The bug is the extra newlines after "This".

I cannot reproduce this, neither in Emacs 24.0.91, nor with the
current trunk.  What I see is this:

 -- Variable: minibuffer-local-map
     This is the default local keymap for reading from the minibuffer.
     By default, it makes the following bindings:

Looking at the relevant Info file (elisp-3), I don't see any newlines
there, either.

Do you see the problem in "emacs -Q"?  If not, what minimal set of
customizations is needed to reproduce the problem?

Message #11 received at 10134 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 10134 <at> debbugs.gnu.org
Subject: RE: 24.0.91; Typo, (elisp) `Text from Minibuffer'
Date: Sat, 24 Dec 2011 08:05:09 -0800

[Message part 1 (text/plain, inline)]

 > I cannot reproduce this, neither in Emacs 24.0.91, nor with the
> current trunk.  What I see is this:
> 
>  -- Variable: minibuffer-local-map
>      This is the default local keymap for reading from the minibuffer.
>      By default, it makes the following bindings:
> 
> Looking at the relevant Info file (elisp-3), I don't see any newlines
> there, either.
> 
> Do you see the problem in "emacs -Q"?  If not, what minimal set of
> customizations is needed to reproduce the problem?

Yes, `emacs -Q'.  Recipe: go to the node; look at it.
See attached screenshot.

[throw-emacs-bug-10134.png (image/png, attachment)]

Message #14 received at 10134 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 10134 <at> debbugs.gnu.org
Subject: Re: 24.0.91; Typo, (elisp) `Text from Minibuffer'
Date: Sat, 24 Dec 2011 18:53:28 +0200

[Message part 1 (text/plain, inline)]

tags 10134 unreproducible
quit

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <10134 <at> debbugs.gnu.org>
> Date: Sat, 24 Dec 2011 08:05:09 -0800
> 
>  > I cannot reproduce this, neither in Emacs 24.0.91, nor with the
> > current trunk.  What I see is this:
> > 
> >  -- Variable: minibuffer-local-map
> >      This is the default local keymap for reading from the minibuffer.
> >      By default, it makes the following bindings:
> > 
> > Looking at the relevant Info file (elisp-3), I don't see any newlines
> > there, either.
> > 
> > Do you see the problem in "emacs -Q"?  If not, what minimal set of
> > customizations is needed to reproduce the problem?
> 
> Yes, `emacs -Q'.  Recipe: go to the node; look at it.
> See attached screenshot.

Sorry, not reproducible.  See the attached screenshot.  It's probably
something specific to that system's setup, although I'm puzzled what
kind of setup can have such a profound effect on the Emacs display.

[no-emacs-bug.png (image/png, attachment)]

Message #19 received at 10134 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 10134 <at> debbugs.gnu.org
Subject: RE: 24.0.91; Typo, (elisp) `Text from Minibuffer'
Date: Sat, 24 Dec 2011 09:17:58 -0800

> tags 10134 unreproducible
> quit
> 
> > Yes, `emacs -Q'.  Recipe: go to the node; look at it.
> > See attached screenshot.
> 
> Sorry, not reproducible.  See the attached screenshot.  It's probably
> something specific to that system's setup, although I'm puzzled what
> kind of setup can have such a profound effect on the Emacs display.

Dunno what you mean by "that system's setup".  Are you referring to the system
used to build Emacs or the system where I invoke `emacs -Q'?

Did you actually try it using the cited Emacs version/build?  It is the latest
Windows binary made available on emacs-devel.  It is simple to download it and
test with `emacs -Q'.

In GNU Emacs 24.0.92.1 (i386-mingw-nt5.1.2600) of 2011-12-06 on MARVIN
 Windowing system distributor `Microsoft Corp.', version 5.1.2600
 configured using `configure --with-gcc (4.6) --no-opt --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-2.10.1/include --ldflags
 -LD:/devel/emacs/libs/gnutls-2.10.1/lib'

This is the build zip:
http://alpha.gnu.org/gnu/emacs/windows/emacs-20111206-r106632-bin-i386.zip

This is the announcement post to emacs-devel <at> gnu.org:
http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00142.html

It is 100% reproducible with that build.  If the bug has been fixed since then,
fine.  But please try to reproduce it using the build cited in the bug report.
Do that, and my guess is you will have no problem at all seeing it.

If you test only with the pretest or the latest trunk then you are probably not
testing with the same Emacs sources, let alone the same binary build.

Message #22 received at 10134 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 10134 <at> debbugs.gnu.org
Subject: Re: 24.0.91; Typo, (elisp) `Text from Minibuffer'
Date: Sat, 24 Dec 2011 19:34:07 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <10134 <at> debbugs.gnu.org>
> Date: Sat, 24 Dec 2011 09:17:58 -0800
> 
> Did you actually try it using the cited Emacs version/build?  It is the latest
> Windows binary made available on emacs-devel.  It is simple to download it and
> test with `emacs -Q'.

I used my own compiled binary of the same version.

Please look at the file info/elisp-3 you have, and tell me:

  . Do you see the extra newline in that file?

  . If you do, what do the first 2 lines of that file say?

The file I have doesn't have the extra newline, and its beginning says
this:

  This is /home/cyd/trunk/doc/lispref/../../info/elisp, produced by
  makeinfo version 4.13 from /home/cyd/trunk/doc/lispref/elisp.texi.

IOW, this file was produced by Chong when he created the pretest
tarball.  Maybe yours was produced by a different version of makeinfo
which has some bug.  That would explain why we see such a different
picture.

> If you test only with the pretest or the latest trunk then you are probably not
> testing with the same Emacs sources, let alone the same binary build.

I don't see it, neither in the current trunk nor in the 24.0.91
pretest.  The binary was built by me, but I don't think a different
binary can produce such an effect on display.  The Info files in the
pretest are produced by whoever made the pretest, in this case Chong,
and are not supposed to be regenerated during the build.  However,
perhaps Christoph somehow ended regenerating them when he built the
binary you used, and maybe he used some different version of makeinfo.

Message #25 received at 10134 <at> debbugs.gnu.org (full text, mbox):

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10134 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'
Date: Sat, 24 Dec 2011 10:48:27 -0700

On 12/24/2011 10:34 AM, Eli Zaretskii wrote:

> I don't see it, neither in the current trunk nor in the 24.0.91
> pretest.  The binary was built by me, but I don't think a different
> binary can produce such an effect on display.  The Info files in the
> pretest are produced by whoever made the pretest, in this case Chong,
> and are not supposed to be regenerated during the build.  However,
> perhaps Christoph somehow ended regenerating them when he built the
> binary you used, and maybe he used some different version of makeinfo.

Sorry, I actually ran `make bootstrap' and `make info' when building the 
pretest from Chong's tarball. I use the same build/package script 
(Python) for the pretest that I wrote for the weekly builds. I can take 
these steps out for the pretest though.

C:\Program Files (x86)\GnuWin32\bin>makeinfo --version
makeinfo (GNU texinfo) 4.8

Copyright (C) 2004 Free Software Foundation, Inc.
There is NO warranty.  You may redistribute this software
under the terms of the GNU General Public License.
For more information about these matters, see the files named COPYING.

Message #30 received at 10134 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christoph Scholtes <cschol2112 <at> googlemail.com>
Cc: 10134 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'
Date: Sat, 24 Dec 2011 19:57:34 +0200

> Date: Sat, 24 Dec 2011 10:48:27 -0700
> From: Christoph Scholtes <cschol2112 <at> googlemail.com>
> CC: Drew Adams <drew.adams <at> oracle.com>, 10134 <at> debbugs.gnu.org
> 
> On 12/24/2011 10:34 AM, Eli Zaretskii wrote:
> 
> > I don't see it, neither in the current trunk nor in the 24.0.91
> > pretest.  The binary was built by me, but I don't think a different
> > binary can produce such an effect on display.  The Info files in the
> > pretest are produced by whoever made the pretest, in this case Chong,
> > and are not supposed to be regenerated during the build.  However,
> > perhaps Christoph somehow ended regenerating them when he built the
> > binary you used, and maybe he used some different version of makeinfo.
> 
> Sorry, I actually ran `make bootstrap' and `make info' when building the 
> pretest from Chong's tarball. I use the same build/package script 
> (Python) for the pretest that I wrote for the weekly builds. I can take 
> these steps out for the pretest though.

Yes, please do.  The pretest zip should use the *.elc and Info files
from the original source tarball, and so should the release zip.

> C:\Program Files (x86)\GnuWin32\bin>makeinfo --version
> makeinfo (GNU texinfo) 4.8
> 
> Copyright (C) 2004 Free Software Foundation, Inc.
> There is NO warranty.  You may redistribute this software
> under the terms of the GNU General Public License.
> For more information about these matters, see the files named COPYING.

Might as well upgrade, you can find the latest Texinfo here:

  http://sourceforge.net/projects/ezwinports/files/

It does work for me ;-)

Message #33 received at 10134 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 'Christoph Scholtes' <cschol2112 <at> googlemail.com>, 10134 <at> debbugs.gnu.org
Subject: RE: 24.0.91; Typo, (elisp) `Text from Minibuffer'
Date: Sat, 24 Dec 2011 12:00:35 -0800

> Please look at the file info/elisp-3 you have, and tell me:
> 
>   . Do you see the extra newline in that file?

Yes:

 -- Variable: minibuffer-local-map
     This

     is the default local keymap for reading from the minibuffer.  By
     default, it makes the following bindings:

    `C-j'
          `exit-minibuffer'
...

>   . If you do, what do the first 2 lines of that file say?

This is ./../../info/elisp, produced by makeinfo version 4.8 from
./elisp.texi.

> The file I have doesn't have the extra newline, and its beginning says
> this:
> 
>   This is /home/cyd/trunk/doc/lispref/../../info/elisp, produced by
>   makeinfo version 4.13 from /home/cyd/trunk/doc/lispref/elisp.texi.
> 
> IOW, this file was produced by Chong when he created the pretest
> tarball.  Maybe yours was produced by a different version of makeinfo
> which has some bug.  That would explain why we see such a different
> picture.

HTH.  CCing Christoph, for his info.

Message #36 received at 10134 <at> debbugs.gnu.org (full text, mbox):

From: Christoph Scholtes <cschol2112 <at> googlemail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10134 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'
Date: Sat, 24 Dec 2011 13:06:25 -0700

On 12/24/2011 10:57 AM, Eli Zaretskii wrote:

> Yes, please do.  The pretest zip should use the *.elc and Info files
> from the original source tarball, and so should the release zip.

Will do.

> Might as well upgrade, you can find the latest Texinfo here:
>
>    http://sourceforge.net/projects/ezwinports/files/
>
> It does work for me ;-)

How about that. :) Thanks alot for doing this!

Message #39 received at 10134 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: cschol2112 <at> googlemail.com, 10134 <at> debbugs.gnu.org
Subject: Re: 24.0.91; Typo, (elisp) `Text from Minibuffer'
Date: Sat, 24 Dec 2011 22:38:55 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <10134 <at> debbugs.gnu.org>,
>         "'Christoph Scholtes'" <cschol2112 <at> googlemail.com>
> Date: Sat, 24 Dec 2011 12:00:35 -0800
> 
> > Please look at the file info/elisp-3 you have, and tell me:
> > 
> >   . Do you see the extra newline in that file?
> 
> Yes:
> 
>  -- Variable: minibuffer-local-map
>      This
> 
>      is the default local keymap for reading from the minibuffer.  By
>      default, it makes the following bindings:
> 
>     `C-j'
>           `exit-minibuffer'
> ...
> 
> >   . If you do, what do the first 2 lines of that file say?
> 
> This is ./../../info/elisp, produced by makeinfo version 4.8 from
> ./elisp.texi.

So now everything is clear: this is a bug in Texinfo 4.8 that is fixed
in later versions.  The bug is triggered by this trickery in the
manual's sources:

  @defvar minibuffer-local-map
  This
  @anchor{Definition of minibuffer-local-map}
  @c avoid page break at anchor; work around Texinfo deficiency
  is the default local keymap for reading from the minibuffer.  By
  default, it makes the following bindings:

Evidently, makeinfo 4.8 leaves an empty line where there was the
@anchor.  The @anchor was put in this strange place to make sure the
page break is not inserted in the printed manual, thus making the
cross-references to it point to the wrong page.  I don't know if this
trickery is still needed nowadays.

Message #42 received at 10134 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Christoph Scholtes <cschol2112 <at> googlemail.com>, 10134 <at> debbugs.gnu.org
Subject: Re: bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'
Date: Sun, 25 Dec 2011 11:23:18 +0100

On Sat, Dec 24, 2011 at 18:57, Eli Zaretskii <eliz <at> gnu.org> wrote:

> Might as well upgrade, you can find the latest Texinfo here:
>
>  http://sourceforge.net/projects/ezwinports/files/
>
> It does work for me ;-)

Thanks!

    Juanma

Message #45 received at 10134 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: cschol2112 <at> googlemail.com, 10134 <at> debbugs.gnu.org
Subject: Re: bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'
Date: Sun, 25 Dec 2011 06:01:52 -0500

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Sun, 25 Dec 2011 11:23:18 +0100
> Cc: Christoph Scholtes <cschol2112 <at> googlemail.com>, 10134 <at> debbugs.gnu.org
> 
> On Sat, Dec 24, 2011 at 18:57, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > Might as well upgrade, you can find the latest Texinfo here:
> >
> >  http://sourceforge.net/projects/ezwinports/files/
> >
> > It does work for me ;-)
> 
> Thanks!

You are welcome.

Message #50 received at 10134 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> gnu.org>
Cc: 10134 <at> debbugs.gnu.org
Subject: RE: bug#10134 acknowledged by developer (close 10134) |
	[debbugs-tracker] Processed: close 10134
Date: Sat, 11 Feb 2012 06:59:25 -0800

Another bug closure with no explanation mail sent to the filer.  Just a reminder
that this is not really kosher.

Citing Bob Proulx, from the last time you did this: 

"See the documentation for the 'close' command to see that
 it explicitly calls out this use case as a problem and asks
 maintainers to ensure that they communicate, probably by
 sending a separate message, why the bug is being closed.
 See the section 'close bugnumber'
 http://debbugs.gnu.org/server-control.html."

(Yes, I read the bug thread and I realize the bug has now been fixed.)

FYI, these are the only closure messages I received, both automatic:

> -----Original Message-----
> From: GNU bug Tracking System
> Sent: Saturday, February 11, 2012 6:06 AM
> To: Chong Yidong Cc: tracker <at> debbugs.gnu.org
> Subject: [debbugs-tracker] Processed: close 10134
> 
> Processing commands for control <at> debbugs.gnu.org:
> 
> > close 10134
> bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'
> bug closed, send any further explanations to
> 10134 <at> debbugs.gnu.org and "Drew Adams" <drew.adams <at> oracle.com>
> 
> > thanks
> Stopping processing here.
> 
> Please contact help-debbugs <at> gnu.org if you need assistance.
> 
> GNU bugs database, http://debbugs.gnu.org/



> -----Original Message-----
> From: GNU bug Tracking System Sent: Saturday, February 11, 2012 6:06 AM
> Subject: bug#10134 acknowledged by developer (close 10134)
> 
> This is an automatic notification regarding your bug report
> #10134: 24.0.91; Typo, (elisp) `Text from Minibuffer',
> which was filed against the emacs package.
> 
> Thank you for your report, which has now been closed.
> You can view the full report at
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10134
> 
> If you require further information, please followup to 
> 10134 <at> debbugs.gnu.org.
> 
> debbugs.gnu.org maintainers
> (administrator, GNU bugs database)

Message #53 received at 10134 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 10134 <at> debbugs.gnu.org
Subject: Re: bug#10134: acknowledged by developer (close 10134) |
	[debbugs-tracker] Processed: close 10134
Date: Sun, 12 Feb 2012 01:36:38 +0800

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

> Another bug closure with no explanation mail sent to the filer.
> Just a reminder that this is not really kosher.

I hereby declare, under the religious authority vested in me by the
Church of Emacs, that closing bugs with no explanation mail does not
violate kosher laws.

> (Yes, I read the bug thread and I realize the bug has now been fixed.)

... especially when the objection is this silly.

Message #56 received at 10134 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Chong Yidong'" <cyd <at> gnu.org>
Cc: 10134 <at> debbugs.gnu.org, 'Bob Proulx' <bob <at> proulx.com>
Subject: RE: bug#10134: acknowledged by developer (close 10134) |
	[debbugs-tracker] Processed: close 10134
Date: Sat, 11 Feb 2012 10:03:06 -0800

> > Another bug closure with no explanation mail sent to the filer.
> > Just a reminder that this is not really kosher.
> 
> I hereby declare, under the religious authority vested in me by the
> Church of Emacs, that closing bugs with no explanation mail does not
> violate kosher laws.

http://debbugs.gnu.org/server-control.html:

 close bugnumber [ fixed-version ] 
 Close bug report #bugnumber. 
 A notification is sent to the user who reported the bug, but
 (in contrast to mailing bugnumber-done) the text of the mail
 which caused the bug to be closed is not included in that
 notification. The maintainer who closes a report should ensure,
 probably by sending a separate message, that the user who
 reported the bug knows why it is being closed.

Not providing an explanation for the closure requires the bug filer to look up
the bug number, consult the bug thread on line, and reread the thread looking
for an explanation.

When you close a bug it might be obvious to you why it was closed, but it is not
obvious to a user who receives only an automatic control message saying it was
closed.  The only information available to the user in that message is the bug's
number and subject line.

> > (Yes, I read the bug thread and I realize the bug has now 
> > been fixed.)
> 
> ... especially when the objection is this silly.

Silly and all a big joke to you perhaps.  But to obtain that knowledge of what
the closure meant (the bug was fixed) I still had to look up the bug thread and
reread it.  If the automatic message had said that it was fixed then I would not
have needed to do that.  Perhaps that part of the automatic messaging could be
improved.

If a bug has been fixed, knowledge of that fact is often all the filer needs.
If it has not been fixed (e.g. was declared not-a-bug or wishlist or wont-fix),
then additional explanation is typically needed.

Message #59 received at 10134 <at> debbugs.gnu.org (full text, mbox):

From: Jason Rumney <jasonr <at> gnu.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 10134 <at> debbugs.gnu.org, 'Chong Yidong' <cyd <at> gnu.org>,
	'Bob Proulx' <bob <at> proulx.com>
Subject: Re: bug#10134: acknowledged by developer (close 10134) |
	[debbugs-tracker] Processed: close 10134
Date: Sun, 12 Feb 2012 10:57:52 +0800

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

>  The maintainer who closes a report should ensure, probably by sending
>  a separate message, that the user who reported the bug knows why it
>  is being closed.

Which is exactly what happened, according to your comment:

> (Yes, I read the bug thread and I realize the bug has now been fixed.)

Message #62 received at 10134 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Jason Rumney'" <jasonr <at> gnu.org>
Cc: 10134 <at> debbugs.gnu.org, 'Chong Yidong' <cyd <at> gnu.org>,
	'Bob Proulx' <bob <at> proulx.com>
Subject: RE: bug#10134: acknowledged by developer (close 10134) |
	[debbugs-tracker] Processed: close 10134
Date: Sat, 11 Feb 2012 20:01:45 -0800

> >  The maintainer who closes a report should ensure, probably 
> > by sending a separate message, that the user who reported
> > the bug knows why it is being closed.
> 
> Which is exactly what happened, according to your comment:
> 
> > (Yes, I read the bug thread and I realize the bug has now 
> > been fixed.)

Uh, nope.

I wrote that in my message that pointed out that I received no message
explaining the closure.  I wrote it _after_ getting the automatic closure
message, looking up the bug number, and consulting the thread.  After all that,
yes, I realized that bug #10134 was one that had been fixed.

The point of the guideline is for the closer to ensure that the filer knows why
it is being closed before closing.  The point of sending a separate message is
to let the filer connect the reason/status with the bug number, without having
to traipse through the thread again.

The last message in the thread, before the automatic closure message, was
2011/12/25, over a month and a half ago.  Had the no-reason automatic message
come on that day or, say, Dec 26th, things might have been a bit different in
terms of my awareness of this bug and its status.

Between just 2012/01/01 and today there have been 280 messages for Emacs bugs I
filed.  Perhaps you can understand that a message letting me know that this bug
was fixed would have been helpful.

And as I said, in the case where a bug is fixed, that info alone is sometimes
sufficient for the filer, so perhaps the automatic closure message could include
that info.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.