bug#7127: 23.2; M-x help throws an error

bug#7127: 23.2; M-x help throws an error

[Aidan Kehoe]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug.  If you can, give
a recipe starting from `emacs -Q':

Recipe is as follows:

1) emacs -Q
2) M-x help RET
3) Observe error giving following backtrace: 

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("%THIS-KEY%" nil)
  help()
  call-interactively(help t nil)
  execute-extended-command(nil)
  call-interactively(execute-extended-command nil nil)

The issue seems to be make-help-screen in help-macro.el, which assumes
that (documentation FNAME) gives non-nil, something not true for
#'help. It would probably be sufficient to change the string-match call
like so:

  (if (and help-screen (string-match "%THIS-KEY%" help-screen))
      ...)

and an insert further down like so:

  (insert (or help-screen ""))



If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/usr/share/emacs/23.2/etc/DEBUG.


In GNU Emacs 23.2.1 (i686-pc-cygwin, GTK+ Version 2.18.6)
 of 2010-05-08 on laptop
configured using `configure  '--srcdir=/usr/src/emacs-23.2-1/src/emacs-23.2' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--libexecdir=/usr/lib' '--datadir=/usr/share' '--localstatedir=/var' '--sysconfdir=/etc' '--datarootdir=/usr/share' '--docdir=/usr/share/doc/emacs' 'CPPFLAGS=-I/usr/include/ncursesw' 'LDFLAGS=-L/usr/lib/ncursesw' 'CC=gcc' 'CFLAGS=-O2 -pipe ' 'LIBS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
RET k C-a C-k C-x b * B A TAB C-b C-k a TAB RET c q 
C-p C-n C-p C-n C-n C-p C-p C-n C-n C-n ESC x e h l 
p C-a C-k h e l p RET f C-g q C-x o C-x b RET C-s t 
h i s C-p C-p ESC < C-s s t r i n g - m a t c h C-a 
C-x b * B a c TAB C-g C-x o ESC x h e l p RET q ESC 
x h e l p RET v C-g q ESC [ [ A v h e l p - s c r e 
e n RET C-g ESC x h e l p RET f d o c C-g q ESC [ [ 
A f d o c u m e n t a t i o n RET C-x o C-x o C-n C-n 
C-n RET RET C-p ( d o s C-b C-k c u m e n t a t i o 
n SPC ' ESC [ [ A f h e l p RET ESC [ [ A f h e l p 
- f o r - h e l p RET C-a C-e h e l p - f o r - h e 
l p - i n t e r n a l ) C-j ESC x r e p o r t - e m 
a c s - b u g RET M x - DEL DEL - x SPC h e l p SPC 
d DEL f a i l s C-b C-b C-b C-b C-b C-k R E T C-g ESC 
x h e l p RET q C-a ESC x h e ESC p ESC p RET

Recent messages:
Proceeding, will debug on next eval or call.
Entering debugger...
Continuing.
Entering debugger...
Quit
Back to top level.
Type C-x 4 C-o RET to restore the other window.
Quit
Entering debugger...
Back to top level.

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message idna sendmail regexp-opt ecomplete rfc822
mml mml-sec password-cache mm-decode mm-bodies mm-encode mailcap
mail-parse rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader
gnus-util netrc time-date mm-util mail-prsvr gmm-utils wid-edit
mailheader canlock sha1 hex-util hashcash mail-utils emacsbug byte-opt
disass bytecomp byte-compile multi-isearch find-func debug two-column cl
cl-19 help-mode easymenu view help-fns tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd font-setting tool-bar dnd fontset
image fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mldrag 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 loaddefs button minibuffer faces cus-face files
text-properties overlay md5 base64 format env code-pages mule custom
widget hashtable-print-readable backquote make-network-process
font-render-setting gtk x-toolkit x multi-tty emacs)

-- 
“Apart from the nine-banded armadillo, man is the only natural host of
Mycobacterium leprae, although it can be grown in the footpads of mice.”
  -- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research

bug#7127: 23.2; M-x help throws an error

[Glenn Morris]

Aidan Kehoe wrote:

> 1) emacs -Q
> 2) M-x help RET
> 3) Observe error giving following backtrace: 
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)

I cannot reproduce this.

> The issue seems to be make-help-screen in help-macro.el, which assumes
> that (documentation FNAME) gives non-nil, something not true for
> #'help.

