Emacs 23.1.90 pretest

Emacs 23.1.90 pretest

[Chong Yidong]

Emacs pretest 23.1.90 is now available for download via FTP, at the
following location:

  ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz

The xdelta against Emacs 23.1 is here:

  ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1-23.1.90.xdelta

This is the first pretest for what will be the Emacs 23.2 release.

Pretesters: please send me an email reporting success or failure on your
build platform.  Report bugs via M-x report-emacs-bugs, or email
emacs-pretest-bug@gnu.org.  For questions, email emacs-devel@gnu.org.

Note that the default for `mail-user-agent' has been changed from Mail
mode to Message mode; if you have Mail mode-specific customizations,
please check them.

There are quite a number of changes relative to Emacs 23.1, including
several new packages, notably the CEDET package of development tools.
See etc/NEWS for details.


Emacs developers: please note that the tree is now frozen.  No new
features are allowed, unless agreed to by Stefan or myself.  Changes
that are bug fixes or improvements to documentations may still be
committed directly; when in doubt, send email to emacs-devel@gnu.org.  I
think we will probably begin Emacs 24 development soon-ish, once we make
the switch from CVS to BZR (we can discuss this further on emacs-devel).

Thanks.

Re: Emacs 23.1.90 pretest

[Juanma Barranquero]

On Wed, Dec 9, 2009 at 03:54, Chong Yidong <cyd@stupidchicken.com> wrote:

>  ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz

> Pretesters: please send me an email reporting success or failure on your
> build platform.

I've tried both building and bootstrapping the tar.gz file on

  Windows 7 Home Edition (build 7600)

compiling with

  gcc.exe (TDM-2 mingw32) 4.4.1-dw2

Building works fine.

Bootstrapping does not compile the *.el files in the subdirs under
lisp/cedet/semantic/; a subsequent "make cvs-update install" fixes it.

    Juanma

Re: Emacs 23.1.90 pretest

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 9 Dec 2009 05:39:02 +0100
> Cc: emacs-devel@gnu.org
> 
> Bootstrapping does not compile the *.el files in the subdirs under
> lisp/cedet/semantic/; a subsequent "make cvs-update install" fixes it.

Doesn't compile because the *.elc files are already there and
"bootstrap-clean" does not remove them, or doesn't compile because it
wasn't told to do so, even if *.elc supplied with the tarball are
removed?

Re: Emacs 23.1.90 pretest

[Juanma Barranquero]

On Wed, Dec 9, 2009 at 12:33, Eli Zaretskii <eliz@gnu.org> wrote:

> Doesn't compile because the *.elc files are already there and
> "bootstrap-clean" does not remove them, or doesn't compile because it
> wasn't told to do so, even if *.elc supplied with the tarball are
> removed?

Sorry, I didn't really made myself clear here.

The *.elc for lisp/cedet/semantic/*/*.el files are in the tarball.

The .BAT script that I use to bootstrap Emacs starts by cleaning the
source dir, removing *.elc, *.o, etc. I'm using the realclean target
etc., though after the switch I'll use "bzr clean-tree --unknown
--ignored --detritus"; the intent is having a clean checkout.

After that,

    cd nt
    configure
    make bootstrap
    make install

does not compile the semantic/*/*.el files.

    Juanma

Re: Emacs 23.1.90 pretest

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

> Sorry, I didn't really made myself clear here.
>
> The *.elc for lisp/cedet/semantic/*/*.el files are in the tarball.
>
> The .BAT script that I use to bootstrap Emacs starts by cleaning the
> source dir, removing *.elc, *.o, etc. I'm using the realclean target
> etc., though after the switch I'll use "bzr clean-tree --unknown
> --ignored --detritus"; the intent is having a clean checkout.
>
> After that,
>
>     cd nt
>     configure
>     make bootstrap
>     make install
>
> does not compile the semantic/*/*.el files.

One possibility is that the Makefile in the tarball doesn't compile the
semantic/*/*.elc files, but the change to Makefile.in, done by Stefan
after the tarball was made, fixes this.  Dunno why the problem doesn't
show up on GNU/Linux, though.

Re: Emacs 23.1.90 pretest

[Juanma Barranquero]

On Wed, Dec 9, 2009 at 21:46, Chong Yidong <cyd@stupidchicken.com> wrote:

> One possibility is that the Makefile in the tarball doesn't compile the
> semantic/*/*.elc files, but the change to Makefile.in, done by Stefan
> after the tarball was made, fixes this.  Dunno why the problem doesn't
> show up on GNU/Linux, though.

I don't think Makefile.in is involved in this; likely a problem with
the Windows-specific makefile.w32-in.

The problem, BTW, has surely been happening for a while on the trunk;
we just didn't notice until now.

    Juanma

Re: Emacs 23.1.90 pretest

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Wed, Dec 9, 2009 at 21:46, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> One possibility is that the Makefile in the tarball doesn't compile the
>> semantic/*/*.elc files, but the change to Makefile.in, done by Stefan
>> after the tarball was made, fixes this.  Dunno why the problem doesn't
>> show up on GNU/Linux, though.
>
> I don't think Makefile.in is involved in this; likely a problem with
> the Windows-specific makefile.w32-in.
>
> The problem, BTW, has surely been happening for a while on the trunk;
> we just didn't notice until now.

Then I am confused as to why "make cvs-update install" would fix the
problem.

Re: Emacs 23.1.90 pretest

[Glenn Morris]

Chong Yidong wrote:

> Then I am confused as to why "make cvs-update install" would fix the
> problem.

I think WINS_CEDET_SUBDIRS is missing from the list of directories to
compile (WINS_ALMOST) in lisp/makefile.w32-in.

cvs-update runs recompile which uses batch-byte-recompile-directory,
so compiling the files in a different way.

Re: Emacs 23.1.90 pretest

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> Chong Yidong wrote:
>
>> Then I am confused as to why "make cvs-update install" would fix the
>> problem.
>
> I think WINS_CEDET_SUBDIRS is missing from the list of directories to
> compile (WINS_ALMOST) in lisp/makefile.w32-in.
>
> cvs-update runs recompile which uses batch-byte-recompile-directory,
> so compiling the files in a different way.

You're right, of course.  Juanma, could you test this change and see if
it does the right thing?

*** emacs/lisp/makefile.w32-in.~1.101.~	2009-11-20 09:20:56.000000000 -0500
--- emacs/lisp/makefile.w32-in	2009-12-09 16:44:40.000000000 -0500
***************
*** 89,97 ****
  	cedet \
  	cedet/ede \
  	cedet/semantic \
! 	cedet/srecode
! 
! WINS_CEDET_SUBDIRS=\
  	cedet/semantic/analyze \
  	cedet/semantic/bovine \
  	cedet/semantic/decorate \
--- 89,95 ----
  	cedet \
  	cedet/ede \
  	cedet/semantic \
! 	cedet/srecode \
  	cedet/semantic/analyze \
  	cedet/semantic/bovine \
  	cedet/semantic/decorate \
***************
*** 118,137 ****
  	textmodes \
  	url
  
! # Directories with lisp files to compile
! WINS_ALMOST=$(WINS_BASIC) \
  	$(WINS_CEDET)
  
- # Directories to extract data from (customs, autoloads, etc.)
- WINS_UPDATES=$(WINS_ALMOST) \
- 	$(WINS_CEDET_SUBDIRS)
- 
  # Directories to add to subdirs.el
  WINS_SUBDIR=$(WINS_BASIC) \
  	obsolete
  
! # All directories, except CEDET subdirs
! WINS= $(WINS_ALMOST) \
  	term \
  	obsolete
  
--- 116,132 ----
  	textmodes \
  	url
  
! # Directories with lisp files to compile, and to extract data from
! # (customs, autoloads, etc.)
! WINS_UPDATES=$(WINS_BASIC) \
  	$(WINS_CEDET)
  
  # Directories to add to subdirs.el
  WINS_SUBDIR=$(WINS_BASIC) \
  	obsolete
  
! # All directories
! WINS= $(WINS_UPDATES) \
  	term \
  	obsolete
  

Re: Emacs 23.1.90 pretest

[Juanma Barranquero]

On Wed, Dec 9, 2009 at 22:45, Chong Yidong <cyd@stupidchicken.com> wrote:

> You're right, of course.  Juanma, could you test this change and see if
> it does the right thing?

Yes, apparently so, though you'll have to remove also the references
to WINS_CEDET_SUBDIRS in targets bootstrap-clean-CMD and
boostrap-clean-SH.

    Juanma

Re: Emacs 23.1.90 pretest

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Wed, Dec 9, 2009 at 22:45, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> You're right, of course.  Juanma, could you test this change and see
>> if it does the right thing?
>
> Yes, apparently so, though you'll have to remove also the references
> to WINS_CEDET_SUBDIRS in targets bootstrap-clean-CMD and
> boostrap-clean-SH.

OK, I've checked the corrected fix into CVS.  Could you check if it
works?

Re: Emacs 23.1.90 pretest

[Juanma Barranquero]

On Fri, Dec 11, 2009 at 17:48, Chong Yidong <cyd@stupidchicken.com> wrote:

> OK, I've checked the corrected fix into CVS.  Could you check if it
> works?

The change you've committed is the one I already tested (including the
missing fixes in the bootstrap-clean-* targets). Also, I bootstrap
quite often, so any trouble should be evident before the next pretest
release.

    Juanma

Re: Emacs 23.1.90 pretest

[Giovanni Lanzani]

Chong Yidong <cyd@stupidchicken.com> writes:

> Emacs pretest 23.1.90 is now available for download via FTP, at the
> following location:
>
>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
>
> The xdelta against Emacs 23.1 is here:
>
>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1-23.1.90.xdelta
>
> This is the first pretest for what will be the Emacs 23.2 release.
>
> Pretesters: please send me an email reporting success or failure on your
> build platform.  Report bugs via M-x report-emacs-bugs, or email
> emacs-pretest-bug@gnu.org.  For questions, email emacs-devel@gnu.org.
>
> Note that the default for `mail-user-agent' has been changed from Mail
> mode to Message mode; if you have Mail mode-specific customizations,
> please check them.
>
> There are quite a number of changes relative to Emacs 23.1, including
> several new packages, notably the CEDET package of development tools.
> See etc/NEWS for details.
>

