Emacs pretest 22.1.91

Emacs pretest 22.1.91

[Chong Yidong]

The second pretest for the Emacs 22.2 release is now available.  It
can be downloaded from

  http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.1.91.tar.gz

The xdelta against the 22.1.90 pretest is available at

  http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.1.90-22.1.91.xdelta

The CVS tag for this pretest is EMACS_PRETEST_22_1_91.

Please email emacs-devel@gnu.org if you encounter any problems with
the pretest.

Thanks.

Re: Emacs pretest 22.1.91

[Jason Rumney]

Windows binaries for the latest pretest are now available from

    http://alpha.gnu.org/gnu/emacs/pretest/windows


The release announcement follows:

Chong Yidong wrote:
> The second pretest for the Emacs 22.2 release is now available.  It
> can be downloaded from
>
>   http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.1.91.tar.gz
>
> The xdelta against the 22.1.90 pretest is available at
>
>   http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.1.90-22.1.91.xdelta
>
> The CVS tag for this pretest is EMACS_PRETEST_22_1_91.
>
> Please email emacs-devel@gnu.org if you encounter any problems with
> the pretest.
>
> Thanks.
>
>
>
>   

Re: Emacs pretest 22.1.91

[Takashi Hiromatsu]

Thank you for hard work.

At Tue, 19 Feb 2008 13:50:05 -0500,
Chong Yidong wrote:
> 
> The second pretest for the Emacs 22.2 release is now available.  It
> can be downloaded from
> 
>   http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.1.91.tar.gz
 
I succeed to build on Windows by cygwin make (version 3.80). Mostly work
fine, except called from cygwin shell. When called from cygwin shell, it
freezed during startup.

You can take binary from here:
    http://ntemacsjp.sourceforge.jp/matsuan/index.html

Please care that this binary was modified as below for user convenient.
    Japanese IME patch, transparency patch were implemented.
    Japanese fixed width fontsets were pre-defined.
    some fonts were defined for international HELLO.
    cygwin-mount.el & w32-symlinks.el were loaded.

Takashi Hiromatsu

Re: Emacs pretest 22.1.91

[Eli Zaretskii]

> Date: Thu, 21 Feb 2008 15:35:39 +0900
> From: Takashi Hiromatsu <matsuan@ca2.so-net.ne.jp>
> Cc: Chong Yidong <cyd@stupidchicken.com>
> 
> >   http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.1.91.tar.gz
>  
> I succeed to build on Windows by cygwin make (version 3.80). Mostly work
> fine, except called from cygwin shell. When called from cygwin shell, it
> freezed during startup.

Is it possible that the Cygwin shell sets up PATH so that Emacs finds
Cygwin-compiled image libraries before the native Windows libraries?

Re: Emacs pretest 22.1.91

[Claus]

On Thu, Feb 21, 2008 at 7:35 AM, Takashi Hiromatsu
<matsuan@ca2.so-net.ne.jp> wrote:
>     cygwin-mount.el & w32-symlinks.el were loaded.
>

Ah, cygwin-mount.el - too bad it doesn't seem to work anymore on newer
Emacs-Versions. It fails with "Cannot parse output from `mount'" on a
recent Emacs 23.0.60.1

Any idea what might have caused this? I'd like to investigate myself
but have no clue where to start.

Claus

Re: Emacs pretest 22.1.91

[Eli Zaretskii]

> Date: Fri, 22 Feb 2008 20:28:36 +0100
> From: Claus <claus.klingberg@gmail.com>
> 
> Ah, cygwin-mount.el - too bad it doesn't seem to work anymore on newer
> Emacs-Versions. It fails with "Cannot parse output from `mount'" on a
> recent Emacs 23.0.60.1
> 
> Any idea what might have caused this? I'd like to investigate myself
> but have no clue where to start.

Obviously, start with where the error message comes from, then work
your way up the traceback to find the culprit.

Re: Emacs pretest 22.1.91

[Takashi Hiromatsu]

> > I succeed to build on Windows by cygwin make (version 3.80). Mostly work
> > fine, except called from cygwin shell. When called from cygwin shell, it
> > freezed during startup.
> 
> Is it possible that the Cygwin shell sets up PATH so that Emacs finds
> Cygwin-compiled image libraries before the native Windows libraries?
Ah, you are right.

I installed libXpm-nox4.dll in same directory as emacs.exe. Then there
have been no problem till 22.1.90.

I checked 'image-library-alist, which was changed at 22.1.91.
    22.1.90
        ((xpm "xpm4.dll" "libXpm-nox4.dll" "libxpm.dll")...[snip]...)
    22.1.91
        ((xpm "libxpm.dll" "xpm4.dll" "libXpm-nox4.dll")...[snip]...)

This is the reason that emacs-22.1.91 read /usr/X11R5/bin/libXpm.dll first
on my system.

1. Why the Xpm library order in 'image-library-alist was changed?

2. Where libxpm.dll can be found?
    Other graphic libraries are found on the gnuwin32 homepage easily.

Takashi Hiromatsu

Re: Emacs pretest 22.1.91

[Eli Zaretskii]

> Date: Sat, 23 Feb 2008 12:51:30 +0900
> From: Takashi Hiromatsu <matsuan@ca2.so-net.ne.jp>
> Cc: Eli Zaretskii <eliz@gnu.org>
> 
> I checked 'image-library-alist, which was changed at 22.1.91.
>     22.1.90
>         ((xpm "xpm4.dll" "libXpm-nox4.dll" "libxpm.dll")...[snip]...)
>     22.1.91
>         ((xpm "libxpm.dll" "xpm4.dll" "libXpm-nox4.dll")...[snip]...)
> 
> This is the reason that emacs-22.1.91 read /usr/X11R5/bin/libXpm.dll first
> on my system.
> 
> 1. Why the Xpm library order in 'image-library-alist was changed?
> 
> 2. Where libxpm.dll can be found?

libXpm.dll is included in the binary distribution for Windows,
emacs-22.1.91-bin-i386.zip, that you can find on alpha.gnu.org.  Or
you can download libXpm-3.5.7-w32-src.zip from the same place and
build it with MinGW (see the file README in there).

