Re: GTK build crashes under X
> Date: Fri, 08 Dec 2006 08:27:21 +0100 > From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org > > > > Alas, I couldn't find any documentation of the *.pc files' format, so > > that I could edit the files. > > It is in the man page for pkg-config. What man page? I'm quite sure I tried "man pkg-config" and didn't find it there. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
> Date: Fri, 08 Dec 2006 08:23:26 +0100 > From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= <[EMAIL PROTECTED]> > Cc: emacs-pretest-bug@gnu.org > > I've added some text about PKG_CONFIG_PATH also. Thanks. > >> In summary, pkg-config is a very helpful tool, but you have to get use to > >> it. > > > > It is indeed useful, but only as long as your installation doesn't > > need to do something extraordinary. > > This seems to be in line with where Gnome seems to be going, less user > customizations. Not that I agree with that philosophy. I don't like it either. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
Hi, I was specifically asked to provide the / vs \ output of Dir. However, you may note that / works as long as it isn't the last element of Dir. Cheers, Will -Original Message- From: Eli Zaretskii [mailto:[EMAIL PROTECTED] Sent: Thursday, December 07, 2006 11:39 PM To: Deutsch, Will Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; emacs-pretest-bug@gnu.org Subject: Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM > Date: Thu, 7 Dec 2006 16:59:05 -0800 > From: "Deutsch, Will" <[EMAIL PROTECTED]> > Cc: emacs-pretest-bug@gnu.org > > It appears that the / between the bin and the command is the problem. This may > be an OS bug. > > Here is the dir output: > C:\Users\wdeutsch>dir "C:\Program Files (x86)\Emacs\emacs/bin/runemacs.exe" > Volume in drive C is OS Drive > Volume Serial Number is 8020-54D6 > > Directory of C:\Program Files (x86)\Emacs\emacs\bin > > File Not Found Am I missing something here? How are the problems with DIR relevant to emacsclient? It is well known that DIR doesn't grok forward slashes because it tries to interpret what follows a forward slash as an option (try "DIR /?" and you will see what options it supports). However, emacsclient is not DIR; emacsclient simply passes the file names to the OS API, and the OS API does support forward slashes as well as backslashes. So please show us where the forward slashes fail inside emacsclient, not with DIR. smime.p7s Description: S/MIME cryptographic signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
> Date: Fri, 08 Dec 2006 02:18:20 +0100 > From: Lennart Borgman <[EMAIL PROTECTED]> > Cc: "Deutsch, Will" <[EMAIL PROTECTED]>, emacs-pretest-bug@gnu.org > > On the other hand we might be receiving bug reports just because there > are more users if we supply a prebuildt binary on MS Windows. It might > be more important. I have no problems with having a precompiled Windows binary distro as part of the pretest, as long as it is a straight compilation of the pretest sources without any extra quirks. If you are willing to do this job, please talk to Chong Yidong and coordinate your uploads to alpha.gnu.org. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
> Date: Thu, 7 Dec 2006 16:59:05 -0800 > From: "Deutsch, Will" <[EMAIL PROTECTED]> > Cc: emacs-pretest-bug@gnu.org > > It appears that the / between the bin and the command is the problem. This > may > be an OS bug. > > Here is the dir output: > C:\Users\wdeutsch>dir "C:\Program Files (x86)\Emacs\emacs/bin/runemacs.exe" > Volume in drive C is OS Drive > Volume Serial Number is 8020-54D6 > > Directory of C:\Program Files (x86)\Emacs\emacs\bin > > File Not Found Am I missing something here? How are the problems with DIR relevant to emacsclient? It is well known that DIR doesn't grok forward slashes because it tries to interpret what follows a forward slash as an option (try "DIR /?" and you will see what options it supports). However, emacsclient is not DIR; emacsclient simply passes the file names to the OS API, and the OS API does support forward slashes as well as backslashes. So please show us where the forward slashes fail inside emacsclient, not with DIR. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
Eli Zaretskii skrev: Date: Thu, 07 Dec 2006 08:55:06 +0100 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= <[EMAIL PROTECTED]> Cc: Henrik Enberg <[EMAIL PROTECTED]>, emacs-pretest-bug@gnu.org "PKG_CONFIG_PATH=/path/to/dir/with/foo.pc ./configure" Thanks, but this only works if the package installed privately installs foo.pc. Not every package does, since not every package supports pkg-config in its source distribution. That is true. A workaround woould be to copy the .pc-file that mentions foo to a private directory, edit it to point to your private foo, and then set PKG_CONFIG_PATH. Alas, I couldn't find any documentation of the *.pc files' format, so that I could edit the files. It is in the man page for pkg-config. pkg-config needs some kind of --use or --override switch so we could do this easier. Indeed. As things are now, it looks like the maintainers of pkg-config didn't _want_ you to have the freedom to point it to the non-default installation directories. Its origin is form the Gnome project after all... Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
Eli Zaretskii skrev: Do we document the LDFLAGS-trick somewhere? Yes, in INSTALL. I've added some text about PKG_CONFIG_PATH also. In summary, pkg-config is a very helpful tool, but you have to get use to it. It is indeed useful, but only as long as your installation doesn't need to do something extraordinary. This seems to be in line with where Gnome seems to be going, less user customizations. Not that I agree with that philosophy. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
Stephen Berman skrev: On Thu, 07 Dec 2006 11:11:18 +0100 Stephen Berman wrote: This was the state of things last night. This morning I wanted to pursue it but, to my surprise, I now cannot get GTK-Emacs to segfault. I first started it with no ~/.fonts.cache-2 and no /var/cache/fontconfig (and without setting LD_LIBRARY_PATH to /usr/local/lib) and, as last night, it started slow and a ~1.6 MB large ~/.fonts.cache-2 was rebuilt. But then I could start further instances without deleting ~/.fonts.cache-2, unlike last night. Moreover, when I moved fontconfig back into /var/cache/, I still could start GTK-Emacs (and a big ~/.fonts.cache-2 was again rebuilt). That's the current situation. So, I'm pleased that I have GTK-Emacs back again, but I would still like to know why I lost it in the first place, so if anyone has an suggestions, I'd be grateful. Well, now I can get GTK-Emacs to segfault again :-). I noticed that the desktop fonts didn't look as sharp as they normally do (it took me a while to notice this, probably because the fonts in Emacs are always not so sharp :-), so I ran fc-cache, exited KDE and logged on again. Now my desktop fonts are back to their previous sharpness, but Emacs-GTK segfaults again with the standard invocation (but I can start it by setting LD_LIBRARY_PATH to /usr/local/lib). So if someone is able to advise me how to debug this, I can try to do it. It is hard if Emacs doesn't fail with the debug-compiled fontconfig. Does wxGTK install fonts? The cache handling seems to have some bug in it. As it only fails sometimes it might be that the code that builds or reads the cache have some uninitialized variable that gets random garbage. Sometimes that garbage is OK, sometimes it isn't. If you rebuild the cache several times with the same fontconfig, are the ~/.fonts.cache-2 then identical? And are they different if you rebuild with the fontconfig you compiled? Does any other Gnome/GTK application fail when Emacs fails or is it just Emacs? Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Replacement of spaces in wdired
One problem I found is that it allows me to edit the last space in the " -> " string that indicates a symbolic link. If I have a symbolic link "a -> b" in the directory I'm editing, I can delete the 2nd space, leaving "a ->b", and when I hit C-c C-c, I end up with "a -> /dev/null". Doing a query replace of " " with "." when there are symlinks present also replaces the " " which follows each "->". Martin, I suggest you install your patch, since it is an improvement. Then can you fix this other problem? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: no way to stop helpful modeline color tinkering
Dude... just set mode-line-in-non-selected-windows to nil. While that might eliminate the problem, this could still be a bug. When mode-line-in-non-selected-windows is t, the nonselected window mode lines display in face `mode-line-inactive'. Is that face being set up in a suboptimal way in a certain situation? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Patch] build cvs emacs for x86_64-sun-solaris10
Oops. I sent a wrong patch. Here's the revised one.
Index: configure
===
RCS file: /cvsroot/emacs/emacs/configure,v
retrieving revision 1.180
diff -u -r1.180 configure
--- configure 4 Dec 2006 08:17:50 - 1.180
+++ configure 8 Dec 2006 04:39:34 -
@@ -2433,6 +2433,7 @@
m68* ) machine=sun3 ;;
i[3456]86-sun-sunos[34]* ) machine=sun386 ;;
i[3456]86-*-* ) machine=intel386 ;;
+ amd64-*-*|x86_64-*-*)machine=amdx86-64 ;;
powerpcle* ) machine=powerpcle ;;
powerpc* | rs6000* ) machine=ibmrs6000 ;;
sparc* ) machine=sparc ;;
Index: configure.in
===
RCS file: /cvsroot/emacs/emacs/configure.in,v
retrieving revision 1.421
diff -u -r1.421 configure.in
--- configure.in4 Dec 2006 08:17:59 - 1.421
+++ configure.in8 Dec 2006 04:39:34 -
@@ -951,6 +951,7 @@
m68* ) machine=sun3 ;;
i[3456]86-sun-sunos[34]* ) machine=sun386 ;;
i[3456]86-*-* ) machine=intel386 ;;
+ amd64-*-*|x86_64-*-*)machine=amdx86-64 ;;
powerpcle* ) machine=powerpcle ;;
powerpc* | rs6000* ) machine=ibmrs6000 ;;
sparc* ) machine=sparc ;;
Index: src/fns.c
===
RCS file: /cvsroot/emacs/emacs/src/fns.c,v
retrieving revision 1.422
diff -u -r1.422 fns.c
--- src/fns.c 24 Nov 2006 19:53:56 - 1.422
+++ src/fns.c 8 Dec 2006 04:39:34 -
@@ -89,6 +89,8 @@
#ifndef HAVE_UNISTD_H
extern long time ();
#endif
+
+static Lisp_Object concat (int, Lisp_Object *, enum Lisp_Type, int);
DEFUN ("identity", Fidentity, Sidentity, 1, 1, 0,
doc: /* Return the argument unchanged. */)
Index: src/m/amdx86-64.h
===
RCS file: /cvsroot/emacs/emacs/src/m/amdx86-64.h,v
retrieving revision 1.12
diff -u -r1.12 amdx86-64.h
--- src/m/amdx86-64.h 26 Nov 2006 22:16:49 - 1.12
+++ src/m/amdx86-64.h 8 Dec 2006 04:39:34 -
@@ -125,7 +125,11 @@
#undef LIB_STANDARD
#define LIB_STANDARD -lgcc -lc -lgcc /usr/lib/crtend.o
-#else /* !__OpenBSD__ && !__FreeBSD__ */
+#elif defined(sun)
+#undef START_FILES
+#undef LIB_STANDARD
+
+#else /* !__OpenBSD__ && !__FreeBSD__ && !sun */
#undef START_FILES
#ifdef HAVE_X86_64_LIB64_DIR
> In <[EMAIL PROTECTED]>
> NAKAJI Hiroyuki <[EMAIL PROTECTED]> wrote:
> I successfully built cvs emacs on my Opteron box for the target
> x86_64-sun-solaris10.
> o I added the target {amd64,x86_64}-sun-solaris* in configure.in.
> o src/fns.c also need change to avoid prototype error by Sun Studio.
> o src/m/amdx86-64.h is also modified to fit sun.
--
NAKAJI Hiroyuki
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[Patch] build cvs emacs for x86_64-sun-solaris10
I successfully built cvs emacs on my Opteron box for the target
x86_64-sun-solaris10.
o I added the target {amd64,x86_64}-sun-solaris* in configure.in.
o src/fns.c also need change to avoid prototype error by Sun Studio.
o src/m/amdx86-64.h is also modified to fit sun.
o I tested compile with both gcc-3.4.3 and Sun Studio 11 with this shell
script.
--->8-->8-->8-->8-->8---
#!/usr/bin/env bash
cd ~/emacs || exit 1
case "$1" in
gcc)
export CC="gcc -m64"
cfgopt="--with-gcc"
;;
cc)
export CC="cc -xarch=amd64"
cfgopt="--without-gcc"
;;
*)
exit 0
;;
esac
export LANG=C
test -f Makefile && gmake distclean
cvs -q update -dP
./configure ${cfgopt} --with-gtk amd64-sun-solaris10 || exit 2
gmake bootstrap && sudo gmake install
--->8-->8-->8-->8-->8---
o I tested run and exit only.
Thanks.
--
NAKAJI Hiroyuki
Index: configure.in
===
RCS file: /cvsroot/emacs/emacs/configure.in,v
retrieving revision 1.419
diff -u -r1.419 configure.in
--- configure.in26 Nov 2006 22:16:17 - 1.419
+++ configure.in8 Dec 2006 04:14:20 -
@@ -951,6 +951,7 @@
m68* ) machine=sun3 ;;
i[3456]86-sun-sunos[34]* ) machine=sun386 ;;
i[3456]86-*-* ) machine=intel386 ;;
+ amd64-*-*|x86_64-*-*)machine=amdx86-64 ;;
powerpcle* ) machine=powerpcle ;;
powerpc* | rs6000* ) machine=ibmrs6000 ;;
sparc* ) machine=sparc ;;
@@ -998,7 +999,14 @@
;;
*-sunos5* | *-solaris* )
opsys=sol2-6
- NON_GNU_CPP=/usr/ccs/lib/cpp
+ case "${canonical}" in
+ amd64-*-*|x86_64-*-*)
+ NON_GNU_CPP="/usr/ccs/lib/cpp -D__x86_64"
+ ;;
+ *)
+ NON_GNU_CPP=/usr/ccs/lib/cpp
+ ;;
+ esac
;;
* ) opsys=bsd4-2 ;;
esac
Index: src/fns.c
===
RCS file: /cvsroot/emacs/emacs/src/fns.c,v
retrieving revision 1.422
diff -u -r1.422 fns.c
--- src/fns.c 24 Nov 2006 19:53:56 - 1.422
+++ src/fns.c 8 Dec 2006 04:14:20 -
@@ -89,6 +89,8 @@
#ifndef HAVE_UNISTD_H
extern long time ();
#endif
+
+static Lisp_Object concat (int, Lisp_Object *, enum Lisp_Type, int);
DEFUN ("identity", Fidentity, Sidentity, 1, 1, 0,
doc: /* Return the argument unchanged. */)
Index: src/m/amdx86-64.h
===
RCS file: /cvsroot/emacs/emacs/src/m/amdx86-64.h,v
retrieving revision 1.12
diff -u -r1.12 amdx86-64.h
--- src/m/amdx86-64.h 26 Nov 2006 22:16:49 - 1.12
+++ src/m/amdx86-64.h 8 Dec 2006 04:14:20 -
@@ -125,7 +125,11 @@
#undef LIB_STANDARD
#define LIB_STANDARD -lgcc -lc -lgcc /usr/lib/crtend.o
-#else /* !__OpenBSD__ && !__FreeBSD__ */
+#elif defined(sun)
+#undef START_FILES
+#undef LIB_STANDARD
+
+#else /* !__OpenBSD__ && !__FreeBSD__ && !sun */
#undef START_FILES
#ifdef HAVE_X86_64_LIB64_DIR
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
I'm not sure why... I'll run prebuilt binaries and test and if needed even provide basic output of debugger commands. I run App and System and HW level debuggers in the course of my job. So I'm already exposed to the machine code of EVERYTHING that is running on the system at any time. It is imposable not to be. Therefore providing feedback from a debugger in the case of exceptions or crash is no stretch. Mostly the point of my email is that due to the nature of my job I can't/wont build my own binaries from source. However, I will file detailed bugs and assist where possible in root causing the problem. Cheers, Will -Original Message- From: Nick Roberts [mailto:[EMAIL PROTECTED] Sent: Thursday, December 07, 2006 6:22 PM To: Deutsch, Will Cc: Lennart Borgman; Juanma Barranquero; emacs-pretest-bug@gnu.org Subject: RE: emacsclient and emacsclientw don't work in Windows Vista x64 RTM > I'm a software developer who works on code that I cannot contaminate. I > cannot risk even the appearance of contamination... > ...I'm happy to run binaries to test things and provide detailed > reports. I'll provide feedback and even run the debugger, minus the source, > however, I just cannot risk working directly with the source even for a > simple build situation. These two statements seem contradictory. -- Nick http://www.inet.net.nz/~nickrob smime.p7s Description: S/MIME cryptographic signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
On 12/8/06, Deutsch, Will <[EMAIL PROTECTED]> wrote: I'm just an Emacs user not an Emacs developer... And we thank you for helping test Emacs. I really don't want to get into a free/non-free software debate. I'm already pro-free software... What Lennart and I are debating is not a free/non-free software issue, but wasted efforts. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
On 12/8/06, Lennart Borgman <[EMAIL PROTECTED]> wrote: And I will try to make sure that it is just the CVS code (+ EmacsW32 + the installer of course). I'm grateful that you plan on providing prebuilt binaries for testing on Windows. However, as soon as you add that parenthesis, it turns less useful, because it diverges from what we want to test. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
> I'm a software developer who works on code that I cannot contaminate. I > cannot risk even the appearance of contamination... > ...I'm happy to run binaries to test things and provide detailed > reports. I'll provide feedback and even run the debugger, minus the source, > however, I just cannot risk working directly with the source even for a > simple build situation. These two statements seem contradictory. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
Hi, I'm just an Emacs user not an Emacs developer... However, here is my feedback on this issue. I'm a software developer who works on code that I cannot contaminate. I cannot risk even the appearance of contamination. Therefore, I don't download and compile anything right now. I don't even use source debs or srpms on my linux boxes. Past jobs were more GPL friendly, so I gladly download and compiled everything. When my job changes I will gladly go back to building from CVS. I'm happy to run binaries to test things and provide detailed reports. I'll provide feedback and even run the debugger, minus the source, however, I just cannot risk working directly with the source even for a simple build situation. Were the world perfect someone would pay me to work on GPL code. However, currently I'm being paid to work on something else. I really don't want to get into a free/non-free software debate. I'm already pro-free software... Cheers, Will -Original Message- From: Lennart Borgman [mailto:[EMAIL PROTECTED] Sent: Thursday, December 07, 2006 6:00 PM To: Juanma Barranquero Cc: Deutsch, Will; emacs-pretest-bug@gnu.org Subject: Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM Juanma Barranquero wrote: > On 12/8/06, Lennart Borgman <[EMAIL PROTECTED]> wrote: > >> On the other hand we might be receiving bug reports just because there >> are more users if we supply a prebuildt binary on MS Windows. It might >> be more important. > > Pretesters should be able to build their own Emacs, IMHO. There are > official (or mostly official) binary builds of Emacs for Windows, once > it is released. I know that it is important that many users build Emacs too, but the problem on MS Windows is that most users will not do that. That means that there will be fewer testers when we do not supply prebuilt binaries. For this reason I have planned to supply more prebuilt binaries during the pretest. (They will not be from the tarball, but directly from the CVS.) And I will try to make sure that it is just the CVS code (+ EmacsW32 + the installer of course). smime.p7s Description: S/MIME cryptographic signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
Yeah, no problem. Cheers, Will -Original Message- From: Lennart Borgman [mailto:[EMAIL PROTECTED] Sent: Thursday, December 07, 2006 6:03 PM To: Deutsch, Will Cc: Juanma Barranquero; emacs-pretest-bug@gnu.org Subject: Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM I will change the slashes to forward slashes only as soon as I have time. Could you test when I have done that Will? smime.p7s Description: S/MIME cryptographic signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
I will change the slashes to forward slashes only as soon as I have time. Could you test when I have done that Will? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
Juanma Barranquero wrote: On 12/8/06, Lennart Borgman <[EMAIL PROTECTED]> wrote: On the other hand we might be receiving bug reports just because there are more users if we supply a prebuildt binary on MS Windows. It might be more important. Pretesters should be able to build their own Emacs, IMHO. There are official (or mostly official) binary builds of Emacs for Windows, once it is released. I know that it is important that many users build Emacs too, but the problem on MS Windows is that most users will not do that. That means that there will be fewer testers when we do not supply prebuilt binaries. For this reason I have planned to supply more prebuilt binaries during the pretest. (They will not be from the tarball, but directly from the CVS.) And I will try to make sure that it is just the CVS code (+ EmacsW32 + the installer of course). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
Hi, I just did the dir test on Server 2003SP1... It seems DIR on 2003SP1 and Vista behave the same yet the exec doesn't. 2003SP1: Microsoft Windows [Version 5.2.3790] (C) Copyright 1985-2003 Microsoft Corp. D:\Documents and Settings\wdeutsch>dir "D:\Program Files\Emacs\emacs/bin/runemac s.exe" Volume in drive D is System Disk Volume Serial Number is 10CF-7D40 Directory of D:\Program Files\Emacs\emacs\bin File Not Found D:\Documents and Settings\wdeutsch>dir "D:\Program Files\Emacs\emacs/bin\runemac s.exe" Volume in drive D is System Disk Volume Serial Number is 10CF-7D40 Directory of D:\Program Files\Emacs\emacs\bin 12/05/2006 02:22 AM29,115 runemacs.exe 1 File(s) 29,115 bytes 0 Dir(s) 9,976,893,440 bytes free D:\Documents and Settings\wdeutsch>dir "D:\Program Files\Emacs\emacs\bin\runemac s.exe" Volume in drive D is System Disk Volume Serial Number is 10CF-7D40 Directory of D:\Program Files\Emacs\emacs\bin 12/05/2006 02:22 AM29,115 runemacs.exe 1 File(s) 29,115 bytes 0 Dir(s) 9,976,893,440 bytes free D:\Documents and Settings\wdeutsch>dir "D:/Program Files/Emacs/emacs/bin/runemac s.exe" Volume in drive D is System Disk Volume Serial Number is 10CF-7D40 Directory of D:\Program Files\Emacs\emacs\bin File Not Found D:\Documents and Settings\wdeutsch>dir "D:/Program Files/Emacs/emacs/bin\runemac s.exe" Volume in drive D is System Disk Volume Serial Number is 10CF-7D40 Directory of D:\Program Files\Emacs\emacs\bin 12/05/2006 02:22 AM29,115 runemacs.exe 1 File(s) 29,115 bytes 0 Dir(s) 9,976,893,440 bytes free D:\Documents and Settings\wdeutsch> But emacsclient still works fine. Cheers, Will -Original Message- From: Lennart Borgman [mailto:[EMAIL PROTECTED] Sent: Thursday, December 07, 2006 5:26 PM To: Deutsch, Will Cc: Juanma Barranquero; emacs-pretest-bug@gnu.org Subject: Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM Deutsch, Will wrote: > Hi, > > It appears that the / between the bin and the command is the problem. This > may > be an OS bug. > > Here is the dir output: > C:\Users\wdeutsch>dir "C:\Program Files (x86)\Emacs\emacs/bin/runemacs.exe" > Volume in drive C is OS Drive > Volume Serial Number is 8020-54D6 > > Directory of C:\Program Files (x86)\Emacs\emacs\bin > > File Not Found > > C:\Users\wdeutsch>dir "C:\Program Files (x86)\Emacs\emacs\bin\runemacs.exe" > Volume in drive C is OS Drive > Volume Serial Number is 8020-54D6 > > Directory of C:\Program Files (x86)\Emacs\emacs\bin > > 11/21/2006 02:00 AM46,523 runemacs.exe >1 File(s) 46,523 bytes >0 Dir(s) 109,831,647,232 bytes free > > C:\Users\wdeutsch>dir "C:\Program Files (x86)\Emacs\emacs\bin/runemacs.exe" > Volume in drive C is OS Drive > Volume Serial Number is 8020-54D6 > > Directory of C:\Program Files (x86)\Emacs\emacs\bin > > File Not Found ... > > It would appear MS changed the behavior of the / in the path. Could you please try with only forward slashes too? > Here are the list of images I have tried (I have installed most of these on > XP > and Server 2003SP1 x64 and x86): > Emacs-22-CvsP061121-EmacsW32-1.10.exe > Emacs-22-CvsP060830-EmacsW32-1.06.exe Those are both patched versions. The patched version as a P in the name and the unpatched has a U instead. > Sorry, the system that I did most of my Emacs installs on has been wiped and > repurposed so I no longer have a complete record. I've spot tested many > versions in between these two. > > This is what is running: > This is GNU Emacs 22.0.91.1 (i386-mingw-nt6.0.6000) > of 2006-11-20 on W2ONE I have changed this message in the latest patched version so it says that it is patched. I have also changed the icon in the patched version to make it more clear which version is used. I will update my web site soon to tell this. (Maybe I will change to a better one than the one I am using now, but I do not have time to do that at the moment.) smime.p7s Description: S/MIME cryptographic signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
Deutsch, Will wrote: Hi, I only had the install files left around from the patched files. However, I have tried in unpatched, I just don't have the install source as the drive from that system image was wiped. I definitely understand the difference between the patched and unpatched versions. However, for this issue I saw no difference. Thanks, I see. Here is more dir output: C:\Users\wdeutsch>dir "C:/Program Files (x86)/Emacs/emacs/bin/runemacs.exe" Volume in drive C is OS Drive Volume Serial Number is 8020-54D6 Directory of C:\Program Files (x86)\Emacs\emacs\bin File Not Found C:\Users\wdeutsch>dir "C:/Program Files (x86)/Emacs/emacs/bin\runemacs.exe" Volume in drive C is OS Drive Volume Serial Number is 8020-54D6 Directory of C:\Program Files (x86)\Emacs\emacs\bin 12/05/2006 02:22 AM29,115 runemacs.exe 1 File(s) 29,115 bytes 0 Dir(s) 109,375,385,600 bytes free Those two really makes me believe it is an OS bug. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bad copyright years
In article <[EMAIL PROTECTED]>, Richard Stallman <[EMAIL PROTECTED]> writes: > ps-bdf.el should have all the from 2001 to 2006. > Do I update the years for AIST as well as FSF? > I think only those for FSF, but please ask Handa-san. Long ago, I updated AIST's copyright line to list only such years that I modified the code. But, AIST keeps copyright for all continuous years. If we must list all years explicitely in such a case, could you please update the lines for AIST too? --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
Hi, I only had the install files left around from the patched files. However, I have tried in unpatched, I just don't have the install source as the drive from that system image was wiped. I definitely understand the difference between the patched and unpatched versions. However, for this issue I saw no difference. Here is more dir output: Microsoft Windows [Version 6.0.6000] Copyright (c) 2006 Microsoft Corporation. All rights reserved. C:\Users\wdeutsch>dir "C:\Program Files (x86)\Emacs\emacs/bin\runemacs.exe" Volume in drive C is OS Drive Volume Serial Number is 8020-54D6 Directory of C:\Program Files (x86)\Emacs\emacs\bin 12/05/2006 02:22 AM29,115 runemacs.exe 1 File(s) 29,115 bytes 0 Dir(s) 109,375,385,600 bytes free C:\Users\wdeutsch>dir "C:/Program Files (x86)/Emacs/emacs/bin/runemacs.exe" Volume in drive C is OS Drive Volume Serial Number is 8020-54D6 Directory of C:\Program Files (x86)\Emacs\emacs\bin File Not Found C:\Users\wdeutsch>dir "C:/Program Files (x86)/Emacs/emacs/bin\runemacs.exe" Volume in drive C is OS Drive Volume Serial Number is 8020-54D6 Directory of C:\Program Files (x86)\Emacs\emacs\bin 12/05/2006 02:22 AM29,115 runemacs.exe 1 File(s) 29,115 bytes 0 Dir(s) 109,375,385,600 bytes free C:\Users\wdeutsch> Cheers, Will Deutsch -Original Message- From: Lennart Borgman [mailto:[EMAIL PROTECTED] Sent: Thursday, December 07, 2006 5:26 PM To: Deutsch, Will Cc: Juanma Barranquero; emacs-pretest-bug@gnu.org Subject: Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM Deutsch, Will wrote: > Hi, > > It appears that the / between the bin and the command is the problem. This > may > be an OS bug. > > Here is the dir output: > C:\Users\wdeutsch>dir "C:\Program Files (x86)\Emacs\emacs/bin/runemacs.exe" > Volume in drive C is OS Drive > Volume Serial Number is 8020-54D6 > > Directory of C:\Program Files (x86)\Emacs\emacs\bin > > File Not Found > > C:\Users\wdeutsch>dir "C:\Program Files (x86)\Emacs\emacs\bin\runemacs.exe" > Volume in drive C is OS Drive > Volume Serial Number is 8020-54D6 > > Directory of C:\Program Files (x86)\Emacs\emacs\bin > > 11/21/2006 02:00 AM46,523 runemacs.exe >1 File(s) 46,523 bytes >0 Dir(s) 109,831,647,232 bytes free > > C:\Users\wdeutsch>dir "C:\Program Files (x86)\Emacs\emacs\bin/runemacs.exe" > Volume in drive C is OS Drive > Volume Serial Number is 8020-54D6 > > Directory of C:\Program Files (x86)\Emacs\emacs\bin > > File Not Found ... > > It would appear MS changed the behavior of the / in the path. Could you please try with only forward slashes too? > Here are the list of images I have tried (I have installed most of these on > XP > and Server 2003SP1 x64 and x86): > Emacs-22-CvsP061121-EmacsW32-1.10.exe > Emacs-22-CvsP060830-EmacsW32-1.06.exe Those are both patched versions. The patched version as a P in the name and the unpatched has a U instead. > Sorry, the system that I did most of my Emacs installs on has been wiped and > repurposed so I no longer have a complete record. I've spot tested many > versions in between these two. > > This is what is running: > This is GNU Emacs 22.0.91.1 (i386-mingw-nt6.0.6000) > of 2006-11-20 on W2ONE I have changed this message in the latest patched version so it says that it is patched. I have also changed the icon in the patched version to make it more clear which version is used. I will update my web site soon to tell this. (Maybe I will change to a better one than the one I am using now, but I do not have time to do that at the moment.) smime.p7s Description: S/MIME cryptographic signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
On 12/8/06, Lennart Borgman <[EMAIL PROTECTED]> wrote: On the other hand we might be receiving bug reports just because there are more users if we supply a prebuildt binary on MS Windows. It might be more important. Pretesters should be able to build their own Emacs, IMHO. There are official (or mostly official) binary builds of Emacs for Windows, once it is released. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
Deutsch, Will wrote: Hi, It appears that the / between the bin and the command is the problem. This may be an OS bug. Here is the dir output: C:\Users\wdeutsch>dir "C:\Program Files (x86)\Emacs\emacs/bin/runemacs.exe" Volume in drive C is OS Drive Volume Serial Number is 8020-54D6 Directory of C:\Program Files (x86)\Emacs\emacs\bin File Not Found C:\Users\wdeutsch>dir "C:\Program Files (x86)\Emacs\emacs\bin\runemacs.exe" Volume in drive C is OS Drive Volume Serial Number is 8020-54D6 Directory of C:\Program Files (x86)\Emacs\emacs\bin 11/21/2006 02:00 AM46,523 runemacs.exe 1 File(s) 46,523 bytes 0 Dir(s) 109,831,647,232 bytes free C:\Users\wdeutsch>dir "C:\Program Files (x86)\Emacs\emacs\bin/runemacs.exe" Volume in drive C is OS Drive Volume Serial Number is 8020-54D6 Directory of C:\Program Files (x86)\Emacs\emacs\bin File Not Found ... It would appear MS changed the behavior of the / in the path. Could you please try with only forward slashes too? Here are the list of images I have tried (I have installed most of these on XP and Server 2003SP1 x64 and x86): Emacs-22-CvsP061121-EmacsW32-1.10.exe Emacs-22-CvsP060830-EmacsW32-1.06.exe Those are both patched versions. The patched version as a P in the name and the unpatched has a U instead. Sorry, the system that I did most of my Emacs installs on has been wiped and repurposed so I no longer have a complete record. I've spot tested many versions in between these two. This is what is running: This is GNU Emacs 22.0.91.1 (i386-mingw-nt6.0.6000) of 2006-11-20 on W2ONE I have changed this message in the latest patched version so it says that it is patched. I have also changed the icon in the patched version to make it more clear which version is used. I will update my web site soon to tell this. (Maybe I will change to a better one than the one I am using now, but I do not have time to do that at the moment.) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
Juanma Barranquero wrote: On 12/8/06, Lennart Borgman <[EMAIL PROTECTED]> wrote: Ok, I should be responsible for EmacsW32 I guess. Yes, I think so. And this report is exactly the kind of thing some people in the list were talking about: we're receiving a bug report for a problem that it is perhaps non-existent in the official builds. On the other hand we might be receiving bug reports just because there are more users if we supply a prebuildt binary on MS Windows. It might be more important. The unpatched version should really be the just the standard distribution (from CVS) compiled + optionally the EmacsW32 files but those should not be involved here at all. As long as it is not the standard tarball or straight from the CVS, I would count it as unofficial. Differences can creep in. It would be very nice if there were un official prebuilt binary package for MS Windows. Of course mistakes could happen there too, but I think they will be sorted out rather quickly. In the case of the EmacsW32 distros I actually think the same though they do not have any official status of course. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
On 12/8/06, Lennart Borgman <[EMAIL PROTECTED]> wrote: Ok, I should be responsible for EmacsW32 I guess. Yes, I think so. And this report is exactly the kind of thing some people in the list were talking about: we're receiving a bug report for a problem that it is perhaps non-existent in the official builds. The unpatched version should really be the just the standard distribution (from CVS) compiled + optionally the EmacsW32 files but those should not be involved here at all. As long as it is not the standard tarball or straight from the CVS, I would count it as unofficial. Differences can creep in. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
Hi, It appears that the / between the bin and the command is the problem. This may be an OS bug. Here is the dir output: C:\Users\wdeutsch>dir "C:\Program Files (x86)\Emacs\emacs/bin/runemacs.exe" Volume in drive C is OS Drive Volume Serial Number is 8020-54D6 Directory of C:\Program Files (x86)\Emacs\emacs\bin File Not Found C:\Users\wdeutsch>dir "C:\Program Files (x86)\Emacs\emacs\bin\runemacs.exe" Volume in drive C is OS Drive Volume Serial Number is 8020-54D6 Directory of C:\Program Files (x86)\Emacs\emacs\bin 11/21/2006 02:00 AM46,523 runemacs.exe 1 File(s) 46,523 bytes 0 Dir(s) 109,831,647,232 bytes free C:\Users\wdeutsch>dir "C:\Program Files (x86)\Emacs\emacs\bin/runemacs.exe" Volume in drive C is OS Drive Volume Serial Number is 8020-54D6 Directory of C:\Program Files (x86)\Emacs\emacs\bin File Not Found C:\Users\wdeutsch>dir "C:\Program Files (x86)\Emacs\emacs/bin\runemacs.exe" Volume in drive C is OS Drive Volume Serial Number is 8020-54D6 Directory of C:\Program Files (x86)\Emacs\emacs\bin 11/21/2006 02:00 AM46,523 runemacs.exe 1 File(s) 46,523 bytes 0 Dir(s) 109,831,528,448 bytes free C:\Users\wdeutsch>dir "C:\Program Files (x86)\Emacs/emacs/bin\runemacs.exe" Volume in drive C is OS Drive Volume Serial Number is 8020-54D6 Directory of C:\Program Files (x86)\Emacs\emacs\bin 11/21/2006 02:00 AM46,523 runemacs.exe 1 File(s) 46,523 bytes 0 Dir(s) 109,831,528,448 bytes free C:\Users\wdeutsch>dir "C:\Program Files (x86)/Emacs/emacs/bin\runemacs.exe" Volume in drive C is OS Drive Volume Serial Number is 8020-54D6 Directory of C:\Program Files (x86)\Emacs\emacs\bin 11/21/2006 02:00 AM46,523 runemacs.exe 1 File(s) 46,523 bytes 0 Dir(s) 109,830,873,088 bytes free C:\Users\wdeutsch> It would appear MS changed the behavior of the / in the path. Here are the list of images I have tried (I have installed most of these on XP and Server 2003SP1 x64 and x86): Emacs-22-CvsP061121-EmacsW32-1.10.exe Emacs-22-CvsP060830-EmacsW32-1.06.exe Sorry, the system that I did most of my Emacs installs on has been wiped and repurposed so I no longer have a complete record. I've spot tested many versions in between these two. This is what is running: This is GNU Emacs 22.0.91.1 (i386-mingw-nt6.0.6000) of 2006-11-20 on W2ONE I've run both the patched an unpatched releases. Cheers, Will -Original Message- From: Lennart Borgman [mailto:[EMAIL PROTECTED] Sent: Thursday, December 07, 2006 4:36 PM To: Juanma Barranquero Cc: Deutsch, Will; emacs-pretest-bug@gnu.org Subject: Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM Juanma Barranquero wrote: > On 12/7/06, Deutsch, Will <[EMAIL PROTECTED]> wrote: > >> Is this an issue with the EmacsW32 distribution? Do I need to take it up >> with them or build my own? > > emacsclient.exe running runemacs.exe is an issue with the EmacsW32 > distribution; it's better to talk to them. Ok, I should be responsible for EmacsW32 I guess. Will, exactly what packages from EmacsW32 have you tried? I want the name of the setup files. I might have made some mistake. I often check my patches with the unpatched version first. I should not upload those tests of course, but I might have done that by mistake. (Eh, I have to put in some test in my routines so this does not happen.) >> I suspect MS changed or removed the code that allows the file path >> code to >> resolve / and \ that same. > > It would be useful if you could try with the standard distribution > (from CVS) to determine whether there's any issue with / vs. \. The unpatched version should really be the just the standard distribution (from CVS) compiled + optionally the EmacsW32 files but those should not be involved here at all. On 12/6/06, Deutsch, Will <[EMAIL PROTECTED]> wrote: > > Command output of emacsclient bellow: > > C:\Program Files (x86)\Emacs\emacs\bin>emacsclient > > emacsclient: Can't find C:\Program Files > > (x86)\Emacs\emacs/bin/runemacs.exe If you copy that output and just do C:\> dir "C:\Program Files (x86)\Emacs\emacs/bin/runemacs.exe" what do you get? smime.p7s Description: S/MIME cryptographic signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
Juanma Barranquero wrote: On 12/7/06, Deutsch, Will <[EMAIL PROTECTED]> wrote: Is this an issue with the EmacsW32 distribution? Do I need to take it up with them or build my own? emacsclient.exe running runemacs.exe is an issue with the EmacsW32 distribution; it's better to talk to them. Ok, I should be responsible for EmacsW32 I guess. Will, exactly what packages from EmacsW32 have you tried? I want the name of the setup files. I might have made some mistake. I often check my patches with the unpatched version first. I should not upload those tests of course, but I might have done that by mistake. (Eh, I have to put in some test in my routines so this does not happen.) I suspect MS changed or removed the code that allows the file path code to resolve / and \ that same. It would be useful if you could try with the standard distribution (from CVS) to determine whether there's any issue with / vs. \. The unpatched version should really be the just the standard distribution (from CVS) compiled + optionally the EmacsW32 files but those should not be involved here at all. On 12/6/06, Deutsch, Will <[EMAIL PROTECTED]> wrote: > > Command output of emacsclient bellow: > > C:\Program Files (x86)\Emacs\emacs\bin>emacsclient > > emacsclient: Can't find C:\Program Files > > (x86)\Emacs\emacs/bin/runemacs.exe If you copy that output and just do C:\> dir "C:\Program Files (x86)\Emacs\emacs/bin/runemacs.exe" what do you get? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
> Cc: Eli Zaretskii <[EMAIL PROTECTED]>, emacs-pretest-bug@gnu.org > From: Miles Bader <[EMAIL PROTECTED]> > Date: Thu, 07 Dec 2006 17:00:40 +0900 > > Simply _ignoring_ package-config doesn't seem practical. Then we should lobby its maintainers to provide the missing features. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
> Date: Thu, 07 Dec 2006 08:55:06 +0100 > From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= <[EMAIL PROTECTED]> > Cc: Henrik Enberg <[EMAIL PROTECTED]>, > emacs-pretest-bug@gnu.org > >> > >> "PKG_CONFIG_PATH=/path/to/dir/with/foo.pc ./configure" > > > > Thanks, but this only works if the package installed privately > > installs foo.pc. Not every package does, since not every package > > supports pkg-config in its source distribution. > > That is true. A workaround woould be to copy the .pc-file that mentions foo > to a private directory, edit it to point to your private foo, and then set > PKG_CONFIG_PATH. Alas, I couldn't find any documentation of the *.pc files' format, so that I could edit the files. > pkg-config needs some kind of --use or --override switch so > we could do this easier. Indeed. As things are now, it looks like the maintainers of pkg-config didn't _want_ you to have the freedom to point it to the non-default installation directories. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
> Date: Thu, 07 Dec 2006 08:42:40 +0100 > From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= <[EMAIL PROTECTED]> > Cc: emacs-pretest-bug@gnu.org > > It can be a pain sometimes, but for the most part it works quite well. As long as you can play by its rules. If you can't, God help you. > Do we document the LDFLAGS-trick somewhere? Yes, in INSTALL. > We should add something about PKG_CONFIG_PATH there. Yes. > The initial motivation (I think) was that the thing pkg-config does was too > complicated for configure. As with many human endeavors, the idea was good, but the result is ugly. > In summary, pkg-config is a very helpful tool, but you have to get use to it. It is indeed useful, but only as long as your installation doesn't need to do something extraordinary. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bad copyright years
> ps-bdf.el should have all the from 2001 to 2006. Do I update the years for AIST as well as FSF? I think only those for FSF, but please ask Handa-san. > t-mouse.el was added in 2006 so it is correct. It can't be correct. See my thread in emacs-devel. I meant that the years were correct. I tend to focus too narrowly these days, so I didn't even notice the issue about Rubini until someone pointed it out. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
On 12/7/06, Deutsch, Will <[EMAIL PROTECTED]> wrote: Is this an issue with the EmacsW32 distribution? Do I need to take it up with them or build my own? emacsclient.exe running runemacs.exe is an issue with the EmacsW32 distribution; it's better to talk to them. I suspect MS changed or removed the code that allows the file path code to resolve / and \ that same. It would be useful if you could try with the standard distribution (from CVS) to determine whether there's any issue with / vs. \. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
Hi, No, I'm not using alternate editor nor and I using -a... I actually tried setting ALTERNATE_EDITOR Is this an issue with the EmacsW32 distribution? Do I need to take it up with them or build my own? I know this distribution works fine on Server 2003, Server 2003 x64, XP Pro, and XP Pro x64. Vista x64 is the only place that has this problem. I suspect MS changed or removed the code that allows the file path code to resolve / and \ that same. Cheers, Will -Original Message- From: Juanma Barranquero [mailto:[EMAIL PROTECTED] Sent: Thursday, December 07, 2006 10:41 AM To: Deutsch, Will Cc: emacs-pretest-bug@gnu.org Subject: Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM On 12/7/06, Deutsch, Will <[EMAIL PROTECTED]> wrote: > I'm using a 3rd party distribution from: > http://ourcomments.org/Emacs/EmacsW32.html (EmacsW32 site) I suspected as much. > I've tried both their patched and unpatched Emacs distribution. Are you using the ALTERNATE_EDITOR environment variable? Because the emacsclient.exe from the unpatched distribution shouldn't try to execute runemacs.exe *at all*, unless you're doing C:\yourpath\emacsclient -a runemacs.exe my-file.txt /L/e/k/t/u smime.p7s Description: S/MIME cryptographic signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bad copyright years
Nick Roberts wrote: > And I thought we said that CC mode was added to Emacs in 1992, yet e.g > > ;;; cc-langs.el --- language specific settings for CC Mode > > ;; Copyright (C) 1985, 1987, 1992, 1993, 1994, 1995, 1996, 1997, 1998, > ;; 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software > ;; Foundation, Inc. > > i.e the years before 1992 are still in the header Yes, this is fine. Presumably cc-mode was released as a separate package several times before it was added to Emacs. So in 1992 the header may have looked like: 1985, 1987, 1992 John Smith Then when the copyright got assigned to the FSF in 1992, this changes to become: 1985, 1987, 1992 FSF The older years do not get removed, you just change the copyright holder. > Q. to RMS: What *should* the header for t-mouse.el look like? > > Currently: > > ;; Copyright (C) 1994,1995 Alessandro Rubini <[EMAIL PROTECTED]> > ;; parts are by Ian T Zimmermann <[EMAIL PROTECTED]>, 1995,1998 > ;; Copyright (C) 2006 > ;; Free Software Foundation, Inc. If I may answer, then normally you remove the old names and replace them with FSF, but keep the old dates. So it would look like: 1994, 1995, 1998, 2006 FSF I suppose there are corner cases when things may be different. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
On 12/7/06, Deutsch, Will <[EMAIL PROTECTED]> wrote: I'm using a 3rd party distribution from: http://ourcomments.org/Emacs/EmacsW32.html (EmacsW32 site) I suspected as much. I've tried both their patched and unpatched Emacs distribution. Are you using the ALTERNATE_EDITOR environment variable? Because the emacsclient.exe from the unpatched distribution shouldn't try to execute runemacs.exe *at all*, unless you're doing C:\yourpath\emacsclient -a runemacs.exe my-file.txt /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: no way to stop helpful modeline color tinkering
On 12/7/06, Chong Yidong <[EMAIL PROTECTED]> wrote: Dude... just set mode-line-in-non-selected-windows to nil. Or customize the mode-line-inactive face... /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
Hi, I'm using a 3rd party distribution from: http://ourcomments.org/Emacs/EmacsW32.html (EmacsW32 site) I've tried both their patched and unpatched Emacs distribution. Cheers, Will -Original Message- From: Juanma Barranquero [mailto:[EMAIL PROTECTED] Sent: Thursday, December 07, 2006 10:31 AM To: Deutsch, Will Cc: emacs-pretest-bug@gnu.org Subject: Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM On 12/6/06, Deutsch, Will <[EMAIL PROTECTED]> wrote: > Command output of emacsclient bellow: > C:\Program Files (x86)\Emacs\emacs\bin>emacsclient > emacsclient: Can't find C:\Program Files > (x86)\Emacs\emacs/bin/runemacs.exe Are you compiling Emacs from a prerelease tarball, from the CVS or perhaps a third-party distribution? /L/e/k/t/u smime.p7s Description: S/MIME cryptographic signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient and emacsclientw don't work in Windows Vista x64 RTM
On 12/6/06, Deutsch, Will <[EMAIL PROTECTED]> wrote: Command output of emacsclient bellow: C:\Program Files (x86)\Emacs\emacs\bin>emacsclient emacsclient: Can't find C:\Program Files (x86)\Emacs\emacs/bin/runemacs.exe Are you compiling Emacs from a prerelease tarball, from the CVS or perhaps a third-party distribution? /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Replacement of spaces in wdired
Chong Yidong <[EMAIL PROTECTED]> writes: > martin rudalics <[EMAIL PROTECTED]> writes: > >> It is large because it also tries to handle permission bits correctly. > > Have you tried Martin's patch? Does it work for you? Please reply to > the list, thanks. I hadn't tried it, but I just did. It seems to behave very well, allowing me to use query-replace and only replacing what it should, and the permission bit editing works nicely too. One problem I found is that it allows me to edit the last space in the " -> " string that indicates a symbolic link. If I have a symbolic link "a -> b" in the directory I'm editing, I can delete the 2nd space, leaving "a ->b", and when I hit C-c C-c, I end up with "a -> /dev/null". Doing a query replace of " " with "." when there are symlinks present also replaces the " " which follows each "->". This isn't something the patch attempted to address, but it's something that should be addressed I think. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Bug#402043: Info: fresher stuff hidden
Package: emacs-snapshot-common Version: 1:20060923-1 Severity: normal File: /usr/share/info/emacs-snapshot Here on my Debian sid machine, 2 matches for "emacs:" in buffer: *info* 122:* Emacs: (emacs-21/emacs). The extensible self-documenting text 179:* Emacs: (emacs-snapshot/emacs). The extensible self-documenting text Typing m emacs, and even hitting tab, one will never know about the second entry. Dear Debian Dudes: just how is one, used to m emacs RET, to even be aware of those second entries, without bending over backwards poking around the whole buffer to make sure there are no additional matches hidden? Indeed I always want to see the second entry, not the first. D> So TAB should cough up all the facts. > "E" == Eli Zaretskii <[EMAIL PROTECTED]> writes: E> No, it shouldn't: it's not uncommon for a system to have several DIR E> files along INFOPATH with identical entries pointing to the same E> manuals. It would be a nuisance to see all those identical entries E> line up in my face. All I want to be aware of is those second entries on the same page. E> Let's not lose perspective here: TAB-completion is not supposed to E> show you an exhaustive list of possibilities. You can get to the E> other "Emacs" entry if you manually move point there. Or (better) E> simply edit your DIR file to make the two entries distinct, as having E> them identical is a bad idea anyway. I'd also suggest to report this E> as a bug to whoever maintains your system distribution. OK, reporting to them. Hope they will make better DIR files, as I won't be editing them. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: no way to stop helpful modeline color tinkering
Dan Jacobson <[EMAIL PROTECTED]> writes: > Big let down versus emacs21. > $ emacs -Q /usr/share/common-licenses/GPL #or any file with lots of text > C-x 2 C-x o > The mode line running across the middle of the screen is the same > color as my emacs background color set in ~/.Xresources, > Emacs*Background: DarkSlateGray > > Instead of two windows, it looks very much like one big window! > > And it seems there is no variable to restore the former emacs21 style > behavior. Thanks for trying to show me what buffer is current via > changing the modeline, but it turns out that was too helpful. Dude... just set mode-line-in-non-selected-windows to nil. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-mode: Newsgroups header ignored
K> Why don't *you* just use the mode that meets *your* needs? mail-mode and message-mode look the same to the innocent user. One silently throws away Newsgroups headers and the other doesn't. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
no way to stop helpful modeline color tinkering
Big let down versus emacs21. $ emacs -Q /usr/share/common-licenses/GPL #or any file with lots of text C-x 2 C-x o The mode line running across the middle of the screen is the same color as my emacs background color set in ~/.Xresources, Emacs*Background: DarkSlateGray Instead of two windows, it looks very much like one big window! And it seems there is no variable to restore the former emacs21 style behavior. Thanks for trying to show me what buffer is current via changing the modeline, but it turns out that was too helpful. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mail-mode: still guessing big5 in utf-8 environment?
Terrible, $ env - LC_ALL=zh_TW.utf8 TERM=$TERM emacs -Q C-h v default-sendmail-coding-system default-sendmail-coding-system is a variable defined in `mail/sendmail.el'. Its value is chinese-big5 So something just sees the TW and ignores the utf8 upon changing it from iso-latin-1. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
emacsclient and emacsclientw don't work in Windows Vista x64 RTM
Command output of emacsclient bellow: C:\Program Files (x86)\Emacs\emacs\bin>emacsclient emacsclient: Can't find C:\Program Files (x86)\Emacs\emacs/bin/runemacs.exe C:\Program Files (x86)\Emacs\emacs\bin> Emacsclientw has the same output only in a dialog box. I have run usethis.exe several times in an attempt to trick runemacs to use \ instead of the / it is using. This behavior is consistent across several versions of Gnu Emacs I have tested. (This doesn't seem to be a regression.) In GNU Emacs 22.0.91.1 (i386-mingw-nt6.0.6000) of 2006-11-20 on W2ONE X server distributor `Microsoft Corp.', version 6.0.6000 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: M-x r e p o r t b u g - Recent messages: (C:\Program Files (x86)\Emacs\emacs\bin\emacs.exe) Loading encoded-kb...done Adding c:/Program Files (x86)/Emacs/EmacsW32/lisp/ to load-path Loading cl-macs...done Loading cl-seq...done Loading easy-mmode...done For information about the GNU Project and its goals, type C-h C-p. [2 times] Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
emacs-unicode-2: misjudged eol type when startup on windows-xp
When startup on Windows-XP, the default-buffer-file-coding-system is set to chinese-gbk-unix, it should be chinese-gbk-dos by default on windows. Startup with "emacs -Q" and "C-h C" in the *scratch* buffer gives: --8<---cut here---start->8--- Coding system for saving this buffer: Not set locally, use the default. Default coding system (for new files): c -- chinese-gbk-unix (alias: gbk-unix cp936-unix windows-936-unix) Coding system for keyboard input: c -- cp936 (alias of chinese-gbk) Coding system for terminal output: c -- cp936 (alias of chinese-gbk) Coding system for inter-client cut and paste: U -- utf-16le-dos Defaults for subprocess I/O: decoding: - -- undecided-dos (alias: dos) encoding: - -- undecided-unix (alias: unix) Priority order for recognizing coding systems when reading files: 1. chinese-gbk (alias: gbk cp936 windows-936) 2. iso-2022-cn (alias: chinese-iso-7bit) 3. chinese-iso-8bit (alias: cn-gb-2312 euc-china euc-cn cn-gb gb2312 cp936) 4. utf-8 (alias: mule-utf-8) 5. iso-2022-7bit 6. iso-2022-8bit-ss2 7. emacs-mule 8. raw-text 9. iso-2022-jp (alias: junet) 10. in-is13194-devanagari (alias: devanagari) 11. utf-16 12. utf-16be-with-signature (alias: utf-16-be) 13. utf-16le-with-signature (alias: utf-16-le) 14. utf-16be 15. utf-16le 16. japanese-shift-jis (alias: shift_jis sjis cp932) 17. undecided Other coding systems cannot be distinguished automatically from these, and therefore cannot be recognized automatically with the present coding system priorities. Particular coding systems specified for certain file names: OPERATION TARGET PATTERN CODING SYSTEM(s) - -- File I/O "\\.dz\\'" (no-conversion . no-conversion) "\\.g?z\\(~\\|\\.~[0-9]+~\\)?\\'" (no-conversion . no-conversion) "\\.tgz\\'" (no-conversion . no-conversion) "\\.tbz\\'" (no-conversion . no-conversion) "\\.bz2\\'" (no-conversion . no-conversion) "\\.Z\\(~\\|\\.~[0-9]+~\\)?\\'" (no-conversion . no-conversion) "\\.elc\\'" utf-8-emacs "\\.utf\\(-8\\)?\\'"utf-8 "\\.xml\\'" utf-8 "\\(\\`\\|/\\)loaddefs.el\\'" (raw-text . raw-text-unix) "\\.tar\\'" (no-conversion . no-conversion) "\\.po[tx]?\\'\\|\\.po\\." po-find-file-coding-system "\\.\\(tex\\|ltx\\|dtx\\|drv\\)\\'" latexenc-find-file-coding-system "" find-buffer-file-type-coding-system Process I/O nothing specified Network I/O nothing specified --8<---cut here---end--->8--- If Emacs crashed, and you have the Emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file c:/Emacs/etc/DEBUG for instructions. In GNU Emacs 23.0.0.1 (i386-mingw-nt5.1.2600) of 2006-12-05 on BREP X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.2)' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: CHS value of $XMODIFIERS: nil locale-coding-system: cp936 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: auto-image-file-mode: t display-time-mode: t show-paren-mode: t delete-selection-mode: t pc-selection-mode: t encoded-kbd-mode: t tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t global-auto-composition-mode: t auto-composition-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: M-x r e p r o t o r t - e m Recent messages: Source file `c:/Emacs/lisp/emacs-lisp/easymenu.el' newer than byte-compiled file Loading regexp-opt (compiled; note, source file is newer)...done Loading cl-macs (compiled; note, source file is newer)...done Loading d:/emacs-download/color-theme-6.6.0/themes/color-theme-example.el (source)...done Loading d:/emacs-download/color-theme-6.6.0/themes/color-theme-library.el (source)...done Loading image-file...done Loading c:/Emacs/zw-config/zw-dot-emacs.el (source)...done For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug...done byte-code: Beginn
Re: Failure to submit second netnews message
...and to be more precise I send a message to a newsgroup using gnus (as defined in lisp/gnus/message.el) The first message is sent successfully. I then send another message, totally different text to the same group (after all I moderate it and that is what I have to do) and it rejects the second message saying (error "Denied posting -- multiple copies") which is on line 3597 on lisp/gnus/message.el I am assuming that some value is not getting cleaned up when a message is sent. I will experiment with sending two unmoderated messages to see what happens, but I am late for a meeting now ==John ffitch ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Failure to submit second netnews message
I think this error I reported is from gnus/message.el line 3598 which calls the undefined function caddr I have replaced it here with (setq success (funcall (cadr (cdr elem)) arg))) amd it runs OK. Either that on the cl code is needed ==John ffitch > "Richard" == Richard Stallman <[EMAIL PROTECTED]> writes: Richard> I am a moderator of a NetNews list, which I control with emacs. With Richard> emacs-22 (beta) I can only accept one message; the second one says Richard> "Denied posting -- multiple copies" but it is not a multiple copy. Richard> If I restart emacs I can send one more message. Richard> This is not a precise report, but even if it were precise Richard> we would probably find it hard to try to reproduce this. Richard> Can you debug what happens inside the command that fails? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: gnus crashes on threads deeper than 333 articles
> Instead of adding a new defcustom, we use the safe recursive sorter > by default, and try again with the non-recursive sorter if an error > is signalled. The patch also regenerates gnus-thread-indent-array > if it becomes too small to handle a thread. Any objections to this approach? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Case-insensitive completion is broken
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
In a shell, create a new directory and cd there.
> touch Foo Foobar
> emacs -Q
In the *scratch* buffer, type:
(setq read-file-name-completion-ignore-case t) C-j
M-x partial-completion-mode
C-x C-f f
I expected it to complete "f" to "Foo", because all possible
completions begin with "Foo". That's what it does if you don't enable
partial-completion-mode. But with partial-completion-mode enabled, it
completes to "foo". If you press Tab again, Emacs displays the list
of possible completions ("Foo" and "Foobar"), but the minibuffer text
remains "foo".
If you type "b ", it will change "foob" to "Foobar" (as expected).
I checked some of the older executables I had lying around. This
worked properly in GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+
Version 2.6.10) of 2005-11-27.
The bug is present in the copy of 22.0.50.1 I compiled on 2006-09-03.
It's still present in the current version.
All these were built from the current CVS HEAD sources on the
compilation date.
In GNU Emacs 22.0.91.1 (i686-pc-linux-gnu, GTK+ Version 2.8.19)
of 2006-12-07 on bit
X server distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure '--prefix=/usr' '--host=i686-pc-linux-gnu'
'--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share'
'--sysconfdir=/etc' '--localstatedir=/var/lib'
'--program-suffix=.emacs-22.0.91' '--without-carbon' '--with-x' '--with-xpm'
'--with-toolkit-scroll-bars' '--with-jpeg' '--with-tiff' '--with-gif'
'--with-png' '--with-x-toolkit=gtk' '--build=i686-pc-linux-gnu' 'CFLAGS=-O2'
'build_alias=i686-pc-linux-gnu' 'host_alias=i686-pc-linux-gnu''
Important settings:
value of $LC_ALL: en_US
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: nil
locale-coding-system: iso-8859-1
default-enable-multibyte-characters: t
Major mode: Lisp Interaction
Minor modes in effect:
partial-completion-mode: t
tooltip-mode: t
tool-bar-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
line-number-mode: t
Recent input:
( s e t q SPC r e a d - f i - c
SPC t ) C-j M-x p a r t C-x C-f
f C-g M-x r - e - b
Recent messages:
(emacs -Q)
For information about the GNU Project and its goals, type C-h C-p.
Loading complete...
Loading advice...done
Loading complete...done
Partial-Completion mode enabled
Quit
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: no :type in Elisp index
Richard Stallman <[EMAIL PROTECTED]> writes: > > > Perhaps `i' should discard colon at the start, so that this > > > case will work. What do you think? > > > > Could work. But I'd suggest to postpone this till after the > release. > > > > I think it should be almost trivial -- please give it a try and see. > > It doesn't seem trivial to make it work with completion... > > Maybe not, but if it at least succeeds in finding `:type' > by searching for `type', that will be much better than it is now. > Could you do that much? Done. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
On Thu, 07 Dec 2006 11:11:18 +0100 Stephen Berman wrote: > This was the state of things last night. This morning I wanted to > pursue it but, to my surprise, I now cannot get GTK-Emacs to segfault. > I first started it with no ~/.fonts.cache-2 and no > /var/cache/fontconfig (and without setting LD_LIBRARY_PATH to > /usr/local/lib) and, as last night, it started slow and a ~1.6 MB > large ~/.fonts.cache-2 was rebuilt. But then I could start further > instances without deleting ~/.fonts.cache-2, unlike last night. > Moreover, when I moved fontconfig back into /var/cache/, I still could > start GTK-Emacs (and a big ~/.fonts.cache-2 was again rebuilt). > That's the current situation. So, I'm pleased that I have GTK-Emacs > back again, but I would still like to know why I lost it in the first > place, so if anyone has an suggestions, I'd be grateful. Well, now I can get GTK-Emacs to segfault again :-). I noticed that the desktop fonts didn't look as sharp as they normally do (it took me a while to notice this, probably because the fonts in Emacs are always not so sharp :-), so I ran fc-cache, exited KDE and logged on again. Now my desktop fonts are back to their previous sharpness, but Emacs-GTK segfaults again with the standard invocation (but I can start it by setting LD_LIBRARY_PATH to /usr/local/lib). So if someone is able to advise me how to debug this, I can try to do it. Steve Berman ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
gnus queries all mail folders on startup
I'm using nnimap in gnus to read my email.
Each time I start gnus, it polls every one of my hundreds of mail
folders, which takes quite a long time.
I've set gnus-activate-level to 5, and unsubscribed from the folders I
don't want it to scan. I've checked, and those folders now have a
rank of 6, and so they shouldn't be scanned by default.
If I interrupt the lengthy startup process, I see a backtrace like
this:
accept-process-output(# 0 100)
imap-wait-for-tag(919 nil)
imap-send-command-wait("EXAMINE \"sites.s\"")
imap-mailbox-select-1("sites.s" examine)
imap-mailbox-select("sites.s" examine)
nnimap-find-minmax-uid("sites.s" examine)
nnimap-retrieve-groups(("sites.linkedin" "deleted" "sites.worth1000"
"sites.google.blogger" ...) "localhost")
gnus-retrieve-groups(("sites.linkedin" "deleted" "sites.worth1000"
"sites.google.blogger" ...) (nnimap "localhost"))
gnus-read-active-file-2(("sites.linkedin" "deleted" "sites.worth1000"
"sites.google.blogger" ...) (nnimap "localhost"))
gnus-read-active-file-1((nnimap "localhost") nil)
gnus-read-active-file(nil nil)
gnus-setup-news(nil nil nil)
byte-code(...)
gnus-1(nil nil nil)
gnus(nil)
call-interactively(gnus)
And I can see here that the rank of "sites.worth1000" is 6, whereas
gnus-activate-level is 5:
ELISP> (gnus-info-rank (assoc "sites.worth1000" gnus-newsrc-alist))
6
ELISP> gnus-activate-level
5
Info node "(gnus) Group Levels" tells me:
Gnus will normally just activate (i. e., query the server about)
groups on level `gnus-activate-level' or less. If you don't want to
activate unsubscribed groups, for instance, you might set this variable
to 5. The default is 6.
In GNU Emacs 22.0.91.24 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
of 2006-12-06 on chrislap
X server distributor `RealVNC Ltd', version 11.0.3370
configured using `configure '--with-gtk' '--prefix' '/usr/local/emacs22'
'--with-xpm' '--with-jpeg' '--with-png' '--with-gif''
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bad copyright years
> > t-mouse.el was added in 2006 so it is correct. > > It can't be correct. See my thread in emacs-devel. > If Rubini and Zimmermann have signed assignments, their names should > not appear as copyright holders. If they haven't, the file should not > be in Emacs, AFAIU. And I thought we said that CC mode was added to Emacs in 1992, yet e.g ;;; cc-langs.el --- language specific settings for CC Mode ;; Copyright (C) 1985, 1987, 1992, 1993, 1994, 1995, 1996, 1997, 1998, ;; 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software ;; Foundation, Inc. i.e the years before 1992 are still in the header Q. to RMS: What *should* the header for t-mouse.el look like? Currently: ;; Copyright (C) 1994,1995 Alessandro Rubini <[EMAIL PROTECTED]> ;; parts are by Ian T Zimmermann <[EMAIL PROTECTED]>, 1995,1998 ;; Copyright (C) 2006 ;; Free Software Foundation, Inc. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
On Wed, 06 Dec 2006 16:50:47 +0100 Jan Djärv <[EMAIL PROTECTED]> wrote: > Hmm, modifying the Makefile wont do, as pango dynamically links in > fontconfig at runtime. > > If you built fontconfig under /usr/local/lib and the libfontconfig.so > file is in /usr/local/lib, you should be able to do > > % LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH > % export LD_LIBRARY_PATH > % emacs > > or > % gdb emacs > > to get Emacs to use the fontconfig you have compiled. Thanks, this worked, and GTK Emacs started without a problem and seemed to function normally. The only unusual thing was that, after emacs started, the shell printed "Invalid directory name /usr/local/share/fonts"; do you know what the significance of this is (the directory does exist)? I then used strings and ediff to compare the libfontconfig.so I built with SUSE's libfontconfig.so in /usr/lib. One of the differences was that SUSE's libfontconfig.so uses the directory /var/cache/fontconfig, whereas my build uses /usr/local/var/cache/fontconfig. As an experiment I moved fontconfig out of /var/cache/ and then invoked GTK-Emacs (without setting LD_LIBRARY_PATH to /usr/local/lib), and it started. However, it took exceptionally long to start, and I noticed afterwards that ~/.fonts.cache-2 had been rebuilt and was ~1.6 MB (its normal size is 8 KB). Then I could not start a new instance of GTK-Emacs unless I deleted ~/.fonts.cache-2, and then it was rebuilt again. Also, when I moved the fontconfig directory back into /var/cache, I again could not start GTK-Emacs. So it appeared that SUSE's fontconfig was somehow broken, and that the breakage was somehow caused by wxGTK (since before installing that I had no problem starting GTK-Emacs with the same fontconfig). This was the state of things last night. This morning I wanted to pursue it but, to my surprise, I now cannot get GTK-Emacs to segfault. I first started it with no ~/.fonts.cache-2 and no /var/cache/fontconfig (and without setting LD_LIBRARY_PATH to /usr/local/lib) and, as last night, it started slow and a ~1.6 MB large ~/.fonts.cache-2 was rebuilt. But then I could start further instances without deleting ~/.fonts.cache-2, unlike last night. Moreover, when I moved fontconfig back into /var/cache/, I still could start GTK-Emacs (and a big ~/.fonts.cache-2 was again rebuilt). That's the current situation. So, I'm pleased that I have GTK-Emacs back again, but I would still like to know why I lost it in the first place, so if anyone has an suggestions, I'd be grateful. Steve Berman ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Cursor placement with mouse in long lines with wrapped tab
Klaus Zeitler <[EMAIL PROTECTED]> writes: > When I change the frame to 81 columns (the tab in the long line is now wrapped > after 1 char), clicking on the '7' will set the cursor to '6'. > > In GNU Emacs 22.0.50.14 (sparc-sun-solaris2.8, Motif Version 2.1.0) > of 2006-11-28 on sfsws4 I can't reproduce that behaviour in "GNU Emacs 22.0.91.24 (i686-pc-linux-gnu, GTK+ Version 2.8.20)\n of 2006-12-06 on chrislap" - could you try rebuilding from newer sources and see if it still happens? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: w32 build problem in src/process.c
Bill Karh <[EMAIL PROTECTED]> writes: > Hey, > > I'm unable to build the latest CVS version with MSVC. There is a > compiler problem with src/process.c and the "strncasecmp" and > "strcasecmp" symbols. Here is the patch. Hi Bill, Thank you for the bug report and patch. > +#define strcasecmp _stricmp > +#define strncasecmp _strnicmp I'll install a different patch shortly, avoiding the use of those functions. -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
Jan Djärv <[EMAIL PROTECTED]> writes: > In summary, pkg-config is a very helpful tool, but you have to get use to it. And for better or for worse, it seems to be becoming the standard method of doing the sort of things it does. So if there are problems with it, we should either try to fix package-config (send bug reports), or try to convince people to use something else (this option seems a lot harder!). Simply _ignoring_ package-config doesn't seem practical. -Miles -- Freedom's just another word, for nothing left to lose --Janis Joplin ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