I tried to build the extracted tar.gz, on Snow Leopard, 64bit, with the
following

./configure --with-ns
make install

But it ends with the error

Undefined symbols:
  "_xg_select", referenced from:
      _wait_reading_process_output in process.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [temacs] Error 1
make: *** [src] Error 2


Cheers

Giovanni

Re: Emacs 23.1.90 pretest

[Jan Djärv]

Can you send us config.log?  In the meantime, try adding --without-dbus (just 
a guess).

	Jan D.

Giovanni Lanzani skrev 2009-12-09 10.14:
> Chong Yidong<cyd@stupidchicken.com>  writes:
>
>> Emacs pretest 23.1.90 is now available for download via FTP, at the
>> following location:
>>
>>    ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
>>
>> The xdelta against Emacs 23.1 is here:
>>
>>    ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1-23.1.90.xdelta
>>
>> This is the first pretest for what will be the Emacs 23.2 release.
>>
>> Pretesters: please send me an email reporting success or failure on your
>> build platform.  Report bugs via M-x report-emacs-bugs, or email
>> emacs-pretest-bug@gnu.org.  For questions, email emacs-devel@gnu.org.
>>
>> Note that the default for `mail-user-agent' has been changed from Mail
>> mode to Message mode; if you have Mail mode-specific customizations,
>> please check them.
>>
>> There are quite a number of changes relative to Emacs 23.1, including
>> several new packages, notably the CEDET package of development tools.
>> See etc/NEWS for details.
>>
>
> I tried to build the extracted tar.gz, on Snow Leopard, 64bit, with the
> following
>
> ./configure --with-ns
> make install
>
> But it ends with the error
>
> Undefined symbols:
>    "_xg_select", referenced from:
>        _wait_reading_process_output in process.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make[1]: *** [temacs] Error 1
> make: *** [src] Error 2
>
>
> Cheers
>
> Giovanni
>
>

Re: Emacs 23.1.90 pretest

[Jan Djärv]

Giovanni skrev:
> On Wed, Dec 9, 2009 at 6:14 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>> Can you send us config.log?  In the meantime, try adding --without-dbus
>> (just a guess).
>>
>>        Jan D.
> 
> --without-dbus doens't help.
> 
> See the attached file for config.log

Thanks.  --without-rsvg should get you a build until this is fixed.  Maybe 
throw in a --without-gconf to be on the safe side.  It seems you have librsvg 
for X11 so configure picks that up.

	Jan D.

> 
> 
> Giovanni
> 
> 
>> Giovanni Lanzani skrev 2009-12-09 10.14:
>>> Chong Yidong<cyd@stupidchicken.com>  writes:
>>>
>>>> Emacs pretest 23.1.90 is now available for download via FTP, at the
>>>> following location:
>>>>
>>>>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
>>>>
>>>> The xdelta against Emacs 23.1 is here:
>>>>
>>>>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1-23.1.90.xdelta
>>>>
>>>> This is the first pretest for what will be the Emacs 23.2 release.
>>>>
>>>> Pretesters: please send me an email reporting success or failure on your
>>>> build platform.  Report bugs via M-x report-emacs-bugs, or email
>>>> emacs-pretest-bug@gnu.org.  For questions, email emacs-devel@gnu.org.
>>>>
>>>> Note that the default for `mail-user-agent' has been changed from Mail
>>>> mode to Message mode; if you have Mail mode-specific customizations,
>>>> please check them.
>>>>
>>>> There are quite a number of changes relative to Emacs 23.1, including
>>>> several new packages, notably the CEDET package of development tools.
>>>> See etc/NEWS for details.
>>>>
>>> I tried to build the extracted tar.gz, on Snow Leopard, 64bit, with the
>>> following
>>>
>>> ./configure --with-ns
>>> make install
>>>
>>> But it ends with the error
>>>
>>> Undefined symbols:
>>>   "_xg_select", referenced from:
>>>       _wait_reading_process_output in process.o
>>> ld: symbol(s) not found
>>> collect2: ld returned 1 exit status
>>> make[1]: *** [temacs] Error 1
>>> make: *** [src] Error 2
>>>
>>>
>>> Cheers
>>>
>>> Giovanni
>>>
>>>

Re: Emacs 23.1.90 pretest

