bug#636: marked as done (23.0.60; Read syntax error while byte-compiling)

[Emacs bug Tracking System]

Your message dated Mon, 11 Aug 2008 17:42:22 -0400
with message-id <87bpzzfcu9.fsf@stupidchicken.com>
and subject line Re: bug#636: Please fix before the release of 23.1
has caused the Emacs bug report #636,
regarding 23.0.60; Read syntax error while byte-compiling
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)


-- 
636: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=636
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> 23.0.60; Read syntax error while byte-compiling
>
>
>
>
> Date: 
>
> Fri, 01 Aug 2008 11:43:43 +0400
>
>
>
>
> User-agent: 
>
> Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)
>
>
>
>
> The problem occurs when one tries to byte-compile a file with the
> following contents (note the newline after `eval-when-compile`):
>
>     (eval-when-compile
>        (require 'cc-mode))
>
> Using this command:
>
>     emacs -q --batch -f batch-byte-compile file.el
>
> Which fails with error:
>
>     In toplevel form:
>     test1.el:2:19:Error: Invalid read syntax: ")"
>
> Visiting this file in Emacs and attempting to byte-compile it using the
> `M-x byte-compile-file RET` command results in the same error being
> shown in *Compile-Log* buffer.
>     
> In the same time, if there is no newline after `eval-when-compile`, e.g.
>
>     (eval-when-compile (require 'cc-mode))
>
> Byte-compiling proceeds successfully. The problem occurs only if one
> requires `cc-mode`. Probably this is somehow related with `cc-bytecomp`
> module.
>
> In GNU Emacs 23.0.60.1 (i686-pc-linux-gnu, GTK+ Version 2.12.11)
>  of 2008-07-30 on blizzard
>
> Windowing system distributor `The X.Org Foundation', version
>  11.0.10402000
>
> configured using `configure '--prefix=/usr' '--host=i686-pc-linux-gnu'
> '--mandir=/usr/share/man' '--infodir=/usr/share/info'
> '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib'
> '--program-suffix=-emacs-23' '--infodir=/usr/share/info/emacs-23'
> '--without-carbon' '--with-sound' '--with-x'
> '--with-toolkit-scroll-bars' '--with-gif' '--with-jpeg' '--with-png'
> '--with-rsvg' '--with-tiff' '--with-xpm' '--enable-font-backend'
> '--with-freetype' '--with-xft' '--without-libotf' '--without-m17n-flt'
> '--with-x-toolkit=gtk' '--without-hesiod' '--without-kerberos'
> '--without-kerberos5' '--with-gpm' '--with-dbus'
> '--build=i686-pc-linux-gnu' 'build_alias=i686-pc-linux-gnu'
> 'host_alias=i686-pc-linux-gnu' 'CFLAGS=-O2 -march=native -pipe'
> 'LDFLAGS=-Wl,-O1''
>
> Important settings:
>   value of $LC_ALL: 
>   value of $LC_COLLATE: nil
>   value of $LC_CTYPE: nil
>   value of $LC_MESSAGES: nil
>   value of $LC_MONETARY: nil
>   value of $LC_NUMERIC: C
>   value of $LC_TIME: nil
>   value of $LANG: ru_RU.UTF-8
>   value of $XMODIFIERS: nil
>   locale-coding-system: utf-8-unix
>   default-enable-multibyte-characters: t
> -- 
> Happy Hacking.
>
> http://sphinx.net.ru
> む
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#636: Please fix before the release of 23.1
>
>
>
>
> Date: 
>
> Mon, 11 Aug 2008 17:42:22 -0400
>
>
>
>
> User-agent: 
>
> Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)
>
>
>
>
> Alan Mackenzie <acm@muc.de> writes:
>
> > The way I see it, it's a bug in `beginning-of-defun'.  The docstring
> > says that a non-nil `beginning-of-defun-function' finds the pertinent
> > place, but beginning-of-defun then moves point somewhere else.  I HATE
> > things that are ostensibly "helpful", but in reality are dumbing down,
> > and mainly just foul things up.
>
> This is part of the baggage in beginning-of-defun regarding whether
> column zero is the beginning of a defun.  Changing this now might be
> unwise, so for the moment I've simply revised the docstring of
> beginning-of-defun for extra clarity.
>
> I've also changed cc-defs.el to use beginning-of-defun-raw, which is a
> more direct and side-effect free test of beginning-of-defun-function,
> and added a save-excursion for extra plus safety ;-)
>
> [Also, closing bug#636.]
>
>
> --- End Message ---