(documentation #'help)

returns "Help command." for me in Emacs 23.2.

> In GNU Emacs 23.2.1 (i686-pc-cygwin, GTK+ Version 2.18.6)
>  of 2010-05-08 on laptop

bug#7127: 23.2; M-x help throws an error

[Aidan Kehoe]

 Ar an t-ochtú lá is fiche de mí Méan Fómhair, scríobh Glenn Morris: 

 > Aidan Kehoe wrote:
 > 
 > > 1) emacs -Q
 > > 2) M-x help RET
 > > 3) Observe error giving following backtrace: 
 > >
 > > Debugger entered--Lisp error: (wrong-type-argument stringp nil)
 > 
 > I cannot reproduce this.
 > 
 > > The issue seems to be make-help-screen in help-macro.el, which assumes
 > > that (documentation FNAME) gives non-nil, something not true for
 > > #'help.
 > 
 > (documentation #'help)
 > 
 > returns "Help command." for me in Emacs 23.2.

Good for you. (symbol-function 'help-for-help-internal) (h-f-h-i being what
help eventually resolves to) gives me a compiled function with a nil
documentation slot; help.elc has (defalias 'help-for-help-internal ...) with
a compiled function and what seems to be the correct lazy doc reference. The
DOC file seems correct, with an entry \x1fFhelp-for-help-internal
Help command.\x1f

But (documentation #'custom-declare-variable-early) and (documentation
#'when) both give nil for me, and the same seems to be true for all the
dumped compiled functions with docstrings. I don’t know why that is, and I
don’t especially care to debug it right now, but this binary is what Cygwin
installed, I’m certain I’m not the only one affected.

 > > In GNU Emacs 23.2.1 (i686-pc-cygwin, GTK+ Version 2.18.6)
 > >  of 2010-05-08 on laptop

-- 
“Apart from the nine-banded armadillo, man is the only natural host of
Mycobacterium leprae, although it can be grown in the footpads of mice.”
  -- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research

bug#7127: 23.2; M-x help throws an error

[Glenn Morris]

This may be Cygwin-specific?

Aidan Kehoe wrote:

> (symbol-function 'help-for-help-internal) (h-f-h-i being what help
> eventually resolves to) gives me a compiled function with a nil
> documentation slot; help.elc has (defalias 'help-for-help-internal
> ...) with a compiled function and what seems to be the correct lazy
> doc reference. The DOC file seems correct, with an entry
> \x1fFhelp-for-help-internal Help command.\x1f
>
> But (documentation #'custom-declare-variable-early) and (documentation
> #'when) both give nil for me, and the same seems to be true for all the
> dumped compiled functions with docstrings. I don’t know why that is, and I
> don’t especially care to debug it right now, but this binary is what Cygwin
> installed, I’m certain I’m not the only one affected.
>
>  > > In GNU Emacs 23.2.1 (i686-pc-cygwin, GTK+ Version 2.18.6)
>  > >  of 2010-05-08 on laptop

bug#7127: 23.2; M-x help throws an error

[Ken Brown]

On 9/29/2010 3:58 AM, Glenn Morris wrote:
>
> This may be Cygwin-specific?
>
> Aidan Kehoe wrote:
>
>> (symbol-function 'help-for-help-internal) (h-f-h-i being what help
>> eventually resolves to) gives me a compiled function with a nil
>> documentation slot; help.elc has (defalias 'help-for-help-internal
>> ...) with a compiled function and what seems to be the correct lazy
>> doc reference. The DOC file seems correct, with an entry
>> \x1fFhelp-for-help-internal Help command.\x1f
>>
>> But (documentation #'custom-declare-variable-early) and (documentation
>> #'when) both give nil for me, and the same seems to be true for all the
>> dumped compiled functions with docstrings. I don’t know why that is, and I
>> don’t especially care to debug it right now, but this binary is what Cygwin
>> installed, I’m certain I’m not the only one affected.
>>
>>   >  >  In GNU Emacs 23.2.1 (i686-pc-cygwin, GTK+ Version 2.18.6)
>>   >  >   of 2010-05-08 on laptop

I can reproduce the problem on my (Cygwin) system.  The bug occurs in 
Emacs 23.2 as well as a build from the current emacs-23 branch.  But the 
bug is gone in a build from the trunk.  I wonder if the patch in 
bug#6715 is what fixed it.  At a glance, I don't see anything else 
Cygwin-specific that might be relevant.  When I get a chance, I'll see 
if back-porting that patch to emacs-23 fixes the problem.

Ken

bug#7127: 23.2; M-x help throws an error

[Ken Brown]

On 9/29/2010 9:02 AM, Ken Brown wrote:
> On 9/29/2010 3:58 AM, Glenn Morris wrote:
>>
>> This may be Cygwin-specific?
>>
>> Aidan Kehoe wrote:
>>
>>> (symbol-function 'help-for-help-internal) (h-f-h-i being what help
>>> eventually resolves to) gives me a compiled function with a nil
>>> documentation slot; help.elc has (defalias 'help-for-help-internal
>>> ...) with a compiled function and what seems to be the correct lazy
>>> doc reference. The DOC file seems correct, with an entry
>>> \x1fFhelp-for-help-internal Help command.\x1f
>>>
>>> But (documentation #'custom-declare-variable-early) and (documentation
>>> #'when) both give nil for me, and the same seems to be true for all the
>>> dumped compiled functions with docstrings. I don’t know why that is, and I
>>> don’t especially care to debug it right now, but this binary is what Cygwin
>>> installed, I’m certain I’m not the only one affected.
>>>
>>>    >   >   In GNU Emacs 23.2.1 (i686-pc-cygwin, GTK+ Version 2.18.6)
>>>    >   >    of 2010-05-08 on laptop
>
> I can reproduce the problem on my (Cygwin) system.  The bug occurs in
> Emacs 23.2 as well as a build from the current emacs-23 branch.  But the
> bug is gone in a build from the trunk.  I wonder if the patch in
> bug#6715 is what fixed it.  At a glance, I don't see anything else
> Cygwin-specific that might be relevant.  When I get a chance, I'll see
> if back-porting that patch to emacs-23 fixes the problem.

This turns out not to be so easy.  That patch is intertwined with a lot 
of changes to the build system that were made only in the trunk, so 
there's no way to quickly test whether that patch is relevant to the 
present bug.  Since the bug is gone in the trunk, I don't think it's 
worth putting a lot of effort into fixing it in the emacs-23 branch.

Ken

bug#7127: 23.2; M-x help throws an error

[Glenn Morris]

Ken Brown wrote:

> This turns out not to be so easy.  That patch is intertwined with a
> lot of changes to the build system that were made only in the trunk,
> so there's no way to quickly test whether that patch is relevant to
> the present bug.

Would this have the same effect?

*** src/s/cygwin.h	2010-01-13 08:35:10 +0000
--- src/s/cygwin.h	2010-09-29 17:04:58 +0000
***************
*** 104,109 ****
--- 104,110 ----
  #define PENDING_OUTPUT_COUNT(FILE) ((FILE)->_p - (FILE)->_bf._base)
  #define SYSV_SYSTEM_DIR 1
  #define UNEXEC unexcw.o
+ #define START_FILES pre-crt0.o
  #define POSIX_SIGNALS 1
  #define LINKER $(CC)
  

bug#7127: 23.2; M-x help throws an error

[Ken Brown]

On 9/29/2010 1:07 PM, Glenn Morris wrote:
> Ken Brown wrote:
>
>> This turns out not to be so easy.  That patch is intertwined with a
>> lot of changes to the build system that were made only in the trunk,
>> so there's no way to quickly test whether that patch is relevant to
>> the present bug.
>
> Would this have the same effect?
>
> *** src/s/cygwin.h	2010-01-13 08:35:10 +0000
> --- src/s/cygwin.h	2010-09-29 17:04:58 +0000
> ***************
> *** 104,109 ****
> --- 104,110 ----
>    #define PENDING_OUTPUT_COUNT(FILE) ((FILE)->_p - (FILE)->_bf._base)
>    #define SYSV_SYSTEM_DIR 1
>    #define UNEXEC unexcw.o
> + #define START_FILES pre-crt0.o
>    #define POSIX_SIGNALS 1
>    #define LINKER $(CC)

That's the first thing I tried, but emacs wouldn't compile because of an 
undefined reference in src/sysdep.c.  So I patched that.  Then emacs 
wouldn't compile because of an undefined reference in src/vm-limit.c. 
That's when I decided that it might not be worth the trouble to put more 
time into this.  I'd also be a little worried about what side-effects 
might result from selectively backporting changes to the build system.

Ken

bug#7127: 23.2; M-x help throws an error

[Glenn Morris]

Ken Brown wrote:

> That's the first thing I tried, but emacs wouldn't compile because of
> an undefined reference in src/sysdep.c.  So I patched that.  Then
> emacs wouldn't compile because of an undefined reference in
> src/vm-limit.c. That's when I decided that it might not be worth the
> trouble to put more time into this.  I'd also be a little worried
> about what side-effects might result from selectively backporting
> changes to the build system.

True; but if the documentation of many (?) functions is missing, that
seems like a problem serious enough to try to fix it for the future
Emacs 23.3. Of course, I can say that because it won't be me trying to
fix it. :)

Did 23.1 have the same problem?

bug#7127: 23.2; M-x help throws an error

[Ken Brown]

On 9/29/2010 8:35 PM, Glenn Morris wrote:
> Ken Brown wrote:
>
>> That's the first thing I tried, but emacs wouldn't compile because of
>> an undefined reference in src/sysdep.c.  So I patched that.  Then
>> emacs wouldn't compile because of an undefined reference in
>> src/vm-limit.c. That's when I decided that it might not be worth the
>> trouble to put more time into this.  I'd also be a little worried
>> about what side-effects might result from selectively backporting
>> changes to the build system.
>
> True; but if the documentation of many (?) functions is missing, that
> seems like a problem serious enough to try to fix it for the future
> Emacs 23.3.

OK, I'll look harder.

> Did 23.1 have the same problem?

No, it doesn't.  So that changes things completely.  I guess I have to 
try a bisection to find the revision between 23.1 and 23.2 where the bug 
first appears.  It may be a little while before I have time to do this.

Ken

bug#7127: 23.2; M-x help throws an error

[Glenn Morris]

Ken Brown wrote:

>> Did 23.1 have the same problem?
>
> No, it doesn't.  So that changes things completely.  I guess I have to
> try a bisection to find the revision between 23.1 and 23.2 where the
> bug first appears.  It may be a little while before I have time to do
> this.

The first thing you could try is just a straight rebuild of the 23.2
package (if you were testing a pre-built binary). I have a vague
memory of some transient DOC related weirdness with emacs-snapshot
packages that just seemed to go away on its own (?). So maybe it was
just a build glitch.

bug#7127: 23.2; M-x help throws an error

[Ken Brown]

On 9/30/2010 3:12 AM, Glenn Morris wrote:
> Ken Brown wrote:
>
>>> Did 23.1 have the same problem?
>>
>> No, it doesn't.  So that changes things completely.  I guess I have to
>> try a bisection to find the revision between 23.1 and 23.2 where the
>> bug first appears.  It may be a little while before I have time to do
>> this.
>
> The first thing you could try is just a straight rebuild of the 23.2
> package (if you were testing a pre-built binary). I have a vague
> memory of some transient DOC related weirdness with emacs-snapshot
> packages that just seemed to go away on its own (?). So maybe it was
> just a build glitch.

Thanks for the suggestion.  This is indeed a build glitch, but I don't 
understand what's happening yet.  If I unpack the emacs-23.2 source and 
just build it (./configure && make) the bug is gone.  But normally I 
build emacs for Cygwin by using a packaging tool called cygport, which 
(among other things) does an out-of-tree build.  I don't know if this is 
causing the problem.  My build of emacs-23.1 also used cygport and 
didn't exhibit the bug.  So I have to keep investigating.

Ken

bug#7127: 23.2; M-x help throws an error

[Ken Brown]

On 9/30/2010 1:30 PM, Ken Brown wrote:
> On 9/30/2010 3:12 AM, Glenn Morris wrote:
>> Ken Brown wrote:
>>
>>>> Did 23.1 have the same problem?
>>>
>>> No, it doesn't.  So that changes things completely.  I guess I have to
>>> try a bisection to find the revision between 23.1 and 23.2 where the
>>> bug first appears.  It may be a little while before I have time to do
>>> this.
>>
>> The first thing you could try is just a straight rebuild of the 23.2
>> package (if you were testing a pre-built binary). I have a vague
>> memory of some transient DOC related weirdness with emacs-snapshot
>> packages that just seemed to go away on its own (?). So maybe it was
>> just a build glitch.
>
> Thanks for the suggestion.  This is indeed a build glitch, but I don't
> understand what's happening yet.  If I unpack the emacs-23.2 source and
> just build it (./configure&&  make) the bug is gone.  But normally I
> build emacs for Cygwin by using a packaging tool called cygport, which
> (among other things) does an out-of-tree build.  I don't know if this is
> causing the problem.  My build of emacs-23.1 also used cygport and
> didn't exhibit the bug.  So I have to keep investigating.

The out-of-tree build is indeed the problem, and I'm no longer sure this 
is Cygwin-specific.  Here are the steps to reproduce it:

wget http://ftp.gnu.org/pub/gnu/emacs/emacs-23.2.tar.gz
tar -xf emacs-23.2.tar.gz
mkdir build
cd build
../emacs-23.2/configure
make
cd src
./emacs -Q
M-x help

The result is the error message "Wrong type argument: stringp, nil".

I would appreciate it if someone could try this on another system so 
that I'll know if it's a Cygwin problem.

Ken

bug#7127: 23.2; M-x help throws an error

[Glenn Morris]

Ken Brown wrote:

> tar -xf emacs-23.2.tar.gz
> mkdir build
> cd build
> ../emacs-23.2/configure
> make
> cd src
> ./emacs -Q
> M-x help

Works for me on an x86_64 GNU/Linux system.

bug#7127: 23.2; M-x help throws an error

[Ken Brown]

On 10/1/2010 2:33 PM, Glenn Morris wrote:
> Ken Brown wrote:
>
>> tar -xf emacs-23.2.tar.gz
>> mkdir build
>> cd build
>> ../emacs-23.2/configure
>> make
>> cd src
>> ./emacs -Q
>> M-x help
>
> Works for me on an x86_64 GNU/Linux system.

That's too bad.  I was hoping this would become someone else's problem. 
  In any case, it's easy enough to work around it.  I just won't do an 
out-of-tree build for my future releases of emacs-23 for Cygwin.  (The 
problem doesn't exist in emacs-24.)  And I'll go ahead and do a rebuild 
of 23.2 for the Cygwin distribution within the next few days.

Ken

bug#7127: 23.2; M-x help throws an error

[Glenn Morris]

Ken Brown wrote:

> That's too bad.  I was hoping this would become someone else's problem.

Maybe it's some temporary thing that isn't specific to Cygwin, but
doesn't happen every time. Like I said, I have a vague memory of
something similar for the emacs-snapshot package. I think it was:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=2590

It's hard to see what could have changed between 23.1 and 23.2 to
cause this, nor why it should go away in 24.1.

>  In any case, it's easy enough to work around it.  I just
> won't do an out-of-tree build for my future releases of emacs-23 for
> Cygwin.  (The problem doesn't exist in emacs-24.)  And I'll go ahead
> and do a rebuild of 23.2 for the Cygwin distribution within the next
> few days.

Great, thank you.

bug#7127: 23.2; M-x help throws an error

[Ken Brown]

On 10/1/2010 10:57 PM, Glenn Morris wrote:
> Ken Brown wrote:
>
>> That's too bad.  I was hoping this would become someone else's problem.
>
> Maybe it's some temporary thing that isn't specific to Cygwin, but
> doesn't happen every time. Like I said, I have a vague memory of
> something similar for the emacs-snapshot package. I think it was:
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=2590
>
> It's hard to see what could have changed between 23.1 and 23.2 to
> cause this, nor why it should go away in 24.1.
>
>>   In any case, it's easy enough to work around it.  I just
>> won't do an out-of-tree build for my future releases of emacs-23 for
>> Cygwin.  (The problem doesn't exist in emacs-24.)  And I'll go ahead
>> and do a rebuild of 23.2 for the Cygwin distribution within the next
>> few days.
>
> Great, thank you.

Before I upload the new build, I want to make sure the problem really is 
fixed.  M-x help works fine, but then I tried some of the other things 
that the OP mentioned, and I got the following results:

(symbol-function 'help-for-help-internal)
#[nil "\306\307\310!!\x18	\203\x0f\311\312\b\"\210\313\314!\x1a\315 
^[\f\x1d\316 \x1e;\317\211\x1e<\x1e=\317\211\x1e>\x1e?\320\321
\"\203<\322\323\324 \325\326O!\327\211
$\x12\330\216\317\x1c\v\x0e@\241\210\331\v\332\333#\210\331\v\334\335\x0eA\336\"#\210	\203|\v\x1eB\337\317!)\x16>\335\x0eC\x0e>\"\203s\335\x0eC\x0e>\"\x16>\x0e>\325H\x16?\202\x7f\340\x16?\x0e?\340=\204\226\x0e?\x0eD=\204\226\x0e?\x0eE>\203$\x01\341 
\x16<\342\343!\210\344\345!\203\267\346\347 !\x0e;=\204\267\346\347 
!\x16=\317\x16<\317\x16F\327\x1eG\350 \210
c\210)
\x1c\351 \210\f\x15)eb\210\x0e?\352\x0eE\x0eD\353B\">\204\354\x0e?\242\354=\204\354\x0e>\355\232\203$\x01\317\356\357\217\210\327\v\x1eB\x1eH\337\360\361\362d!\203\x04\x01\363\202\x05\x01\364\"!\211\x16>\325H\x16?*\x0e?\365=\203\317\366\335\v\x0e>\"\317\x0e>#\210\202\317\311\363!\210\x0e?<\203<\x01\x0e?\x0eIB\x16I\317\211\x16<\202u\x01\335\v\x0e>\"\211\x1eJ\203r\x01\x0e<\203T\x01\367\x0e<!\210\317\x16<\370\x0eJ!\210\x0e=\205t\x01\x0e=\316 
=\204k\x01\371\x0e=!\210\317\211\x16=\202t\x01\372 ).\v\207" [line-prompt 
three-step-help help-screen local-map minor-mode-map-alist 
new-minor-mode-map-alist substitute-command-keys purecopy "Type a help 
option: [abcCdefFgiIkKlLmnprstvw.] C-[cdefmnoptw] or ?" message "%s" 
documentation ...] 7 1900136 nil]

(documentation #'help)
"Help command."

(documentation #'custom-declare-variable-early)
nil

(documentation #'when)
"If COND yields non-nil, do BODY, else return nil.
When COND yields non-nil, eval BODY forms sequentially and return
value of last one, or nil if there are none.

(fn COND BODY...)"

Do these all look OK?  (I'm worried about the first and third.)  I get 
the same results in a build from the (emacs-24) trunk.

Ken

bug#7127: 23.2; M-x help throws an error

[Eli Zaretskii]

> Date: Sat, 02 Oct 2010 09:57:01 -0400
> From: Ken Brown <kbrown@cornell.edu>
> Cc: "7127@debbugs.gnu.org" <7127@debbugs.gnu.org>
> 
> Do these all look OK?  (I'm worried about the first and third.)  I get 
> the same results in a build from the (emacs-24) trunk.

I get the same results in two different builds of Emacs 23.2 (on
GNU/Linux and on Windows), so I think they are at least as good as the
rest of Emacs builds ;-)

bug#7127: 23.2; M-x help throws an error

[Ken Brown]

On 10/2/2010 11:12 AM, Eli Zaretskii wrote:
>> Date: Sat, 02 Oct 2010 09:57:01 -0400
>> From: Ken Brown<kbrown@cornell.edu>
>> Cc: "7127@debbugs.gnu.org"<7127@debbugs.gnu.org>
>>
>> Do these all look OK?  (I'm worried about the first and third.)  I get
>> the same results in a build from the (emacs-24) trunk.
>
> I get the same results in two different builds of Emacs 23.2 (on
> GNU/Linux and on Windows), so I think they are at least as good as the
> rest of Emacs builds ;-)

Thanks!  That's a relief.

Ken

bug#7127: 23.2; M-x help throws an error

[Ken Brown]

On 10/1/2010 10:57 PM, Glenn Morris wrote:
> Ken Brown wrote:
>
>> That's too bad.  I was hoping this would become someone else's problem.
>
> Maybe it's some temporary thing that isn't specific to Cygwin, but
> doesn't happen every time. Like I said, I have a vague memory of
> something similar for the emacs-snapshot package. I think it was:
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=2590
>
> It's hard to see what could have changed between 23.1 and 23.2 to
> cause this, nor why it should go away in 24.1.
>
>>   In any case, it's easy enough to work around it.  I just
>> won't do an out-of-tree build for my future releases of emacs-23 for
>> Cygwin.  (The problem doesn't exist in emacs-24.)  And I'll go ahead
>> and do a rebuild of 23.2 for the Cygwin distribution within the next
>> few days.
>
> Great, thank you.

The mystery is solved by Eli's fix for bug#7167.  It was a problem with 
the 23.2 tarball.  If I delete src/buildobj.h, an out-of-tree build of 
23.2 works again under Cygwin.

Bug closed.

Ken