[Giovanni Lanzani]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Giovanni skrev:
>> On Wed, Dec 9, 2009 at 6:14 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>> Can you send us config.log?  In the meantime, try adding --without-dbus
>>> (just a guess).
>>>
>>>        Jan D.
>>
>> --without-dbus doens't help.
>>
>> See the attached file for config.log
>
> Thanks.  --without-rsvg should get you a build until this is
> fixed.  Maybe throw in a --without-gconf to be on the safe
> side.  It seems you have librsvg for X11 so configure picks
> that up.
>
> 	Jan D.

Thanks Jan, with the option --without-gconf it builds (altough it
doesn't with the option --without-rsvg).


Giovanni

Re: Emacs 23.1.90 pretest

[Jan Djärv]

Giovanni Lanzani skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> Giovanni skrev:
>>> On Wed, Dec 9, 2009 at 6:14 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>>> Can you send us config.log?  In the meantime, try adding --without-dbus
>>>> (just a guess).
>>>>
>>>>        Jan D.
>>> --without-dbus doens't help.
>>>
>>> See the attached file for config.log
>> Thanks.  --without-rsvg should get you a build until this is
>> fixed.  Maybe throw in a --without-gconf to be on the safe
>> side.  It seems you have librsvg for X11 so configure picks
>> that up.
>>
>> 	Jan D.
> 
> Thanks Jan, with the option --without-gconf it builds (altough it
> doesn't with the option --without-rsvg).
> 

This is fixed now.

Thanks for testing.

	Jan D.

Re: Emacs 23.1.90 pretest

[Yavor Doganov]

Jan Djärv wrote:
> > Thanks Jan, with the option --without-gconf it builds (altough it
> > doesn't with the option --without-rsvg).
> 
> This is fixed now.

Your change:

-if test "${HAVE_X11}" = "yes" || test "${HAVE_NS}" = "yes"; then
+if test "${HAVE_X11}" = "yes"; then

removes SVG support for the GNUstep port, which was working just fine
for me on GNU/Linux.

Re: Emacs 23.1.90 pretest

[Jan Djärv]

Yavor Doganov skrev:
> Jan Djärv wrote:
>>> Thanks Jan, with the option --without-gconf it builds (altough it
>>> doesn't with the option --without-rsvg).
>> This is fixed now.
> 
> Your change:
> 
> -if test "${HAVE_X11}" = "yes" || test "${HAVE_NS}" = "yes"; then
> +if test "${HAVE_X11}" = "yes"; then
> 
> removes SVG support for the GNUstep port, which was working just fine
> for me on GNU/Linux.

Testing for NS was totally wrong.  I added a test for GNUStep now.

	Jan D.

Re: Emacs 23.1.90 pretest

[Yavor Doganov]

Jan Djärv wrote:
> Testing for NS was totally wrong.

I'm puzzled.

Adrian added the SVG support for the NS port (my initial patch was
broken), so presumably he tested it on MacOS.  I have no way to know
for certain, but until now I thought that Emacs.app supports SVG on
MacOS via librsvg, the same way it does on GNUstep platforms.

Perhaps the OP's librsvg installation was broken/incomplete or
something else...  Anyway, personally I only care that it keeps
working on GNUstep.

Re: Emacs 23.1.90 pretest

[Jan Djärv]

10 dec 2009 kl. 20.50 skrev Yavor Doganov <yavor@gnu.org>:

> Jan Djärv wrote:
>> Testing for NS was totally wrong.
>
> I'm puzzled.
>
> Adrian added the SVG support for the NS port (my initial patch was
> broken), so presumably he tested it on MacOS.  I have no way to know
> for certain, but until now I thought that Emacs.app supports SVG on
> MacOS via librsvg, the same way it does on GNUstep platforms.
>
> Perhaps the OP's librsvg installation was broken/incomplete or
> something else...  Anyway, personally I only care that it keeps
> working on GNUstep.
>

Librsvg can not work on OSX except with X11. Librsvg is totally  
dependent on X11.

       Jan D.

Re: Emacs 23.1.90 pretest

[Yavor Doganov]

Jan Djärv wrote:
> Librsvg can not work on OSX except with X11. Librsvg is totally  
> dependent on X11.

Ah.  Forgive my ignorance, but my impression was that X11 is usually
installed on that platform and in any case, no harm could be done if
librsvg is not found.

I configure Emacs.app --with-ns --without-x; here are all the
libraries linked:

  -lgnustep-gui -lgnustep-base -lobjc -lpthread -lasound -lrsvg-2
  -lgdk_pixbuf-2.0 -lm -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl
  -lglib-2.0 -ldbus-1 -lgpm -lncurses -lm

As you observe, the GLib/GDK stuff comes from `pkg-config --libs
librsvg-2.0', a fair price to pay given the fact that librsvg is
already present on a typical GNUstep workstation as a dependency of
the LaTeX service, a popular package.  Of course, the Emacs executable
indirectly links with X libs in my case, which sort of explains my
initial bewilderment.

Re: Emacs 23.1.90 pretest

[Chong Yidong]

Yavor Doganov <yavor@gnu.org> writes:

> Jan Djärv wrote:
>> Librsvg can not work on OSX except with X11. Librsvg is totally
>> dependent on X11.
>
> Ah.  Forgive my ignorance, but my impression was that X11 is usually
> installed on that platform and in any case, no harm could be done if
> librsvg is not found.

Adrian (or any OS X user), could you comment?

Re: Emacs 23.1.90 pretest

[Jan Djärv]

11 dec 2009 kl. 18.15 skrev Chong Yidong <cyd@stupidchicken.com>:

> Yavor Doganov <yavor@gnu.org> writes:
>
>> Jan Djärv wrote:
>>> Librsvg can not work on OSX except with X11. Librsvg is totally
>>> dependent on X11.
>>
>> Ah.  Forgive my ignorance, but my impression was that X11 is usually
>> installed on that platform and in any case, no harm could be done if
>> librsvg is not found.
>
> Adrian (or any OS X user), could you comment?

I am an OSX user...

     Jan D.

Re: Emacs 23.1.90 pretest

[Yavor Doganov]

Jan Djärv wrote:
> >>> Librsvg can not work on OSX except with X11. Librsvg is totally
> >>> dependent on X11.
> >>
> >> Ah.  Forgive my ignorance, but my impression was that X11 is usually
> >> installed on that platform and in any case, no harm could be done if
> >> librsvg is not found.
> >
> > Adrian (or any OS X user), could you comment?
> 
> I am an OSX user...

Your last change seems good enough for me (it reinstates SVG support
on GNUstep), but AFAICS there's still something fishy here.

If the initial test for 

   HAVE_X11 || HAVE_NS

caused configure to find librsvg for the OP, and librsvg depends on
X11, and he had a build failure during compilation because of
unresolved X symbols (IIRC), isn't this an indication that his
installation is somewhat broken?  (I still can't explain myself why
the test was wrong in the first place as you say.)

Re: Emacs 23.1.90 pretest

[chad]

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

On Dec 11, 2009, at 1:36 PM, Yavor Doganov wrote:

> Jan Djärv wrote:
>> 
>> Librsvg can not work on OSX except with X11. Librsvg is totally
>> dependent on X11. 
> [...]
> Your last change seems good enough for me (it reinstates SVG support
> on GNUstep), but AFAICS there's still something fishy here.
> 
> If the initial test for 
> 
>   HAVE_X11 || HAVE_NS
> 
> caused configure to find librsvg for the OP, and librsvg depends on
> X11, and he had a build failure during compilation because of
> unresolved X symbols (IIRC), isn't this an indication that his
> installation is somewhat broken?  (I still can't explain myself why
> the test was wrong in the first place as you say.)

OS X comes with a full X11 setup that it can run as a sort of `hosted' window system, distinct from the native system used by --with-ns.  I would expect it to be fairly common to see developers on macosx with X11, Gnome, GTK, and perhaps even librsvg installed.   Neither emacs not any other application of which I am aware *under macosx* can deal with both X11 and Carbon/Cocoa/Quartz at the same time, so simply finding the libraries installed is not sufficient to tell you (or configure) if the library should be used.   It is possible that GNUStep systems can use both, since they implement one in terms of the other -- I'm unfamiliar with GNUStep these days.

*Chad


[-- Attachment #2: Type: text/html, Size: 2205 bytes --]

Re: Emacs 23.1.90 pretest

[Jan Djärv]

Yavor Doganov skrev 2009-12-11 22.36:
> Jan Djärv wrote:
>>>>> Librsvg can not work on OSX except with X11. Librsvg is totally
>>>>> dependent on X11.
>>>>
>>>> Ah.  Forgive my ignorance, but my impression was that X11 is usually
>>>> installed on that platform and in any case, no harm could be done if
>>>> librsvg is not found.
>>>
>>> Adrian (or any OS X user), could you comment?
>>
>> I am an OSX user...
>
> Your last change seems good enough for me (it reinstates SVG support
> on GNUstep), but AFAICS there's still something fishy here.
>
> If the initial test for
>
>     HAVE_X11 || HAVE_NS
>
> caused configure to find librsvg for the OP, and librsvg depends on
> X11, and he had a build failure during compilation because of
> unresolved X symbols (IIRC), isn't this an indication that his
> installation is somewhat broken?  (I still can't explain myself why
> the test was wrong in the first place as you say.)
>

GNUStep runs on top of X11.  OSX normal GUI is a totally different beast 
(Cocoa on display PDF).  Both use the NS API.  Emacs can not mix two different 
GUIs.  Just because the libs are there doesn't mean it doesn't hurt to link in 
them.  The event handling, window handling, and all other stuff are compleatly 
different.  You don't expect X11 libs to work on W32 by just linking them in 
to the executble do you?

The libs are there, but shall not be linked in unless GNUStep, and thereby 
X11, is used.


	Jan D.

Re: Emacs 23.1.90 pretest

[Yavor Doganov]

Jan Djärv wrote:
> The libs are there, but shall not be linked in unless GNUStep, and
> thereby X11, is used.

Thanks for the explanation.  This means that SVG support is not
available for MacOS users, unless they configure for a GTK+/Lucid
build, which is of course a different thing.

It's a relief to find at least one advantage of the GNUstep port on
top of the many regressions.

Re: Emacs 23.1.90 pretest

[David Reitter]

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

On Dec 11, 2009, at 12:15 PM, Chong Yidong wrote:
>>> Librsvg can not work on OSX except with X11. Librsvg is totally
>>> dependent on X11.
>> 
>> Ah.  Forgive my ignorance, but my impression was that X11 is usually
>> installed on that platform and in any case, no harm could be done if
>> librsvg is not found.
> 
> Adrian (or any OS X user), could you comment?

No, X11 is not installed on OS X by default.  It is a separate install.    


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: Emacs 23.1.90 pretest

[Chming]

1) the indent function seems broken.

like this:

#ifdef MACRO
void foo(int i,
             int j,
             int k);
#endif

i, j and k will not aligned correctly.

2) C-M-a does not work correctly sometimes. It will jump to the last {
or somewhere else instead of the beginning of func, esp. if there are
some #ifdef macros around.

Thanks,

Ming

Re: Emacs 23.1.90 pretest

[Chong Yidong]

Jan Djärv <jan.h.d@swipnet.se> writes:

>> Thanks Jan, with the option --without-gconf it builds (altough it
>> doesn't with the option --without-rsvg).
>>
> This is fixed now.
>
> Thanks for testing.

Why did the bug arise in the first place?  In the configure test,

   PKG_CHECK_MODULES(GCONF, gconf-2.0 >= 2.13, HAVE_GCONF=yes, HAVE_GCONF=no)

should have returned HAVE_GCONF=no on OS X (I assume the Gconf libraries
wouldn't be present).  So HAVE_GCONF should not have been defined.

Re: Emacs 23.1.90 pretest

[Jan Djärv]

11 dec 2009 kl. 18.19 skrev Chong Yidong <cyd@stupidchicken.com>:

> Jan Djärv <jan.h.d@swipnet.se> writes:
>
>>> Thanks Jan, with the option --without-gconf it builds (altough it
>>> doesn't with the option --without-rsvg).
>>>
>> This is fixed now.
>>
>> Thanks for testing.
>
> Why did the bug arise in the first place?  In the configure test,
>
>   PKG_CHECK_MODULES(GCONF, gconf-2.0 >= 2.13, HAVE_GCONF=yes,  
> HAVE_GCONF=no)
>
> should have returned HAVE_GCONF=no on OS X (I assume the Gconf  
> libraries
> wouldn't be present).  So HAVE_GCONF should not have been defined.

Gconf libraries and the rest of Gnome are present if you install Fink  
on OSX as the reporters seem to have done.

      Jan D.

Re: Emacs 23.1.90 pretest

[Jan Djärv]

Jan Djärv skrev 2009-12-11 21.05:
>
>
> Gconf libraries and the rest of Gnome are present if you install Fink on
> OSX as the reporters seem to have done.

Fink or MacPorts

	Jan D.

Re: Emacs 23.1.90 pretest

[Andreas Schwab]

Please make sure loaddefs.el (and ldefs-boot.el) is up-to-date.  The
included loaddefs.el lacks all autoloads from tool-bar.el, for example.
Also, please update your tree before tagging the it, the
EMACS_PRETEST_23_1_90 tag lacks the last change from Stefan before your
checkin.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs 23.1.90 pretest

[Chong Yidong]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Please make sure loaddefs.el (and ldefs-boot.el) is up-to-date.  The
> included loaddefs.el lacks all autoloads from tool-bar.el, for example.

That's odd.  A `make autoloads' does not regenerate the autoloads from
tool-bar.el, either.

> Also, please update your tree before tagging the it, the
> EMACS_PRETEST_23_1_90 tag lacks the last change from Stefan before your
> checkin.

Unfortunately, this kind of thing tends to happen in first pretests when
people try to squeeze stuff in at the last minute as I'm rolling the
tarball.

Re: Emacs 23.1.90 pretest

[Andreas Schwab]

Chong Yidong <cyd@stupidchicken.com> writes:

> Unfortunately, this kind of thing tends to happen in first pretests when
> people try to squeeze stuff in at the last minute as I'm rolling the
> tarball.

You can avoid that if you use cvs rtag.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs 23.1.90 pretest

[Stefan Monnier]

>> Unfortunately, this kind of thing tends to happen in first pretests when
>> people try to squeeze stuff in at the last minute as I'm rolling the
>> tarball.

> You can avoid that if you use cvs rtag.

I thought rtag was the problematic one.  I always use `tag' instead, so
I know it tags exactly the files I'm seeing at the moment.  Then you can
use that tag to export those exact same files to build a tarball, no
matter what else happens on the trunk in the mean time.


        Stefan

Re: Emacs 23.1.90 pretest

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Unfortunately, this kind of thing tends to happen in first pretests when
>>> people try to squeeze stuff in at the last minute as I'm rolling the
>>> tarball.
>
>> You can avoid that if you use cvs rtag.
>
> I thought rtag was the problematic one.  I always use `tag' instead, so
> I know it tags exactly the files I'm seeing at the moment.

The right way is to use rtag, then do a fresh checkout of that tag.
That's the only way to guarantee a consistent tag.

> Then you can use that tag to export those exact same files to build a
> tarball, no matter what else happens on the trunk in the mean time.

As you can see with the EMACS_PRETEST_23_1_90 tag, this can result in
the wrong revisions to be tagged.  As a result the git tree is unable to
accurately represent that tag.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs 23.1.90 pretest

[Stefan Monnier]

>>>> Unfortunately, this kind of thing tends to happen in first pretests when
>>>> people try to squeeze stuff in at the last minute as I'm rolling the
>>>> tarball.
>>> You can avoid that if you use cvs rtag.
>> I thought rtag was the problematic one.  I always use `tag' instead, so
>> I know it tags exactly the files I'm seeing at the moment.
> The right way is to use rtag, then do a fresh checkout of that tag.
> That's the only way to guarantee a consistent tag.

"consistent" in which sense?

>> Then you can use that tag to export those exact same files to build a
>> tarball, no matter what else happens on the trunk in the mean time.
> As you can see with the EMACS_PRETEST_23_1_90 tag, this can result in
> the wrong revisions to be tagged.

I really can't imagine why "tag" would be a problem.  "tag" is suppose
to tag exactly the revisions of the files you have currently checked
out, so if those files are fine, so is your tag.

Luckily, I soon won't have to worry about such CVS idiosyncrasies
any more.

> As a result the git tree is unable to accurately represent that tag.

I can definitely imagine lots of cases where it might be very difficult
to represent tags properly when translating from CVS to something else,
regardless of how the tag was applied.


        Stefan

Re: Emacs 23.1.90 pretest

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> "consistent" in which sense?

Consistent in time.

> I really can't imagine why "tag" would be a problem.  "tag" is suppose
> to tag exactly the revisions of the files you have currently checked
> out, so if those files are fine, so is your tag.

That's exactly the problem.  Your checked out files may be out of date
wrt. the repository.

> I can definitely imagine lots of cases where it might be very difficult
> to represent tags properly when translating from CVS to something else,
> regardless of how the tag was applied.

If you tag consistently there won't be any problem.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs 23.1.90 pretest

[Stefan Monnier]

>> I really can't imagine why "tag" would be a problem.  "tag" is suppose
>> to tag exactly the revisions of the files you have currently checked
>> out, so if those files are fine, so is your tag.
> That's exactly the problem.  Your checked out files may be out of date
> wrt. the repository.

"Out of date" in which sense?  You mean, there might have been some
commits performed since?  Of course, that's true, but it doesn't matter
because "tag" will use the revisions in your tree, which should all be
self-consistent.  So it will be the same result as if "tag" was
performed (onsistently) when your file have been checked out
(i.e. before the checkins that may have happened in the mean time).
You can checkout, wait for a year, and then perform "tag", and it will
still be consistent.


        Stefan

Re: Emacs 23.1.90 pretest

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I really can't imagine why "tag" would be a problem.  "tag" is suppose
>>> to tag exactly the revisions of the files you have currently checked
>>> out, so if those files are fine, so is your tag.
>> That's exactly the problem.  Your checked out files may be out of date
>> wrt. the repository.
>
> "Out of date" in which sense?  You mean, there might have been some
> commits performed since?

No, there were some commits performed before!

> Of course, that's true, but it doesn't matter because "tag" will use
> the revisions in your tree, which should all be self-consistent.

But it is inconsistent with the One True Repository.

> You can checkout, wait for a year, and then perform "tag", and it will
> still be consistent.

But not consistent with a checkout by date.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs 23.1.90 pretest

[Stefan Monnier]

>>>> I really can't imagine why "tag" would be a problem.  "tag" is suppose
>>>> to tag exactly the revisions of the files you have currently checked
>>>> out, so if those files are fine, so is your tag.
>>> That's exactly the problem.  Your checked out files may be out of date
>>> wrt. the repository.
>> 
>> "Out of date" in which sense?  You mean, there might have been some
>> commits performed since?

> No, there were some commits performed before!

Before what?
Here's how the scenario I have in mind:

   cvs update
   ...blabla build, glance at it, try it out, maybe make a tarball of it...
   cvs tag

In what way can this be inconsistent with "the One True Repository"?
In what way is this going to be inconsistent with a checkout by date?
In what way could commits performed "before" affect the consistency?
Is this yet another CVS breakage of which I'm not aware?


        Stefan

Re: Emacs 23.1.90 pretest

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> In what way is this going to be inconsistent with a checkout by date?

Compare EMACS_PRETEST_23_1_90 in CVS with EMACS_PRETEST_23_1_90 in git.

> Is this yet another CVS breakage of which I'm not aware?

It is improper use of CVS in a changeset oriented world of VCS.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs 23.1.90 pretest

[Stephen J. Turnbull]

Stefan Monnier writes:

 > Here's how the scenario I have in mind:
 > 
 >    cvs update
 >    ...blabla build, glance at it, try it out, maybe make a tarball of it...
 >    cvs tag
 >
 > In what way can this be inconsistent with "the One True Repository"?

As you know, CVS commits are not atomic.  You are both wrong when you
write of "One True Repository."  In CVS you simply cannot have a True
Repository in the sense of "true to the Emacs we want to build for
ourselves and distribute to others" without restricting commits to one
developer at a time.

 > In what way is this going to be inconsistent with a checkout by date?

I don't know about your release process, but mine involves testing,
then bumping the version number in configure.ac and version.sh.in, and
putting a release herald in the ChangeLogs, then tagging.  If this
happens:

    cvs update
    ... I build build, test, bump
    ... concurrently, Stefan commits
    cvs commit <exactly the version bump changes, assume no conflicts>
    cvs tag

then the tag spans in time, but does not include, your commit, and in
that sense is inconsistent with checkout by date.

Andreas's procedure using rtag is prohibitively inconvenient, IMO,
because it involves either tagging an untested version or analysis of
changes by others *and* a full test run *after* the tag is created.
If using tag is "inconsistent with a dVCS world", well, what else is
new?

The right way to handle this in CVS IMO is to use "tag", accept the
date/tag inconsistencies for prereleases, and to prohibit commits by
anyone but the release engineer from "cvs update" to "cvs tag" for
public releases.  In that case cvs tag is almost equivalent to cvs
rtag (at least in some versions of CVS there were anomolies having to
do with files that don't exist on the branch being tagged).

Again IMO CVS checkouts by date are only useful for bisection, usually
result in identifying a unique commit, and even if the best you can do
is isolate to a period of say 1 hour with a half-dozen commits, that's
not going to be any worse than (say) bisecting and coming up with the
multi-tty merge as the culprit.  You take a diff and start bisecting
by hunks rather than by time.

Re: Emacs 23.1.90 pretest

[David Kastrup]

"Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:

> Stefan Monnier writes:
>
>  > Here's how the scenario I have in mind:
>  > 
>  >    cvs update
>  >    ...blabla build, glance at it, try it out, maybe make a tarball of it...
>  >    cvs tag
>  >
>  > In what way can this be inconsistent with "the One True Repository"?
>
> As you know, CVS commits are not atomic.  You are both wrong when you
> write of "One True Repository."  In CVS you simply cannot have a True
> Repository in the sense of "true to the Emacs we want to build for
> ourselves and distribute to others" without restricting commits to one
> developer at a time.
>
>  > In what way is this going to be inconsistent with a checkout by
>  > date?
>
> I don't know about your release process, but mine involves testing,
> then bumping the version number in configure.ac and version.sh.in, and
> putting a release herald in the ChangeLogs, then tagging.  If this
> happens:
>
>     cvs update
>     ... I build build, test, bump
>     ... concurrently, Stefan commits
>     cvs commit <exactly the version bump changes, assume no conflicts>
>     cvs tag
>
> then the tag spans in time, but does not include, your commit, and in
> that sense is inconsistent with checkout by date.

Which is utterly uninteresting in every respect.  The important thing is
that the version is tagged that has been tested and which is intended to
be released.  Whether or not that tag can be represented as "state of
repository at a certain point of time" is not only irrelevant, but the
point is _exactly_ that one does not want to have some state of the
repository tagged, but the state that has been tested and approved as
_release_.

> Andreas's procedure using rtag is prohibitively inconvenient, IMO,
> because it involves either tagging an untested version or analysis of
> changes by others *and* a full test run *after* the tag is created.
> If using tag is "inconsistent with a dVCS world", well, what else is
> new?

Of course "inconsistent with a dVCS world" is completely nonsense.  The
whole point of dVCS is that you tag what constitutes a version at _your_
local site.  This tag does _not_ apply to anything in a central
repository that is not identical to the version at your local site.

> The right way to handle this in CVS IMO is to use "tag", accept the
> date/tag inconsistencies for prereleases, and to prohibit commits by
> anyone but the release engineer from "cvs update" to "cvs tag" for
> public releases.

I don't see why "state of the repository at time point x" is relevant
for anything.

-- 
David Kastrup

Re: Emacs 23.1.90 pretest

[Stephen J. Turnbull]

David Kastrup writes:

 > I don't see why "state of the repository at time point x" is relevant
 > for anything.

*shrug*  Stefan asked about "consistency", I explained.  The remarks
labelled "IMO" should be construed to mean I agree with you about
relevance.

Re: Emacs 23.1.90 pretest

[Steven Knight]

On Wed Dec 09 2009 11:31:58 GMT-0500 (EST), Dave Donelan wrote:
> Emacs pretest 23.1.90 is now available for download via FTP, at the
> following location:
>
>    ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
>
> The xdelta against Emacs 23.1 is here:
>
>    ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1-23.1.90.xdelta
>
> This is the first pretest for what will be the Emacs 23.2 release.
>
> Pretesters: please send me an email reporting success or failure on your
> build platform.  Report bugs via M-x report-emacs-bugs, or email
> emacs-pretest-bug@gnu.org.  For questions, email emacs-devel@gnu.org.
>
> Note that the default for `mail-user-agent' has been changed from Mail
> mode to Message mode; if you have Mail mode-specific customizations,
> please check them.
>
> There are quite a number of changes relative to Emacs 23.1, including
> several new packages, notably the CEDET package of development tools.
> See etc/NEWS for details.
>
>
> Emacs developers: please note that the tree is now frozen.  No new
> features are allowed, unless agreed to by Stefan or myself.  Changes
> that are bug fixes or improvements to documentations may still be
> committed directly; when in doubt, send email to emacs-devel@gnu.org.  I
> think we will probably begin Emacs 24 development soon-ish, once we make
> the switch from CVS to BZR (we can discuss this further on emacs-devel).
>
> Thanks.
>
>
>    
Hi,

I built and installed Emacs on Fedora 11; I did not encounter any errors 
when building.

When starting up Emacs, I get the following:

$ emacs -Q

(emacs:31419): Gtk-CRITICAL **: gtk_window_resize: assertion `width > 0' 
failed

and the computer emits a beep.

When doing this:

$ emacs -Q -nw

Emacs starts-ups fine.

Please let me know if I should be posting this somewhere else or if you 
need more information.

Thanks,

-- 
Steven Knight
steven.knight@unh.edu

Re: Emacs 23.1.90 pretest

[Jan Djärv]

Steven Knight skrev:
> On Wed Dec 09 2009 11:31:58 GMT-0500 (EST), Dave Donelan wrote:
>> Emacs pretest 23.1.90 is now available for download via FTP, at the
>> following location:
>>
>>    ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
>>
>> The xdelta against Emacs 23.1 is here:
>>
>>    ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1-23.1.90.xdelta
>>
>> This is the first pretest for what will be the Emacs 23.2 release.
>>
>> Pretesters: please send me an email reporting success or failure on your
>> build platform.  Report bugs via M-x report-emacs-bugs, or email
>> emacs-pretest-bug@gnu.org.  For questions, email emacs-devel@gnu.org.
>>
>> Note that the default for `mail-user-agent' has been changed from Mail
>> mode to Message mode; if you have Mail mode-specific customizations,
>> please check them.
>>
>> There are quite a number of changes relative to Emacs 23.1, including
>> several new packages, notably the CEDET package of development tools.
>> See etc/NEWS for details.
>>
>>
>> Emacs developers: please note that the tree is now frozen.  No new
>> features are allowed, unless agreed to by Stefan or myself.  Changes
>> that are bug fixes or improvements to documentations may still be
>> committed directly; when in doubt, send email to emacs-devel@gnu.org.  I
>> think we will probably begin Emacs 24 development soon-ish, once we make
>> the switch from CVS to BZR (we can discuss this further on emacs-devel).
>>
>> Thanks.
>>
>>
>>    
> Hi,
> 
> I built and installed Emacs on Fedora 11; I did not encounter any errors 
> when building.
> 
> When starting up Emacs, I get the following:
> 
> $ emacs -Q
> 
> (emacs:31419): Gtk-CRITICAL **: gtk_window_resize: assertion `width > 0' 
> failed
> 
> and the computer emits a beep.
> 
> When doing this:
> 
> $ emacs -Q -nw
> 
> Emacs starts-ups fine.
> 
> Please let me know if I should be posting this somewhere else or if you 
> need more information.
> 

What happens if you do
% emacs -Q -fn fixed
or if that fails
% emacs -Q -fn fixed -g 80x24

	Jan D.

Re: Emacs 23.1.90 pretest

[Steven Knight]

On Wed Dec 09 2009 11:31:58 GMT-0500 (EST), Dave Donelan wrote:
> Steven Knight skrev:
>> On Wed Dec 09 2009 11:31:58 GMT-0500 (EST), Dave Donelan wrote:
>>> Emacs pretest 23.1.90 is now available for download via FTP, at the
>>> following location:
>>>
>>>    ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1.90.tar.gz
>>>
>>> The xdelta against Emacs 23.1 is here:
>>>
>>>    ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-23.1-23.1.90.xdelta
>>>
>>> This is the first pretest for what will be the Emacs 23.2 release.
>>>
>>> Pretesters: please send me an email reporting success or failure on 
>>> your
>>> build platform.  Report bugs via M-x report-emacs-bugs, or email
>>> emacs-pretest-bug@gnu.org.  For questions, email emacs-devel@gnu.org.
>>>
>>> Note that the default for `mail-user-agent' has been changed from Mail
>>> mode to Message mode; if you have Mail mode-specific customizations,
>>> please check them.
>>>
>>> There are quite a number of changes relative to Emacs 23.1, including
>>> several new packages, notably the CEDET package of development tools.
>>> See etc/NEWS for details.
>>>
>>>
>>> Emacs developers: please note that the tree is now frozen.  No new
>>> features are allowed, unless agreed to by Stefan or myself.  Changes
>>> that are bug fixes or improvements to documentations may still be
>>> committed directly; when in doubt, send email to 
>>> emacs-devel@gnu.org.  I
>>> think we will probably begin Emacs 24 development soon-ish, once we 
>>> make
>>> the switch from CVS to BZR (we can discuss this further on 
>>> emacs-devel).
>>>
>>> Thanks.
>>>
>>>
>> Hi,
>>
>> I built and installed Emacs on Fedora 11; I did not encounter any 
>> errors when building.
>>
>> When starting up Emacs, I get the following:
>>
>> $ emacs -Q
>>
>> (emacs:31419): Gtk-CRITICAL **: gtk_window_resize: assertion `width > 
>> 0' failed
>>
>> and the computer emits a beep.
>>
>> When doing this:
>>
>> $ emacs -Q -nw
>>
>> Emacs starts-ups fine.
>>
>> Please let me know if I should be posting this somewhere else or if 
>> you need more information.
>>
>
> What happens if you do
> % emacs -Q -fn fixed
> or if that fails
> % emacs -Q -fn fixed -g 80x24
>
>     Jan D.
>
>
>
Hi,

Using either of the above commands starts emacs without issue.  How do I 
resolve my issue without using the font fixed?  Also I should have 
mentioned that using emacs 23.1 I was to build and start emacs without 
issue.

Thanks,

-- 
Steven Knight
steven.knight@unh.edu

Re: Emacs 23.1.90 pretest

[Jan Djärv]

Steven Knight skrev 2009-12-09 20.21:

>> What happens if you do
>> % emacs -Q -fn fixed
>> or if that fails
>> % emacs -Q -fn fixed -g 80x24
>>
>> Jan D.
>>
>>
>>
> Hi,
>
> Using either of the above commands starts emacs without issue. How do I
> resolve my issue without using the font fixed? Also I should have
> mentioned that using emacs 23.1 I was to build and start emacs without
> issue.
>

First we need to find out what font you are trying to use.  Can you start 23.1 
that works and in *scratch* evaluate

(frame-parameter nil 'font)

and see what it returns?

	Jan D.

Re: Emacs 23.1.90 pretest

[Steven Knight]

On Wed Dec 09 2009 15:44:06 GMT-0500 (EST), Jan Djärv wrote:
> First we need to find out what font you are trying to use.  Can you 
> start 23.1 that works and in *scratch* evaluate
>
> (frame-parameter nil 'font)
>
> and see what it returns?
>
>     Jan D.
>
>

Hi,

You bet. I started emacs (using emacs -Q) and evaluated the above code.  
Here is the result:

-unknown-DejaVu Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1

Thanks,

-- 
Steven Knight
steven.knight@unh.edu

Re: Emacs 23.1.90 pretest

[Jan D.]

On 2009-12-09 22:20, Steven Knight wrote:
> On Wed Dec 09 2009 15:44:06 GMT-0500 (EST), Jan Djärv wrote:
>> First we need to find out what font you are trying to use. Can you
>> start 23.1 that works and in *scratch* evaluate
>>
>> (frame-parameter nil 'font)
>>
>> and see what it returns?
>>
>> Jan D.
>>
>>
>
> Hi,
>
> You bet. I started emacs (using emacs -Q) and evaluated the above code.
> Here is the result:
>
> -unknown-DejaVu Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1
>

Hmm.  I think you must debug this, I'm trying to figure out where.
Does starting with -fn Monospace-12 work?

Can you start gdb on emacs and set a breakpoint in 
x_default_font_parameter?  A session would look something like:
(gdb) b x_default_font_parameter
(gdb) r -Q
break in x_default_font_parameter

And then type n to step through and print out variables as they are 
assigned:
(gdb) p font
(gdb) pr

and
(gdb) p system_font

I hope we find something here.

	Jan D.

Re: Emacs 23.1.90 pretest

[Steven Knight]

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

On Fri Dec 11 2009 02:47:26 GMT-0500 (EST), Jan D. wrote:
> On 2009-12-09 22:20, Steven Knight wrote:
>> On Wed Dec 09 2009 15:44:06 GMT-0500 (EST), Jan Djärv wrote:
>>> First we need to find out what font you are trying to use. Can you
>>> start 23.1 that works and in *scratch* evaluate
>>>
>>> (frame-parameter nil 'font)
>>>
>>> and see what it returns?
>>>
>>> Jan D.
>>>
>>>
>>
>> Hi,
>>
>> You bet. I started emacs (using emacs -Q) and evaluated the above code.
>> Here is the result:
>>
>> -unknown-DejaVu Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1
>>
>
> Hmm.  I think you must debug this, I'm trying to figure out where.
> Does starting with -fn Monospace-12 work?
$ emacs -Q -fn Monospace-12
Arithmetic error
>
> Can you start gdb on emacs and set a breakpoint in 
> x_default_font_parameter?  A session would look something like:
> (gdb) b x_default_font_parameter
> (gdb) r -Q
> break in x_default_font_parameter
>
> And then type n to step through and print out variables as they are 
> assigned:
> (gdb) p font
> (gdb) pr
>
> and
> (gdb) p system_font
>
I will do this and let you know.

I've attached a copy of my config.log file (bzipped).  I am running 
emacs-23.1.90 on a Fedora 11 system under KDE 4.3.3.

Thanks for all the help,

-- 
Steven Knight
steven.knight@unh.edu


[-- Attachment #2: config.log.bz2 --]
[-- Type: application/octet-stream, Size: 17158 bytes --]

Re: Emacs 23.1.90 pretest

[Jan D.]

On 2009-12-11 15:50, Steven Knight wrote:
> On Fri Dec 11 2009 02:47:26 GMT-0500 (EST), Jan D. wrote:
>> On 2009-12-09 22:20, Steven Knight wrote:
>>> On Wed Dec 09 2009 15:44:06 GMT-0500 (EST), Jan Djärv wrote:
>>>> First we need to find out what font you are trying to use. Can you
>>>> start 23.1 that works and in *scratch* evaluate
>>>>
>>>> (frame-parameter nil 'font)
>>>>
>>>> and see what it returns?
>>>>
>>>> Jan D.
>>>>
>>>>
>>>
>>> Hi,
>>>
>>> You bet. I started emacs (using emacs -Q) and evaluated the above code.
>>> Here is the result:
>>>
>>> -unknown-DejaVu Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1
>>>
>>
>> Hmm. I think you must debug this, I'm trying to figure out where.
>> Does starting with -fn Monospace-12 work?
> $ emacs -Q -fn Monospace-12
> Arithmetic error

Wow, that was unexpected.  I think I have to install Fedora 11 and KDE.

	Jan D.

Re: Emacs 23.1.90 pretest

[Jan Djärv]

Steven Knight skrev 2009-12-11 15.50:
> On Fri Dec 11 2009 02:47:26 GMT-0500 (EST), Jan D. wrote:
>> On 2009-12-09 22:20, Steven Knight wrote:
>>> On Wed Dec 09 2009 15:44:06 GMT-0500 (EST), Jan Djärv wrote:
>>>> First we need to find out what font you are trying to use. Can you
>>>> start 23.1 that works and in *scratch* evaluate
>>>>
>>>> (frame-parameter nil 'font)
>>>>
>>>> and see what it returns?
>>>>
>>>> Jan D.
>>>>
>>>>
>>>
>>> Hi,
>>>
>>> You bet. I started emacs (using emacs -Q) and evaluated the above code.
>>> Here is the result:
>>>
>>> -unknown-DejaVu Sans Mono-normal-normal-normal-*-16-*-*-*-m-0-iso10646-1
>>>
>>
>> Hmm. I think you must debug this, I'm trying to figure out where.
>> Does starting with -fn Monospace-12 work?
> $ emacs -Q -fn Monospace-12
> Arithmetic error
>>
>> Can you start gdb on emacs and set a breakpoint in
>> x_default_font_parameter? A session would look something like:
>> (gdb) b x_default_font_parameter
>> (gdb) r -Q
>> break in x_default_font_parameter
>>
>> And then type n to step through and print out variables as they are
>> assigned:
>> (gdb) p font
>> (gdb) pr
>>
>> and
>> (gdb) p system_font
>>
> I will do this and let you know.

No need now.

>
> I've attached a copy of my config.log file (bzipped). I am running
> emacs-23.1.90 on a Fedora 11 system under KDE 4.3.3.
>

Thanks, I found the problem after installing Fedora 11 with KDE.  Please test 
again with an updated Emacs.

	Jan D.

Re: Emacs 23.1.90 pretest

[Steven Knight]

On 12/12/2009 11:20 AM Jan Djärv wrote:
>
> Thanks, I found the problem after installing Fedora 11 with KDE. Please
> test again with an updated Emacs.
>
> Jan D.
>
>

Hi,

I checkout emacs from cvs and built it; and it works!  Thank you so much 
for your help.

Thanks,

-- 
--------------------------------------------------------------------------------
Steven Knight  steven.knight@unh.edu
-------------------------------------------------------------------------------

Re: Emacs 23.1.90 pretest

[David Robinow]

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

On Tue, Dec 8, 2009 at 9:54 PM, Chong Yidong <cyd@stupidchicken.com> wrote:

> This is the first pretest for what will be the Emacs 23.2 release.
>
> Pretesters: please send me an email reporting success or failure on your
> build platform.

nmake (VS2003) does not like {...} in makefile macros.
A few pairs seem to have crept in.

It builds fine on Windows XP Home with the attached patch.

[-- Attachment #2: makefile.w32.patches --]
[-- Type: application/octet-stream, Size: 1480 bytes --]

*** lib-src/makefile.w32-in.orig	2009-12-08 20:41:30.000000000 -0500
--- lib-src/makefile.w32-in	2009-12-09 09:56:23.375000000 -0500
***************
*** 191,202 ****
  OTHER_PLATFORM_SUPPORT = \
  	$(lispsource)dos-fns.elc \
  	$(lispsource)dos-vars.elc \
! 	${lispsource}term/internal.elc \
! 	${lispsource}term/pc-win.elc \
  	$(lispsource)x-dnd.elc \
  	$(lispsource)term/x-win.elc \
! 	${lispsource}emacs-lisp/easymenu.elc \
! 	${lispsource}term/ns-win.elc
  
  
  lisp1= \
--- 191,202 ----
  OTHER_PLATFORM_SUPPORT = \
  	$(lispsource)dos-fns.elc \
  	$(lispsource)dos-vars.elc \
! 	$(lispsource)term/internal.elc \
! 	$(lispsource)term/pc-win.elc \
  	$(lispsource)x-dnd.elc \
  	$(lispsource)term/x-win.elc \
! 	$(lispsource)emacs-lisp/easymenu.elc \
! 	$(lispsource)term/ns-win.elc
  
  
  lisp1= \
*** doc/lispintro/makefile.w32-in.orig	2009-10-28 10:20:50.000000000 -0400
--- doc/lispintro/makefile.w32-in	2009-12-09 09:53:25.453125000 -0500
***************
*** 54,60 ****
  emacs-lisp-intro.dvi: $(INFO_SOURCES)
  	$(ENVADD) $(TEXI2DVI) $(srcdir)/emacs-lisp-intro.texi
  
! emacs-lisp-intro.pdf: ${INFO_SOURCES}
  	$(ENVADD) $(TEXI2PDF) $(srcdir)/emacs-lisp-intro.texi
  
  emacs-lisp-intro.html: $(INFO_SOURCES)
--- 54,60 ----
  emacs-lisp-intro.dvi: $(INFO_SOURCES)
  	$(ENVADD) $(TEXI2DVI) $(srcdir)/emacs-lisp-intro.texi
  
! emacs-lisp-intro.pdf: $(INFO_SOURCES)
  	$(ENVADD) $(TEXI2PDF) $(srcdir)/emacs-lisp-intro.texi
  
  emacs-lisp-intro.html: $(INFO_SOURCES)

Re: Emacs 23.1.90 pretest

[Chong Yidong]

David Robinow <drobinow@gmail.com> writes:

> On Tue, Dec 8, 2009 at 9:54 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> This is the first pretest for what will be the Emacs 23.2 release.
>>
>> Pretesters: please send me an email reporting success or failure on your
>> build platform.
>
> nmake (VS2003) does not like {...} in makefile macros.
> A few pairs seem to have crept in.
>
> It builds fine on Windows XP Home with the attached patch.

Thanks; applied.

Re: Emacs 23.1.90 pretest

[Juanma Barranquero]

Non-obsolete python.el requires obsolete sym-comp.el, which produces a
warning "Package sym-comp is obsolete!" while loading python.el[c].

Re: Emacs 23.1.90 pretest

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

> Non-obsolete python.el requires obsolete sym-comp.el, which produces a
> warning "Package sym-comp is obsolete!" while loading python.el[c].

Stefan removed sym-comp usage from Python just before the pretest, but
left the (require 'sym-comp) statement in.  Removing it fixes this.

But the new completion-at-point for Python is completely broken.
Consider the following recipe:

1. C-x C-f foo.py
2. i M-TAB

=> Emacs loops while completion-at-point is working, apparently without
   any exit (I tried waiting for about a minute).

Re: Emacs 23.1.90 pretest

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> Juanma Barranquero <lekktu@gmail.com> writes:
>
>> Non-obsolete python.el requires obsolete sym-comp.el, which produces a
>> warning "Package sym-comp is obsolete!" while loading python.el[c].
>
> Stefan removed sym-comp usage from Python just before the pretest, but
> left the (require 'sym-comp) statement in.  Removing it fixes this.
>
> But the new completion-at-point for Python is completely broken.
> Consider the following recipe:
>
> 1. C-x C-f foo.py
> 2. i M-TAB
>
> => Emacs loops while completion-at-point is working, apparently without
>    any exit (I tried waiting for about a minute).

I found the problem: the code in Python was passing a string with text
property notation to the Python interpreter, confusing it.  Should be
fixed in the repository now.

RE: Emacs 23.1.90 pretest

[Drew Adams]

Will a Windows binary be posted for the pretest?
Or has it been posted already?

I looked here, but don't see one:
http://alpha.gnu.org/gnu/emacs/pretest/windows/