Re: Emacs pretest 22.1.91

[Jason Rumney]

Takashi Hiromatsu wrote:
> 1. Why the Xpm library order in 'image-library-alist was changed?
>   
Because the one we are shipping with Emacs is called libxpm.dll. I ran 
into the same problem you are seeing when Gimp was in the path, because 
its xpm4.dll was incompatible with Emacs.

> 2. Where libxpm.dll can be found?
>   
http://alpha.gnu.org/gnu/emacs/pretest/windows/

(the DLL is bundled with the Emacs binaries, source is in 
libXpm-3.5.7-w32-src.zip)

Re: Emacs pretest 22.1.91

[Takashi Hiromatsu]

Thank you for your information.

At Sun, 24 Feb 2008 14:21:40 +0000,
Jason Rumney wrote:
> 
> Takashi Hiromatsu wrote:
> > 1. Why the Xpm library order in 'image-library-alist was changed?
> >   
> Because the one we are shipping with Emacs is called libxpm.dll. I ran
> into the same problem you are seeing when Gimp was in the path, because
> its xpm4.dll was incompatible with Emacs.

Could you teach me, what are the advances from or differences between
libxpm.dll from "xpm4.dll" or "libXpm-nox4.dll" ?

Now, we can get xpm4.dll easily from gnuwin32 homepage.(few years ago,
libXpm-nox4)

> > 2. Where libxpm.dll can be found?
> >   
> http://alpha.gnu.org/gnu/emacs/pretest/windows/
> 
> (the DLL is bundled with the Emacs binaries, source is in
> libXpm-3.5.7-w32-src.zip)
Thank you, I tried the DLL bundled with abovebinaries, then it works fine.

In my opinion,
    If your libxpm.dll has much advances than others, it should be placed
    at first in the alist. And it is better that the DLL can be take
    alone, not with huge package.
    If not, more popular one should be placed at first.

How do you think, Eli and Jason?

Takashi Hiromatsu

Re: Emacs pretest 22.1.91

[Juanma Barranquero]

On Mon, Feb 25, 2008 at 2:16 AM, Takashi Hiromatsu
<matsuan@ca2.so-net.ne.jp> wrote:

>  In my opinion,
>     If your libxpm.dll has much advances than others, it should be placed
>     at first in the alist. And it is better that the DLL can be take
>     alone, not with huge package.
>     If not, more popular one should be placed at first.

It is largely irrelevant how much "advanced" a release of libxpm is,
because Emacs is not a general interface to access its functions; it
just uses a subset of it for its purposes, a subset which is
implemented in all three of libxpm.dll, xpm4.dll and libXpm-nox4.dll.

Choosing one or the other is more a matter of stability (bug fixes,
etc.) and compatibility with Emacs. As libxpm.dll is now included in
the binary Windows distribution, certainly it makes sense to prefer
it, as it can be assumed it is relatively stable and compatible. If
the user really prefers to use another library, he can trivially
modify `image-library-alist' in his .emacs.

             Juanma

Re: Emacs pretest 22.1.91

[Jason Rumney]

Takashi Hiromatsu wrote:
> Could you teach me, what are the advances from or differences between
> libxpm.dll from "xpm4.dll" or "libXpm-nox4.dll" ?
>   
They are different names for the same library. On X, the library is 
called libXpm.so, or with its major version libXpm.so.4.

The version distributed with Emacs is based on the current version 
distributed with x.org X11R7.3, which is libXpm-3.5.7. I believe most 
other versions that are available for Windows are based on libXpm-3.4k 
unless they have picked up the latest version since I submitted the 
patches that were required to compile on Windows to x.org.

Re: Emacs pretest 22.1.91

[Takashi Hiromatsu]

Thank you for your detail explanation. For me, You meant that libxpm.dll
has advances in stability and compatibility area.

OK, could you placed the libxpm.dll alone on the web?
    http://alpha.gnu.org/gnu/emacs/pretest/windows/

In Japan, many peoples want to build Emacs by themselves to implement some
patches like japanese IME. Ofcourse they also want to use more stable
DLLs, but not want to download huge package.

Takashi Hiromatsu

At Mon, 25 Feb 2008 02:27:02 +0100,
Juanma Barranquero wrote:
> 
> On Mon, Feb 25, 2008 at 2:16 AM, Takashi Hiromatsu
> <matsuan@ca2.so-net.ne.jp> wrote:
> 
> >  In my opinion,
> >     If your libxpm.dll has much advances than others, it should be placed
> >     at first in the alist. And it is better that the DLL can be take
> >     alone, not with huge package.
> >     If not, more popular one should be placed at first.
> 
> It is largely irrelevant how much "advanced" a release of libxpm is,
> because Emacs is not a general interface to access its functions; it
> just uses a subset of it for its purposes, a subset which is
> implemented in all three of libxpm.dll, xpm4.dll and libXpm-nox4.dll.
> 
> Choosing one or the other is more a matter of stability (bug fixes,
> etc.) and compatibility with Emacs. As libxpm.dll is now included in
> the binary Windows distribution, certainly it makes sense to prefer
> it, as it can be assumed it is relatively stable and compatible. If
> the user really prefers to use another library, he can trivially
> modify `image-library-alist' in his .emacs.
> 
>              Juanma
> 
> 

Re: Emacs pretest 22.1.91

[Juanma Barranquero]

On Mon, Feb 25, 2008 at 2:57 AM, Takashi Hiromatsu
<matsuan@ca2.so-net.ne.jp> wrote:

> For me, You meant that libxpm.dll
>  has advances in stability and compatibility area.

No. I mean that Jason builds it, so we know it is compatible with the
binary distribution (they are presumably built with the same compiler,
for example), and it works OK. But I've been using xpm4.dll until now
and I've never seen any ill effect either.

> Ofcourse they also want to use more stable
>  DLLs, but not want to download huge package.

The barebin package also includes it and it is 4.6 MB.

             Juanma

Re: Emacs pretest 22.1.91

[Takashi Hiromatsu]

