bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'

bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'

[Drew Adams]

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

bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'

[Eli Zaretskii]

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

bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'

[Drew Adams]

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

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

[-- Attachment #2: throw-emacs-bug-10134.png --]
[-- Type: image/png, Size: 55176 bytes --]

bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'

[Eli Zaretskii]

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

tags 10134 unreproducible
quit

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


[-- Attachment #2: no-emacs-bug.png --]
[-- Type: image/png, Size: 30883 bytes --]

bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'

[Drew Adams]

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

bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'

[Eli Zaretskii]

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

bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'

[Christoph Scholtes]

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.

bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'

[Eli Zaretskii]

> Date: Sat, 24 Dec 2011 10:48:27 -0700
> From: Christoph Scholtes <cschol2112@googlemail.com>
> CC: Drew Adams <drew.adams@oracle.com>, 10134@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 ;-)

bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'

[Christoph Scholtes]

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!

bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'

[Juanma Barranquero]

On Sat, Dec 24, 2011 at 18:57, Eli Zaretskii <eliz@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

bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 25 Dec 2011 11:23:18 +0100
> Cc: Christoph Scholtes <cschol2112@googlemail.com>, 10134@debbugs.gnu.org
> 
> On Sat, Dec 24, 2011 at 18:57, Eli Zaretskii <eliz@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.

bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'

[Drew Adams]

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

bug#10134: 24.0.91; Typo, (elisp) `Text from Minibuffer'

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <10134@debbugs.gnu.org>,
>         "'Christoph Scholtes'" <cschol2112@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.