> it, as it can be assumed it is relatively stable and compatible. If
> the user really prefers to use another library, he can trivially
> modify `image-library-alist' in his .emacs.
It is bad idea, because he can't start Emacs with -q option.

Also he can modify the alist in his site-start.el, but can't start with
--no-site-start option.

At least Emacs should startup without any image support, even if he read
incompatible library.

Takashi Hiromatsu

Re: Emacs pretest 22.1.91

[Takashi Hiromatsu]

Thank you so much, I understood well.

Takashi Hiromatsu

At Mon, 25 Feb 2008 03:13:02 +0100,
Juanma Barranquero wrote:
> 
> On Mon, Feb 25, 2008 at 2:57 AM, Takashi Hiromatsu
> <matsuan@ca2.so-net.ne.jp> wrote:
> 
> > For me, You meant that libxpm.dll
> >  has advances in stability and compatibility area.
> 
> No. I mean that Jason builds it, so we know it is compatible with the
> binary distribution (they are presumably built with the same compiler,
> for example), and it works OK. But I've been using xpm4.dll until now
> and I've never seen any ill effect either.
> 
> > Ofcourse they also want to use more stable
> >  DLLs, but not want to download huge package.
> 
> The barebin package also includes it and it is 4.6 MB.
> 
>              Juanma
> 

Re: Emacs pretest 22.1.91

[Takashi Hiromatsu]

> it, as it can be assumed it is relatively stable and compatible. If
> the user really prefers to use another library, he can trivially
> modify `image-library-alist' in his .emacs.
I wrote this in my site-start.el or .emacs.el.
    (setcdr (assoc 'xpm image-library-alist)
            '("libXpm-nox4.dll" "xpm4.dll" "libxpm.dll"))

When start Emacs from cygwin shell, Emacs hanged up during startup. It
seems that emacs read xpm library, before evaluate site-start.el and
.emacs.el.

Takashi Hiromatsu

Re: Emacs pretest 22.1.91

[Juanma Barranquero]

On Mon, Feb 25, 2008 at 3:44 AM, Takashi Hiromatsu
<matsuan@ca2.so-net.ne.jp> wrote:

>  It is bad idea, because he can't start Emacs with -q option.
>
>  Also he can modify the alist in his site-start.el, but can't start with
>  --no-site-start option.
>
>  At least Emacs should startup without any image support, even if he read
>  incompatible library.

There's no magic answer. Users who install prepackaged binaries (on
Windows) will get a working setup, and users who build from sources
should be expected to understand about the issues involved (different
versions, PATH order, etc.)

             Juanma

Re: Emacs pretest 22.1.91

[Juanma Barranquero]

On Mon, Feb 25, 2008 at 7:16 AM, Takashi Hiromatsu
<matsuan@ca2.so-net.ne.jp> wrote:

>  I wrote this in my site-start.el or .emacs.el.
>     (setcdr (assoc 'xpm image-library-alist)
>             '("libXpm-nox4.dll" "xpm4.dll" "libxpm.dll"))
>
>  When start Emacs from cygwin shell, Emacs hanged up during startup. It
>  seems that emacs read xpm library, before evaluate site-start.el and
>  .emacs.el.

You're right, libxpm is being loaded before the init files. That's a
bug, I think.

             Juanma

Re: Emacs pretest 22.1.91

[Juanma Barranquero]

On Mon, Feb 25, 2008 at 7:16 AM, Takashi Hiromatsu
<matsuan@ca2.so-net.ne.jp> wrote:

>  When start Emacs from cygwin shell, Emacs hanged up during startup. It
>  seems that emacs read xpm library, before evaluate site-start.el and
>  .emacs.el.

You're compiling from the trunk, I suppose?

I've just checked the 22.2 prerelease, and it obeys
image-library-alist changes in .emacs (wrt libxpm, I mean). However,
the trunk does not; it is loading libxpm before the init files run.

Jason, do you think that is a change on the Windows port, or a general
change that just bites in Windows because of the delayed loading?

             Juanma

Re: Emacs pretest 22.1.91

[Jason Rumney]

Juanma Barranquero wrote:
> Jason, do you think that is a change on the Windows port, or a general
> change that just bites in Windows because of the delayed loading?
>   
I think the most likely source of the change in behaviour is the 
multi-tty change to require term/*-win.el to be preloaded and related 
changes to startup order.

Re: Emacs pretest 22.1.91

[Juanma Barranquero]

On Mon, Feb 25, 2008 at 12:28 PM, Jason Rumney <jasonr@gnu.org> wrote:

>  I think the most likely source of the change in behaviour is the
>  multi-tty change to require term/*-win.el to be preloaded and related
>  changes to startup order.

Even if term/*-win.el are preloaded, Emacs (on Windows) doesn't get
"married" with a specific imagelib DLL until it is first needed.
Modifying the PNG entry for `image-library-alist' in .emacs works, for
example.

So the issue is that "(image-type-available-p 'xpm)" is being called
now sooner that it was before.

             Juanma

Re: Emacs pretest 22.1.91

[Eli Zaretskii]

> Date: Mon, 25 Feb 2008 11:58:32 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: Emacs Devel <emacs-devel@gnu.org>, Jason Rumney <jasonr@gnu.org>
> 
> I've just checked the 22.2 prerelease, and it obeys
> image-library-alist changes in .emacs (wrt libxpm, I mean). However,
> the trunk does not; it is loading libxpm before the init files run.
> 
> Jason, do you think that is a change on the Windows port, or a general
> change that just bites in Windows because of the delayed loading?

I think instead of hypothesizing, it's easier to run Emacs under a
debugger, put a breakpoint where it loads image support libraries, and
look at the backtrace when that breakpoint fires.

Re: Emacs pretest 22.1.91

[Takashi Hiromatsu]

At Mon, 25 Feb 2008 11:58:32 +0100,
Juanma Barranquero wrote:
> 
> On Mon, Feb 25, 2008 at 7:16 AM, Takashi Hiromatsu
> <matsuan@ca2.so-net.ne.jp> wrote:
> 
> >  When start Emacs from cygwin shell, Emacs hanged up during startup. It
> >  seems that emacs read xpm library, before evaluate site-start.el and
> >  .emacs.el.
> 
> You're compiling from the trunk, I suppose?
> 
No, I compiled http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.1.91.tar.gz
with some patches.

Takashi Hiromatsu

Re: Emacs pretest 22.1.91

[Juanma Barranquero]

On Mon, Feb 25, 2008 at 9:07 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>  I think instead of hypothesizing, it's easier to run Emacs under a
>  debugger, put a breakpoint where it loads image support libraries, and
>  look at the backtrace when that breakpoint fires.

I am no gdb wizard; it you can shed any light, I'll be glad.

#0  Finit_image_library (type=26281417, libraries=40443477) at image.c:3888
#1  0x0101caf7 in Ffuncall (nargs=3, args=0x82f020) at eval.c:3028
#2  0x011561cd in Fbyte_code (bytestr=19735011, vector=19735052,
maxdepth=24) at bytecode.c:679
#3  0x0101c34a in funcall_lambda (fun=19734972, nargs=1,
arg_vector=0x82f154) at eval.c:3212
#4  0x0101c7c8 in Ffuncall (nargs=2, args=0x82f150) at eval.c:3071
#5  0x011561cd in Fbyte_code (bytestr=19737027, vector=19737116,
maxdepth=40) at bytecode.c:679
#6  0x0101c34a in funcall_lambda (fun=19736988, nargs=1,
arg_vector=0x82f294) at eval.c:3212
#7  0x0101c7c8 in Ffuncall (nargs=2, args=0x82f290) at eval.c:3071
#8  0x011561cd in Fbyte_code (bytestr=19757035, vector=19757316,
maxdepth=64) at bytecode.c:679
#9  0x0101c34a in funcall_lambda (fun=19756948, nargs=4,
arg_vector=0x82f478) at eval.c:3212
#10 0x0101c7c8 in Ffuncall (nargs=5, args=0x82f474) at eval.c:3071
#11 0x0101e610 in Fapply (nargs=6, args=0x82f474) at eval.c:2454
#12 0x0101cc06 in Ffuncall (nargs=7, args=0x82f470) at eval.c:3006
#13 0x011561cd in Fbyte_code (bytestr=19756755, vector=19756812,
maxdepth=56) at bytecode.c:679
#14 0x0101c34a in funcall_lambda (fun=19756676, nargs=2,
arg_vector=0x82f5b4) at eval.c:3212
#15 0x0101c7c8 in Ffuncall (nargs=3, args=0x82f5b0) at eval.c:3071
#16 0x011561cd in Fbyte_code (bytestr=19757843, vector=19758084,
maxdepth=48) at bytecode.c:679
#17 0x0101c34a in funcall_lambda (fun=19757804, nargs=1,
arg_vector=0x82f6f4) at eval.c:3212
#18 0x0101c7c8 in Ffuncall (nargs=2, args=0x82f6f0) at eval.c:3071
#19 0x011561cd in Fbyte_code (bytestr=19224859, vector=19224956,
maxdepth=32) at bytecode.c:679
#20 0x0101c34a in funcall_lambda (fun=19224812, nargs=1,
arg_vector=0x82f824) at eval.c:3212
#21 0x0101c7c8 in Ffuncall (nargs=2, args=0x82f820) at eval.c:3071
#22 0x011561cd in Fbyte_code (bytestr=19516171, vector=19516316,
maxdepth=48) at bytecode.c:679
#23 0x0101c34a in funcall_lambda (fun=19516124, nargs=1,
arg_vector=0x82f964) at eval.c:3212
#24 0x0101c7c8 in Ffuncall (nargs=2, args=0x82f960) at eval.c:3071
#25 0x011561cd in Fbyte_code (bytestr=19512267, vector=19512388,
maxdepth=48) at bytecode.c:679
#26 0x0101c34a in funcall_lambda (fun=19512236, nargs=0,
arg_vector=0x82faa4) at eval.c:3212
#27 0x0101c7c8 in Ffuncall (nargs=1, args=0x82faa0) at eval.c:3071
#28 0x011561cd in Fbyte_code (bytestr=19246635, vector=19247524,
maxdepth=56) at bytecode.c:679
#29 0x0101c34a in funcall_lambda (fun=19246612, nargs=0,
arg_vector=0x82fbe4) at eval.c:3212
#30 0x0101c7c8 in Ffuncall (nargs=1, args=0x82fbe0) at eval.c:3071
#31 0x011561cd in Fbyte_code (bytestr=19242427, vector=19242644,
maxdepth=48) at bytecode.c:679
#32 0x0101c34a in funcall_lambda (fun=19242404, nargs=0,
arg_vector=0x82fcb0) at eval.c:3212
#33 0x0101c5c4 in apply_lambda (fun=19242404, args=25995265,
eval_flag=1) at eval.c:3136
#34 0x0101b855 in Feval (form=26729669) at eval.c:2398
#35 0x01099a54 in top_level_2 () at keyboard.c:1379
#36 0x0101af97 in internal_condition_case (bfun=0x1099a41
<top_level_2>, handlers=26061945, hfun=0x109e713 <cmd_error>) at
eval.c:1494
#37 0x0109d8e9 in top_level_1 () at keyboard.c:1387
#38 0x0101b032 in internal_catch (tag=26054969, func=0x109d8b9
<top_level_1>, arg=25995265) at eval.c:1230
#39 0x0109e52e in command_loop () at keyboard.c:1342
#40 0x0109e876 in recursive_edit_1 () at keyboard.c:958
#41 0x0109e9e1 in Frecursive_edit () at keyboard.c:1020
#42 0x01002b01 in main (argc=8585136, argv=0xa844d0) at emacs.c:1786

             Juanma

Re: Emacs pretest 22.1.91

[Juanma Barranquero]

On Tue, Feb 26, 2008 at 12:45 AM, Takashi Hiromatsu
<matsuan@ca2.so-net.ne.jp> wrote:

>  No, I compiled http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.1.91.tar.gz
>  with some patches.

That's quite weird. I add this to my .emacs:

(let ((xpm (assq 'xpm image-library-alist)))
  (setcdr xpm (cons "my-xpm.dll" (cdr xpm))))

and run the current EMACS_22_BASE branch code and my-xpm.dll gets
loaded instead of libxpm.dll (which is also available in the same
directory). So it works for me, with the 22.2 code [the same test
fails with the trunk].

Which patches are those?

             Juanma

Re: Emacs pretest 22.1.91

[Takashi Hiromatsu]

At Tue, 26 Feb 2008 02:23:29 +0100,
Juanma Barranquero wrote:
> 
> On Tue, Feb 26, 2008 at 12:45 AM, Takashi Hiromatsu
> <matsuan@ca2.so-net.ne.jp> wrote:
> 
> >  No, I compiled http://alpha.gnu.org/gnu/emacs/pretest/emacs-22.1.91.tar.gz
> >  with some patches.
> 
> That's quite weird. I add this to my .emacs:
???????????????...............

I will try again without any patches later.

> 
> Which patches are those?

Japanese Inline IME patch
    http://jaist.dl.sourceforge.jp/ntemacsjp/29519/emacs-22base-20080221-IME.patch.gz

Transparecy patch
    http://globalbase.dl.sourceforge.jp/macemacsjp/29497/transparency-3.1.1.tar.gz

I think both pathes will not influense startup order.

Takashi Hiromatsu

Re: Emacs pretest 22.1.91

[Eli Zaretskii]

> Date: Tue, 26 Feb 2008 02:19:00 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: matsuan@ca2.so-net.ne.jp, emacs-devel@gnu.org, jasonr@gnu.org
> 
> On Mon, Feb 25, 2008 at 9:07 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >  I think instead of hypothesizing, it's easier to run Emacs under a
> >  debugger, put a breakpoint where it loads image support libraries, and
> >  look at the backtrace when that breakpoint fires.
> 
> I am no gdb wizard; it you can shed any light, I'll be glad.
> 
> #0  Finit_image_library (type=26281417, libraries=40443477) at image.c:3888
> #1  0x0101caf7 in Ffuncall (nargs=3, args=0x82f020) at eval.c:3028

What does xbacktrace say?

Re: Emacs pretest 22.1.91

[Juanma Barranquero]

On Tue, Feb 26, 2008 at 5:16 AM, Eli Zaretskii <eliz@gnu.org> wrote:

>  What does xbacktrace say?

Thanks. I knew I was missing something obvious (xbacktrace, I mean).

On the trunk:

"init-image-library" (0x82f024)
"image-type-available-p" (0x82f154)
"find-image" (0x82f294)
"tool-bar-local-item-from-menu" (0x82f478)
"apply" (0x82f474)
"tool-bar-add-item-from-menu" (0x82f5b4)
"tool-bar-setup" (0x82f6f4)
"x-create-frame-with-faces" (0x82f824)
"make-frame" (0x82f964)
"frame-initialize" (0x82faa4)
"command-line" (0x82fbe4)
"normal-top-level" (0x82fcb0)

On EMACS_22_BASE:

"init-image-library" (0x178ac79)
"image-type-available-p" (0x178ac79)
"use-fancy-splash-screens-p" (0x11eede3)
"display-startup-screen" (0x1753801)
"command-line-1" (0x1753801)
"command-line" (0x1a1ec03)
"normal-top-level" (0x1753801)

             Juanma

Re: Emacs pretest 22.1.91

[Eli Zaretskii]

> Date: Tue, 26 Feb 2008 10:36:51 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: matsuan@ca2.so-net.ne.jp, emacs-devel@gnu.org, jasonr@gnu.org
> 
> On the trunk:
> 
> "init-image-library" (0x82f024)
> "image-type-available-p" (0x82f154)
> "find-image" (0x82f294)
> "tool-bar-local-item-from-menu" (0x82f478)
> "apply" (0x82f474)
> "tool-bar-add-item-from-menu" (0x82f5b4)
> "tool-bar-setup" (0x82f6f4)
> "x-create-frame-with-faces" (0x82f824)
> "make-frame" (0x82f964)
> "frame-initialize" (0x82faa4)
> "command-line" (0x82fbe4)
> "normal-top-level" (0x82fcb0)
> 
> On EMACS_22_BASE:
> 
> "init-image-library" (0x178ac79)
> "image-type-available-p" (0x178ac79)
> "use-fancy-splash-screens-p" (0x11eede3)
> "display-startup-screen" (0x1753801)
> "command-line-1" (0x1753801)
> "command-line" (0x1a1ec03)
> "normal-top-level" (0x1753801)

Which explains the difference: on the 22.x branch, init-image-library
is called from command-line-1, which is _after_ site-init file and
.emacs; while on the trunk, it is called from frame-initialize, which
is _before_ these two.

Next question: why does frame-initialize call init-image-library in
Emacs 23, but not in 22?

Re: Emacs pretest 22.1.91

[Juanma Barranquero]

On Tue, Feb 26, 2008 at 8:50 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>  Next question: why does frame-initialize call init-image-library in
>  Emacs 23, but not in 22?

That is a question for someone who understands the multi-tty stuff, I think.

             Juanma

Re: Emacs pretest 22.1.91

[Juanma Barranquero]

On Wed, Feb 27, 2008 at 2:20 AM, Juanma Barranquero <lekktu@gmail.com> wrote:

>  That is a question for someone who understands the multi-tty stuff, I think.

Let me reformulate that:

`frame-initialize' causes the loading of libxpm now because in 23.X it
calls `tool-bar-setup'. The new code in frame-initialize has this
comment:

	  ;; Make sure the tool-bar is ready to be enabled.  The
	  ;; `tool-bar-lines' frame parameter will not take effect
	  ;; without this call.
	  (tool-bar-setup frame)

This code is part of Károly Lőrentey's multi-tty merge (lisp/ChangeLog
entry of 2007-08-29).  However, at least on Windows, removing the call
to `tool-bar-setup' fixes the original problem and does not seem to
cause any trouble, not even the one mentioned in the comment (I
commented out the call to tool-bar-setup and set the tool-bar-lines
frame parameter to nil in my .emacs and it did take effect).

It'd be useful to understand why was it considered necessary to do the
tool-bar-setup here. Perhaps it could be deferred via
emacs-startup-hook or somesuch.

             Juanma

Re: Emacs pretest 22.1.91

[Eli Zaretskii]

> Date: Wed, 27 Feb 2008 02:56:46 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: matsuan@ca2.so-net.ne.jp, emacs-devel@gnu.org, jasonr@gnu.org
> 
> 	  ;; Make sure the tool-bar is ready to be enabled.  The
> 	  ;; `tool-bar-lines' frame parameter will not take effect
> 	  ;; without this call.
> 	  (tool-bar-setup frame)
> 
> This code is part of Károly Lőrentey's multi-tty merge (lisp/ChangeLog
> entry of 2007-08-29).  However, at least on Windows, removing the call
> to `tool-bar-setup' fixes the original problem and does not seem to
> cause any trouble, not even the one mentioned in the comment (I
> commented out the call to tool-bar-setup and set the tool-bar-lines
> frame parameter to nil in my .emacs and it did take effect).

Windows does not support multi-tty, perhaps that's the reason.

> It'd be useful to understand why was it considered necessary to do the
> tool-bar-setup here. Perhaps it could be deferred via
> emacs-startup-hook or somesuch.

How about if you make that change and see if someone hollers?

Re: Emacs pretest 22.1.91

[Juanma Barranquero]

On Wed, Feb 27, 2008 at 5:14 AM, Eli Zaretskii <eliz@gnu.org> wrote:

>  How about if you make that change and see if someone hollers?

Sounds like a plan.

However, all the tool-bar-setup kerfuffle is a bit weird. Károly
Lőrentey added an optional frame argument, but then also added a guard
so tool-bar-setup's innards only run once; seems like the whole point
of having a frame as an argument is not wasting effort in doing
"(with-selected-frame frame (tool-bar-setup))" when in all cases
except the first one tool-bar-setup is not going do to anything at
all...

The cleanest fix I can think of at this moment is moving the
tool-bar-setup call, from `x-create-frame-with-faces' to
`frame-notice-user-settings', which runs at the right time and already
does tool-bar work. That also allows to remove the frame argument to
tool-bar-setup, which would not really be needed and just adds
cognitive overhead.

The alternative would be to maintain the call to tool-bar-setup in
`x-create-frame-with-faces', but adding it to `after-init-hook' only
if we haven't yet loaded the init files. That seems hackish in the
extreme. (And, how do you detect that you have loaded the init files?
I suppose "(when after-init-time ...)" is a way...)

The patch below (with diff -b to exclude the space changes in
tool-bar-setup) does all the right things on Windows: fixes the
original XPM-loading problem, respects settings of `tool-bar-lines'
frame parameter and/or calls to `tool-bar-mode' in .emacs, etc.

I'd like someone who's using Emacs on GNU/Linux (in window and -nw
modes) to give it a little try before commiting it, though.

             Juanma


2008-02-27  Juanma Barranquero  <lekktu@gmail.com>

	* faces.el (x-create-frame-with-faces): Don't call `tool-bar-setup'.
	* frame.el (frame-notice-user-settings): Call `tool-bar-setup'.
	* tool-bar.el (tool-bar-setup): Remove optional `frame' argument.

Index: lisp/faces.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/faces.el,v
retrieving revision 1.394
diff -u -2 -b -r1.394 faces.el
--- lisp/faces.el	22 Feb 2008 23:34:57 -0000	1.394
+++ lisp/faces.el	27 Feb 2008 11:16:57 -0000
@@ -1999,8 +1999,4 @@
 	  (frame-set-background-mode frame)
 	  (face-set-after-frame-default frame)
-	  ;; Make sure the tool-bar is ready to be enabled.  The
-	  ;; `tool-bar-lines' frame parameter will not take effect
-	  ;; without this call.
-	  (tool-bar-setup frame)
 	  (if (null visibility-spec)
 	      (make-frame-visible frame)
Index: lisp/frame.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/frame.el,v
retrieving revision 1.269
diff -u -2 -b -r1.269 frame.el
--- lisp/frame.el	14 Feb 2008 21:16:36 -0000	1.269
+++ lisp/frame.el	27 Feb 2008 11:17:25 -0000
@@ -285,5 +285,9 @@
 	  (setq default-frame-alist
 		(cons (cons 'tool-bar-lines (if tool-bar-mode 1 0))
-		      default-frame-alist))))))
+		      default-frame-alist))))
+      ;; Make sure the tool-bar is ready to be enabled.  The
+      ;; `tool-bar-lines' frame parameter will not take effect
+      ;; without this call.
+      (tool-bar-setup)))

   ;; Creating and deleting frames may shift the selected frame around,
Index: lisp/tool-bar.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/tool-bar.el,v
retrieving revision 1.11
diff -u -2 -b -r1.11 tool-bar.el
--- lisp/tool-bar.el	27 Feb 2008 10:17:06 -0000	1.11
+++ lisp/tool-bar.el	27 Feb 2008 11:19:31 -0000
@@ -232,7 +232,6 @@
   "Set to t if the tool-bar has been set up by `tool-bar-setup'.")

-(defun tool-bar-setup (&optional frame)
+(defun tool-bar-setup ()
   (unless tool-bar-setup
-    (with-selected-frame (or frame (selected-frame))
       ;; People say it's bad to have EXIT on the tool bar, since users
       ;; might inadvertently click that button.
@@ -287,5 +286,5 @@
 		       'help
 		       :help "Pop up the Help menu"))
-  (setq tool-bar-setup t))))
+    (setq tool-bar-setup t)))

Re: Emacs pretest 22.1.91

[Jason Rumney]

Juanma Barranquero wrote:
> The cleanest fix I can think of at this moment is moving the
> tool-bar-setup call, from `x-create-frame-with-faces' to
> `frame-notice-user-settings'

I think the case that the previous change was trying to fix is where 
emacs is started as emacs -nw and a GUI frame is created later. AFAICT, 
frame-notice-user-settings is only called at startup, so I think moving 
the tool-bar setup there will cause this case to fail again.

Re: Emacs pretest 22.1.91

[Juanma Barranquero]

On Wed, Feb 27, 2008 at 1:41 PM, Jason Rumney <jasonr@gnu.org> wrote:

>  I think the case that the previous change was trying to fix is where
>  emacs is started as emacs -nw and a GUI frame is created later.

Ah, I see. When the initial frame is a tty frame, frame-initialize
does nothing (because initial-window-system is nil), so tool-bar-setup
is not run, so it runs for the first non-tty frame created.

> AFAICT,
>  frame-notice-user-settings is only called at startup, so I think moving
>  the tool-bar setup there will cause this case to fail again.

OK, what about this simpler change then?

             Juanma


2008-02-27  Juanma Barranquero  <lekktu@gmail.com>

	* faces.el (x-create-frame-with-faces): Delay call to
	`tool-bar-setup' if invoked before loading the init files.


Index: lisp/faces.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/faces.el,v
retrieving revision 1.394
diff -u -2 -r1.394 faces.el
--- lisp/faces.el	22 Feb 2008 23:34:57 -0000	1.394
+++ lisp/faces.el	27 Feb 2008 13:01:43 -0000
@@ -2002,5 +2002,8 @@
 	  ;; `tool-bar-lines' frame parameter will not take effect
 	  ;; without this call.
-	  (tool-bar-setup frame)
+	  (if after-init-time
+	      (tool-bar-setup frame)
+	    ;; delay until the init files have been loaded
+	    (add-hook 'after-init-hook `(lambda () (tool-bar-setup ,frame))))
 	  (if (null visibility-spec)
 	      (make-frame-visible frame)

Re: Emacs pretest 22.1.91

[Juanma Barranquero]

On Wed, Feb 27, 2008 at 3:11 PM, Juanma Barranquero <lekktu@gmail.com> wrote:

>  OK, what about this simpler change then?

>  2008-02-27  Juanma Barranquero  <lekktu@gmail.com>
>
>         * faces.el (x-create-frame-with-faces): Delay call to
>         `tool-bar-setup' if invoked before loading the init files.

<sigh> What a nice can of worms.

After the patch above, with this simple .emacs:

;;;;;;;;;; emacs.el ;;;;;;;;;;
(with-temp-buffer (compilation-mode 1))
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

you get an error:

  signal(wrong-type-argument (keymapp nil))
  define-key-after(nil [previous-error-no-select] (menu-item
"previous-error-no-select" previous-error-no-select :image (image
:type xpm :file "c:/emacs/trunk/etc/images/left-arrow.xpm") :rtl
"right-arrow" :help "Goto previous error"))
  tool-bar-local-item("left-arrow" previous-error-no-select
previous-error-no-select nil :rtl "right-arrow" :help "Goto previous
error")
  byte-code(...)
  (compilation-mode 1)
 [... etc ]

That's because compile.el (on the trunk) has

(defvar compilation-mode-tool-bar-map
  (if (display-graphic-p)
      (let ((map (butlast (copy-keymap tool-bar-map)))
        ...

But before calling `tool-bar-setup', `tool-bar-map' contains just '(keymap)).

This is not a new bug; if you add the tool-bar stuff from the trunk's
compile.el to the EMACS22_BASE compile.el. it fails too. It just
hadn't been noticed before.

The only way out I can see right now is promoting `tool-bar-setup' to
be a user (or at least, package-developer) visible function. For
example, to change the above code to

(defvar compilation-mode-tool-bar-map
  (when (display-graphic-p)
      (tool-bar-setup)
      (let ((map (butlast (copy-keymap tool-bar-map)))
        ...

I'm feeling deeply unclean right now.

             Juanma

Re: Emacs pretest 22.1.91

[Stefan Monnier]

> +	    ;; delay until the init files have been loaded
> +	    (add-hook 'after-init-hook `(lambda () (tool-bar-setup ,frame))))

Yuck!

There's gotta be a better fix,


        Stefan

Re: Emacs pretest 22.1.91

[Juanma Barranquero]

On Wed, Feb 27, 2008 at 4:50 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

>  There's gotta be a better fix,

I don't doubt it, but I'm a bit short of ideas right now. I'm all ears.

However, let me extend the "yuck" comment to many (I don't dare to say
most) multi-tty code. The functionality is great, I suppose.

             Juanma

Re: Emacs pretest 22.1.91

[Eli Zaretskii]

> Date: Wed, 27 Feb 2008 12:41:04 +0000
> From: Jason Rumney <jasonr@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, matsuan@ca2.so-net.ne.jp, emacs-devel@gnu.org
> 
> Juanma Barranquero wrote:
> > The cleanest fix I can think of at this moment is moving the
> > tool-bar-setup call, from `x-create-frame-with-faces' to
> > `frame-notice-user-settings'
> 
> I think the case that the previous change was trying to fix is where 
> emacs is started as emacs -nw and a GUI frame is created later. AFAICT, 
> frame-notice-user-settings is only called at startup, so I think moving 
> the tool-bar setup there will cause this case to fail again.

Since Windows doesn't support multi-tty (and probably won't for an
observable future), how about if Juanma makes this change conditioned
so that it only has effect on Windows?

Re: Emacs pretest 22.1.91

[Juanma Barranquero]

On Wed, Feb 27, 2008 at 8:15 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>  Since Windows doesn't support multi-tty (and probably won't for an
>  observable future), how about if Juanma makes this change conditioned
>  so that it only has effect on Windows?

This is easy; see the attached patch (though I'm afraid the yuckiness
detector of Stefan is in danger of overloading).

However, this does not fix the other bug I reported: uses of
`tool-bar-map' in .emacs (or packages loaded from it) could still
cause trouble.

             Juanma


2008-02-28  Juanma Barranquero  <lekktu@gmail.com>

	* faces.el (x-create-frame-with-faces): Don't call
	`tool-bar-setup' if the frame's window-system is w32.

	* frame.el (frame-notice-user-settings): Call `tool-bar-setup'.


Index: lisp/faces.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/faces.el,v
retrieving revision 1.394
diff -u -2 -r1.394 faces.el
--- lisp/faces.el	22 Feb 2008 23:34:57 -0000	1.394
+++ lisp/faces.el	28 Feb 2008 00:34:52 -0000
@@ -1999,8 +1999,10 @@
 	  (frame-set-background-mode frame)
 	  (face-set-after-frame-default frame)
-	  ;; Make sure the tool-bar is ready to be enabled.  The
-	  ;; `tool-bar-lines' frame parameter will not take effect
-	  ;; without this call.
-	  (tool-bar-setup frame)
+	  (unless (eq (window-system frame) 'w32)
+	    ;; Make sure the tool-bar is ready to be enabled.  The
+	    ;; `tool-bar-lines' frame parameter will not take effect
+	    ;; without this call.  On Windows, delay the setup to allow
+	    ;; users to choose image libraries in their .emacs.
+	    (tool-bar-setup frame))
 	  (if (null visibility-spec)
 	      (make-frame-visible frame)
Index: lisp/frame.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/frame.el,v
retrieving revision 1.269
diff -u -2 -r1.269 frame.el
--- lisp/frame.el	14 Feb 2008 21:16:36 -0000	1.269
+++ lisp/frame.el	28 Feb 2008 00:36:42 -0000
@@ -285,5 +285,9 @@
 	  (setq default-frame-alist
 		(cons (cons 'tool-bar-lines (if tool-bar-mode 1 0))
-		      default-frame-alist))))))
+		      default-frame-alist))))
+      ;; If the tool-bar was not set up before the init files, do it now.
+      ;; FIXME: When, if ever, we support multi-tty on Windows, this will
+      ;; have to be revisited.
+      (tool-bar-setup)))

   ;; Creating and deleting frames may shift the selected frame around,

Re: Emacs pretest 22.1.91

[Stefan Monnier]

>> There's gotta be a better fix,
> I don't doubt it, but I'm a bit short of ideas right now. I'm all ears.
> However, let me extend the "yuck" comment to many (I don't dare to say
> most) multi-tty code. The functionality is great, I suppose.

Yes, the multi-tty code introduced several problems, but when we bump
into them we shouldn't try to circumvent them and hence introduce more
such problems.  Instead we should take a step back and try and see what
is a real solution.

In this case, I believe the solution is to setup the tool-bar-map at the
very beginning (maybe even before dumping), and then have a function
(run after the .emacs) that can fix up the tool-bar-map by replacing the
default image choice with the preferred images for the current setup (so
it can obey image-library-alist, display-color-p, etc..).


        Stefan

Re: Emacs pretest 22.1.91

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 27 Feb 2008 20:03:29 -0500
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, matsuan@ca2.so-net.ne.jp,
> 	Jason Rumney <jasonr@gnu.org>
> 
> In this case, I believe the solution is to setup the tool-bar-map at the
> very beginning (maybe even before dumping), and then have a function
> (run after the .emacs) that can fix up the tool-bar-map by replacing the
> default image choice with the preferred images for the current setup (so
> it can obey image-library-alist, display-color-p, etc..).

Can you (or someone else) explain why is it necessary to set up
tool-bar-map so early?  Why not set it up where you suggest to ``fix''
it?

Re: Emacs pretest 22.1.91

[Stefan Monnier]

>> In this case, I believe the solution is to setup the tool-bar-map at the
>> very beginning (maybe even before dumping), and then have a function
>> (run after the .emacs) that can fix up the tool-bar-map by replacing the
>> default image choice with the preferred images for the current setup (so
>> it can obey image-library-alist, display-color-p, etc..).

> Can you (or someone else) explain why is it necessary to set up
> tool-bar-map so early?  Why not set it up where you suggest to ``fix''
> it?

So code can refer to it (e.g. compile.el builds a tool-bar-map of its
own based on the pre-existing one and this is done when loading
compile.elc).

Actually, looking at how compile.el uses tool-bar-map, I see that if
compile.el gets loaded before tool-bar-map is "adjusted" (images chosen
depending on the display and libs), then compile's own tool-bar will
lack this adjustment.

So maybe the choice of which image to use should be done in the :filter
function (currently trivial) defined in tool-bar.el as:

(global-set-key [tool-bar]
		'(menu-item "tool bar" ignore
			    :filter (lambda (ignore) tool-bar-map)))

I.e. basically extend the format allowed in tool-bar-map to include
various images and let the image be chosen later on by
the :filter function.  Of course, maybe this filter gets run early on
as well...


        Stefan

Re: Emacs pretest 22.1.91

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: lekktu@gmail.com,  matsuan@ca2.so-net.ne.jp,  jasonr@gnu.org,  emacs-devel@gnu.org
> Date: Wed, 27 Feb 2008 23:59:22 -0500
> 
> So maybe the choice of which image to use should be done in the :filter
> function (currently trivial) defined in tool-bar.el as:
> 
> (global-set-key [tool-bar]
> 		'(menu-item "tool bar" ignore
> 			    :filter (lambda (ignore) tool-bar-map)))
> 
> I.e. basically extend the format allowed in tool-bar-map to include
> various images and let the image be chosen later on by
> the :filter function.  Of course, maybe this filter gets run early on
> as well...

It strikes me that we need to arrange things so that the images are
not looked up nor loaded until the tool bar is actually displayed for
the first time.

Re: Emacs pretest 22.1.91

[Stefan Monnier]

>> So maybe the choice of which image to use should be done in the :filter
>> function (currently trivial) defined in tool-bar.el as:
>> 
>> (global-set-key [tool-bar]
>> '(menu-item "tool bar" ignore
>> :filter (lambda (ignore) tool-bar-map)))
>> 
>> I.e. basically extend the format allowed in tool-bar-map to include
>> various images and let the image be chosen later on by
>> the :filter function.  Of course, maybe this filter gets run early on
>> as well...

> It strikes me that we need to arrange things so that the images are
> not looked up nor loaded until the tool bar is actually displayed for
> the first time.

Indeed.  And using the above :filter might give us exactly that
(if it doesn't, then maybe we can fix the code so that it does).


        Stefan