Re: [2007-07-24] Unicode2 -- Building Emacs overflowed pure space
On 2007-07-26 09:26 +0100, Katsumi Yamaoka wrote: On 2007-07-26 01:13 +0100, Katsumi Yamaoka wrote: I got no problem in building Unicode2 of today: Dumping under names emacs and emacs-23.0.0.1 1116860 pure bytes used ./emacs -q -batch -f list-load-path-shadows Leo wrote: I still get overflowed pure space after make bootstrap in Unicode2. IIUC, the value of PURESIZE defined in src/puresize.h needs to be larger than the one actually used. What's that in your case? You can find it in the log that was made by `make' like the following: make ...options...| tee LOG This problem has gone away after last update. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[Unicode2] calendar window height incorrect
Dear all, Tested in GNU Emacs 23.0.0.4 (i686-pc-linux-gnu, GTK+ Version 2.10.14) of 2007-07-27 The calendar window has a height of half of the height of the frame. HTH, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Unicode2] calendar window height incorrect
On 2007-07-27 18:43 +0100, Leo wrote: Dear all, Tested in GNU Emacs 23.0.0.4 (i686-pc-linux-gnu, GTK+ Version 2.10.14) of 2007-07-27 The calendar window has a height of half of the height of the frame. HTH, To see this, start 'emacs -Q' and 'M-x calendar'. You will notice the calendar window is take up half of the frame. If you then do a second 'M-x calendar', you can see height shrinks to fit the height of the text in calendar window. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [2007-07-24] Unicode2 -- Building Emacs overflowed pure space
On 2007-07-26 01:13 +0100, Katsumi Yamaoka wrote: It was produced in the Fedora 7 Linux that is the same as Leo uses. I'm going to verify it with Unicode2 too... I got no problem in building Unicode2 of today: Dumping under names emacs and emacs-23.0.0.1 1116860 pure bytes used ./emacs -q -batch -f list-load-path-shadows I still get overflowed pure space after make bootstrap in Unicode2. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [2007-07-24] Unicode2 -- Building Emacs overflowed pure space
On 2007-07-26 09:26 +0100, Katsumi Yamaoka wrote: I still get overflowed pure space after make bootstrap in Unicode2. IIUC, the value of PURESIZE defined in src/puresize.h needs to be larger than the one actually used. What's that in your case? You can find it in the log that was made by `make' like the following: make ...options...| tee LOG I have lost the LOG but I didn't make change. It should be the default value. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[2007-07-24] Unicode2 -- Building Emacs overflowed pure space
Warning (initialization): Building Emacs overflowed pure space. (See the node Pure Storage in the Lisp manual for details.) HTH, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-unicode-2: bootstrap failed
On 2007-07-21 15:53 +0100, Zhang Wei wrote: oo-spd/i386/temacs1.a(abbrev.o):abbrev.c:(.text+0x3b6): undefined reference to ` SYNTAX_ENTRY_FOLLOW_PARENT' collect2: ld returned 1 exit status make[2]: *** [oo-spd/i386/temacs.exe] Error 1 make[2]: Leaving directory `D:/emacs-unicode-2/src' make[1]: *** [bootstrap-temacs] Error 2 make[1]: Leaving directory `D:/emacs-unicode-2/src' make: *** [bootstrap-gmake] Error 2 Also in GNU/Linux: , | abbrev.o: In function `abbrev_check_chars': | /home/emacs/src/abbrev.c:201: undefined reference to `SYNTAX_ENTRY_FOLLOW_PARENT' | collect2: ld returned 1 exit status | make[1]: *** [temacs] Error 1 | make[1]: Leaving directory `/home/emacs/src' | make: *** [src] Error 2 ` -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] Chinese characters too small
On 2007-07-12 12:19 +0100, Kenichi Handa wrote: It appears that Chinese characters have pixelsize 16 in Emacs rxvt-unicode gnome-terminal but have a larger pixelsize in gedit xterm. How did you specify the font pixelsize in gedit? As far as I know, what you set via Edit-Preferences-FontColors is pointsize? I didn't specify pixelsize for gedit. I just make sure their ASCII characters have the same size before comparing Chinese characters. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] Chinese characters too small
On 2007-07-12 03:55 +0200, Kenichi Handa wrote: In article [EMAIL PROTECTED], Leo [EMAIL PROTECTED] writes: I configured XTerm and Emacs to use the same font with same size as follows: in .Xresources: XTerm*faceName: xft:monospace:pixelsize=16 XTerm*faceNameDoublesize: fzsongti Emacs.Font: monospace:pixelsize=16 in .emacs: (when window-system (set-fontset-font (frame-parameter nil 'font) 'han '(FZSongTi . unicode-bmp))) And then I compared Chinese characters in 'emacs -nw' running in xterm and emacs running in X11. It turns out Chinese characters are substantially smaller in Emacs running in X11. However, C-u C-x = shows that the characters have pixelsize 16. Is this a bug? I'm not sure. Is the font size of ASCII characters the same in emacs and xterm? Could you please check the actual pixel size of a Chinese character by, for instance, xmag? --- Kenichi Handa [EMAIL PROTECTED] It appears that Chinese characters have pixelsize 16 in Emacs rxvt-unicode gnome-terminal but have a larger pixelsize in gedit xterm. I am running Fedora 7. HTH, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[unicode-2] Chinese characters too small
I configured XTerm and Emacs to use the same font with same size as follows: in .Xresources: XTerm*faceName: xft:monospace:pixelsize=16 XTerm*faceNameDoublesize: fzsongti Emacs.Font: monospace:pixelsize=16 in .emacs: (when window-system (set-fontset-font (frame-parameter nil 'font) 'han '(FZSongTi . unicode-bmp))) And then I compared Chinese characters in 'emacs -nw' running in xterm and emacs running in X11. It turns out Chinese characters are substantially smaller in Emacs running in X11. However, C-u C-x = shows that the characters have pixelsize 16. Is this a bug? Here is an example: character: 大 (22823, #o54447, #x5927) preferred charset: chinese-gb2312 (GB2312 Chinese simplified: ISO-IR-58) code point: 0x3473 syntax: wwhich means: word category: C:Chinese (Han) characters of 2-byte character sets c:Chinese h:Korean j:Japanese |:While filling, we can break a line at this character. buffer code: #xE5 #xA4 #xA7 file code: #xB4 #xF3 (encoded by coding system chinese-iso-8bit-unix) display: by this font (glyph code) fzsongti:pixelsize=16:foundry=unknown:weight=medium:slant=r:width=normal (#x29B3) HTH, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: problem with transparent PNG image display
This follows from article: [EMAIL PROTECTED] in pretest-bugs list. For example the attached icon has transparent background but shows a white background in Emacs. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) attachment: system-users.png___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Support transparent PNG image properly (was: problem with transparent PNG image display)
- Chris Moore (2007-01-10) wrote:- Download this image and open it in Emacs: http://tango-project.org/static/cvs/tango-art-tools/palettes/Tango-Palette.png The image has lots of transparent pixels. Using M-x set-background-colour RET and you'll see the background of the image changes with the background. Now use 'convert' from ImageMagick to make a copy of the image: $ convert Tango-Palette.png Tango-Palette-copy.png Open the new copy in Emacs and the transparent pixels show up as white pixels. Open the copy in The GIMP or gqview and you can see that the background really is still transparent. I'm using this version of convert: Version: ImageMagick 6.2.4 12/13/06 Q16 http://www.imagemagick.org Copyright: Copyright (C) 1999-2005 ImageMagick Studio LLC In GNU Emacs 22.0.92.40 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-01-09 on trpaslik X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' I wonder if the support of transparent PNG images can be added. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
A bug in doc string of `gnus-level-unsubscribed'?
Dear all, , | gnus-level-unsubscribed is a variable defined in `gnus-start.el'. | Its value is 7 | | | Documentation: | Groups with levels less than or equal to this variable are unsubscribed. | Groups with levels less than `gnus-level-subscribed', which should be | less than this variable, are subscribed. ` The first 'less' should be 'more', right? Best, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: BUG in scroll-lock-mode?
Dear Ralf, - Ralf Angeli (2007-06-07) wrote:- * Leo (2007-06-07) writes: I put (scroll-lock-mode t) in ~/.emacs, but it is still disabled after restart emacs. Is this a bug in scroll-lock-mode? Scroll Lock mode is a buffer-local minor mode, so your command will not enable it globally. You can enable it via a hook. For example, if you wanted the mode to be activated when browsing info files, you could do this with something like (add-hook 'Info-mode-hook 'scroll-lock-mode). But looks like the doc string is not clear about this. regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: BUG in scroll-lock-mode?
Dear Ralf, - Ralf Angeli (2007-06-07) wrote:- * Leo (2007-06-07) writes: I put (scroll-lock-mode t) in ~/.emacs, but it is still disabled after restart emacs. Is this a bug in scroll-lock-mode? Scroll Lock mode is a buffer-local minor mode, so your command will not enable it globally. You can enable it via a hook. For example, if you wanted the mode to be activated when browsing info files, you could do this with something like (add-hook 'Info-mode-hook 'scroll-lock-mode). Is it a good idea to make it a global minor mode? regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
BUG in scroll-lock-mode?
Dear all, I put (scroll-lock-mode t) in ~/.emacs, but it is still disabled after restart emacs. Is this a bug in scroll-lock-mode? HTH, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: wrong-type-argument listp 27
- Leo (2007-05-19) wrote:- To reproduce: 1. start emacs in terminal 2. M-x xterm-mouse-mode 3. Use mouse to drag select a region 4. Any subsequent key stroke will cause an error, backtrace: , | Debugger entered--Lisp error: (wrong-type-argument listp 27) | mouse-drag-track((down-mouse-1 (#window 740 on #emacs 141973 (6 | . 24) 72100380 nil 141973 (6 . 23) nil (0 . 0) (1 . 0))) t) | mouse-drag-region((down-mouse-1 (#window 740 on #emacs 141973 (6 | . 24) 72100380 nil 141973 (6 . 23) nil (0 . 0) (1 . 0 | call-interactively(mouse-drag-region) ` This is tested in GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, X toolkit) of 2007-05-18. But it might also happen in Emacs 22. This seems to be fixed in GNU Emacs 23.0.0.2 (i686-pc-linux-gnu, X toolkit) of 2007-05-26 -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Console mouse support breaks unicode2 branch (was: [unicode2] Make bootstrap error)
It appears that the error occurs only when gpm support is enabled for example, in Fedora if you have gpm-devel installed, you can get this error. [gpm version 1.20] - Leo (2007-05-25) wrote:- With latest Checkout (2007-05-25): .. In file included from term.c:418: buffer.h:403: error: redefinition of ‘struct buffer_text’ buffer.h:461: error: redefinition of ‘struct buffer’ make[2]: *** [term.o] Error 1 make[2]: Leaving directory `/home/emacs/src' make[1]: *** [bootstrap-build] Error 2 make[1]: Leaving directory `/home/emacs' make: *** [bootstrap] Error 2 -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Console mouse support breaks unicode2 branch
Dear Jason, - Jason Rumney (2007-05-26) wrote:- Leo wrote: In file included from term.c:418: buffer.h:403: error: redefinition of ‘struct buffer_text’ buffer.h:461: error: redefinition of ‘struct buffer’ buffer.h is included at the top of the file, so doesn't need to be included again, but shouldn't it be protected against double inclusion by the following? #ifndef EMACS_BUFFER_H #define EMACS_BUFFER_H ... #endif /* EMACS_BUFFER_H */ FWIW, it makes 'make bootstrap' happy ;) regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
multi-tty font errors
Here are the record of three attempts to start emacsclient: [EMAIL PROTECTED] ~]$ emacsclient Waiting for Emacs... *ERROR*: Fontset -*-fixed-medium-r-normal-*-16-*-*-*-*-*-fontset-standard already exists [EMAIL PROTECTED] ~]$ emacsclient Waiting for Emacs... *ERROR*: Fontset -*-fixed-medium-r-normal-*-16-*-*-*-*-*-fontset-standard already exists [EMAIL PROTECTED] ~]$ emacsclient Waiting for Emacs... Here it immediately returns to shell and no emacs starts up. Tested in GNU Emacs 23.0.51.1 (i686-pc-linux-gnu, X toolkit, multi-tty) of 2007-05-24. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[unicode2] Make bootstrap error
With latest Checkout (2007-05-25): .. In file included from term.c:418: buffer.h:403: error: redefinition of ‘struct buffer_text’ buffer.h:461: error: redefinition of ‘struct buffer’ make[2]: *** [term.o] Error 1 make[2]: Leaving directory `/home/emacs/src' make[1]: *** [bootstrap-build] Error 2 make[1]: Leaving directory `/home/emacs' make: *** [bootstrap] Error 2 HTH, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell-correct-word-before-point errs in terminal
- Richard Stallman (2007-05-21) wrote:- The error message when invoking flyspell-correct-word-before-point in an emacs running in terminal is not clear. What Emacs version is this? Can you please send a precise test case? I don't want to have to learn how to use that command and flail around looking for a case that fails! 1. emacs -nw 2. C-x b t e s t RET 3. M-x text-mode 4. type in musick 5. C-c $ ; which invokes flyspell-correct-word-before-point You should see the error. Tested in both emacs 22 and 23. regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell-correct-word-before-point errs in terminal
- Leo (2007-05-20) wrote:- BTW, should this function be made to work in terminal? Some ideas: 1. would be neat if it would work like iswitchb or ido in the minibuffer 2. or at least it should invoke flyspell-auto-correct-word instead HTH, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
`C-x 5 m' put the *mail* buffer in fundamental mode
Tested in GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, X toolkit) of 2007-05-18. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
wrong-type-argument listp 27
Dear all, To reproduce: 1. start emacs in terminal 2. M-x xterm-mouse-mode 3. Use mouse to drag select a region 4. Any subsequent key stroke will cause an error, backtrace: , | Debugger entered--Lisp error: (wrong-type-argument listp 27) | mouse-drag-track((down-mouse-1 (#window 740 on #emacs 141973 (6 | . 24) 72100380 nil 141973 (6 . 23) nil (0 . 0) (1 . 0))) t) | mouse-drag-region((down-mouse-1 (#window 740 on #emacs 141973 (6 | . 24) 72100380 nil 141973 (6 . 23) nil (0 . 0) (1 . 0 | call-interactively(mouse-drag-region) ` This is tested in GNU Emacs 23.0.0.1 (i686-pc-linux-gnu, X toolkit) of 2007-05-18. But it might also happen in Emacs 22. Best, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
core dump
I met a weird bug and I don't know if it is due to emacs-w3m or emacs. To reproduce, in Emacs: 0. start Emacs in urxvt¹ 1. M-x w3m 2. Key `g' and type in url: ftp://ftp.gnu.org/gnu/hyperbole 3. Key `^' and see emacs hang 4. Key `C-g' and Emacs asks: i. Auto-save (y/n) ii. Core dump (y/n) I am using the unicode-2 branch of Emacs with cvs checkout 2007-05-16. Emacs-w3m cvs checkout date: 2007-05-16. Footnotes: ¹ http://software.schmorp.de/pkg/rxvt-unicode.html HTH, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) Starting program: /home/emacs/src/emacs -nw [Thread debugging using libthread_db enabled] [New Thread -1208932672 (LWP 30965)] [Switching to Thread -1208932672 (LWP 30965)] Program received signal SIGTSTP, Stopped (user). 0x00a34402 in __kernel_vsyscall () #0 0x00a34402 in __kernel_vsyscall () #1 0x49b8d396 in kill () from /lib/libc.so.6 #2 0x0811478d in sys_suspend () at sysdep.c:806 #3 0x080ff466 in interrupt_signal (signalnum=2) at keyboard.c:10656 #4 signal handler called #5 ccl_driver (ccl=0xbff1fac4, source=0xbff1eac8, destination=0xbff2fb60, src_size=1023, dst_size=0, charset_list=137595081) at ccl.c:872 #6 0x080b367f in decode_coding_ccl (coding=0xbff2fcdc) at coding.c:4524 #7 0x080b13fe in decode_coding (coding=0xbff2fcdc) at coding.c:6282 #8 0x080b2401 in decode_coding_object (coding=0xbff2fcdc, src_object=177708387, from=0, from_byte=0, to=24020, to_byte=24020, dst_object=137595129) at coding.c:6925 #9 0x080b2a0e in code_convert_string (string=177708387, coding_system=177964345, dst_object=137595129, encodep=0, nocopy=0, norecord=0) at coding.c:8078 #10 0x080b2b42 in Fdecode_coding_string (string=177708387, coding_system=177964345, nocopy=137595081, buffer=137595081) at coding.c:8120 #11 0x081647c1 in Ffuncall (nargs=3, args=0xbff2fe90) at eval.c:3007 #12 0x0818fcb2 in Fbyte_code (bytestr=139816779, vector=140157116, maxdepth=80) at bytecode.c:679 #13 0x0816420a in funcall_lambda (fun=140157508, nargs=3, arg_vector=0xbff2ffd4) at eval.c:3184 #14 0x08164611 in Ffuncall (nargs=4, args=0xbff2ffd0) at eval.c:3054 #15 0x0818fcb2 in Fbyte_code (bytestr=139647371, vector=139648020, maxdepth=32) at bytecode.c:679 #16 0x0816420a in funcall_lambda (fun=139648156, nargs=3, arg_vector=0xbff300f4) at eval.c:3184 #17 0x08164611 in Ffuncall (nargs=4, args=0xbff300f0) at eval.c:3054 #18 0x0818fcb2 in Fbyte_code (bytestr=139703091, vector=175539500, maxdepth=40) at bytecode.c:679 #19 0x0816420a in funcall_lambda (fun=175539700, nargs=4, arg_vector=0xbff30224) at eval.c:3184 #20 0x08164611 in Ffuncall (nargs=5, args=0xbff30220) at eval.c:3054 #21 0x0818fcb2 in Fbyte_code (bytestr=177827787, vector=177828508, maxdepth=64) at bytecode.c:679 #22 0x0816420a in funcall_lambda (fun=177828820, nargs=9, arg_vector=0xbff30394) at eval.c:3184 #23 0x08164611 in Ffuncall (nargs=10, args=0xbff30390) at eval.c:3054 #24 0x08165f59 in Fapply (nargs=10, args=0xbff30390) at eval.c:2430 #25 0x08163e75 in Feval (form=174586349) at eval.c:2301 #26 0x0816406f in Fprogn (args=-1074660668) at eval.c:447 #27 0x081642e4 in funcall_lambda (fun=174586368, nargs=1, arg_vector=0xbff304f4) at eval.c:3177 #28 0x08164611 in Ffuncall (nargs=2, args=0xbff304f0) at eval.c:3054 #29 0x0818fcb2 in Fbyte_code (bytestr=177553995, vector=169830652, maxdepth=48) at bytecode.c:679 #30 0x0816420a in funcall_lambda (fun=169830924, nargs=2, arg_vector=0xbff30624) at eval.c:3184 #31 0x08164611 in Ffuncall (nargs=3, args=0xbff30620) at eval.c:3054 #32 0x08165e68 in Fapply (nargs=2, args=0xbff30670) at eval.c:2485 #33 0x08165fa4 in apply1 (fn=140158233, arg=173083021) at eval.c:2749 #34 0x0819243d in read_process_output_call (fun_and_args=173083029) at process.c:4960 #35 0x08163028 in internal_condition_case_1 ( bfun=0x8192420 read_process_output_call, arg=173083029, handlers=137634497, hfun=0x8192380 exec_sentinel_error_handler) at eval.c:1529 #36 0x081925f2 in exec_sentinel (proc=174611676, reason=173095027) at process.c:6633 #37 0x08192804 in status_notify (deleting_process=0x0) at process.c:6736 #38 0x08196c25 in wait_reading_process_output (time_limit=30, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=137595081, wait_proc=0x0, just_wait_proc=0) at process.c:4461 #39 0x08053e60 in sit_for (timeout=240, reading=1, do_display=1) at dispnew.c:6579 #40 0x08107ceb in read_char (commandflag=1, nmaps=7, maps=0xbff30e10, prev_event=137595081, used_mouse_menu=0xbff30ec8, end_time=0x0) at keyboard.c:2904 #41 0x08109a35 in read_key_sequence (keybuf=0xbff30f74, bufsize=30, prompt=137595081, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9135 #42 0x0810b553 in command_loop_1 () at keyboard.c:1618 #43 0x08163252 in internal_condition_case (bfun=0x810b3c0 command_loop_1, handlers=137634497, hfun=0x8105ed0
a bug in ps-print
To reproduce: 1. Start emacs in xterm with emacs -nw 2. M-x ps-print-buffer-with-faces GNU Emacs 23.0.0.21 (i686-pc-linux-gnu, X toolkit) of 2007-05-13 ,[ error ] | Debugger entered--Lisp error: (error `ps-default-fg' and `ps-default-bg' have the same color. | Text won't appear on page. Please, check these variables.) | signal(error (`ps-default-fg' and `ps-default-bg' have the same color.\nText won't appear on page. Please, check these variables.)) | error(`ps-default-fg' and `ps-default-bg' have the same color.\nText won't appear on page. Please, check these variables.) | ps-begin-job(ps-generate-postscript-with-faces) | ps-generate(#buffer *posting on gmane.emacs.pretest.bugs* 669 892 ps-generate-postscript-with-faces) | ps-spool-with-faces(669 892 nil) | ps-print-with-faces(669 892 nil) | ps-print-buffer-with-faces(nil) | call-interactively(ps-print-buffer-with-faces) | execute-extended-command(nil) | call-interactively(execute-extended-command) ` -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: a bug in ps-print
- Vinicius Jose Latorre (2007-05-13) wrote:- Leo wrote: To reproduce: 1. Start emacs in xterm with emacs -nw 2. M-x ps-print-buffer-with-faces GNU Emacs 23.0.0.21 (i686-pc-linux-gnu, X toolkit) of 2007-05-13 ,[ error ] | Debugger entered--Lisp error: (error `ps-default-fg' and `ps-default-bg' have the same color. | Text won't appear on page. Please, check these variables.) | signal(error (`ps-default-fg' and `ps-default-bg' have the same color.\nText won't appear on page. Please, check these variables.)) | error(`ps-default-fg' and `ps-default-bg' have the same color.\nText won't appear on page. Please, check these variables.) | ps-begin-job(ps-generate-postscript-with-faces) | ps-generate(#buffer *posting on gmane.emacs.pretest.bugs* 669 892 ps-generate-postscript-with-faces) | ps-spool-with-faces(669 892 nil) | ps-print-with-faces(669 892 nil) | ps-print-buffer-with-faces(nil) | call-interactively(ps-print-buffer-with-faces) | execute-extended-command(nil) | call-interactively(execute-extended-command) ` Please, do the following steps: 1. emacs -nw 2. M-: (insert (ps-setup)) RET 3. C-x C-s settings.txt RET 4. send me back settings.txt file. Thanks, Vinicius ;;; (Emacs) ps-print version 7.2.2 ;; internal vars ;; emacs-version = 23.0.0.21 ;; ps-windows-system = nil ;; ps-lp-system = nil (setq ps-print-color-p t ps-lpr-command lpr ps-lpr-switches nil ps-printer-name nil ps-printer-name-option -P ps-print-region-function nil ps-manual-feed nil ps-end-with-control-dnil ps-paper-type 'a4 ps-warn-paper-type t ps-landscape-mode t ps-print-upside-down nil ps-number-of-columns 2 ps-zebra-stripes nil ps-zebra-stripe-height 3 ps-zebra-stripe-follow nil ps-zebra-color 0.95 ps-line-number nil ps-line-number-step1 ps-line-number-start 1 ps-default-fg'frame-parameter ps-default-bg'frame-parameter ps-razzle-dazzle t ps-use-face-background nil ps-print-control-characters 'control-8-bit ps-print-background-image nil ps-print-background-text nil ps-error-handler-message 'paper ps-user-defined-prologue nil ps-print-prologue-header nil ps-postscript-code-directory /usr/local/packages/emacs23/share/emacs/23.0.0/etc/ ps-adobe-tag %!PS-Adobe-3.0 ps-left-margin56.69291338582677 ps-right-margin 56.69291338582677 ps-inter-column 56.69291338582677 ps-bottom-margin 42.51968503937008 ps-top-margin 42.51968503937008 ps-print-only-one-header nil ps-switch-header 'duplex ps-print-header nil ps-header-lines 2 ps-header-offset 28.346456692913385 ps-header-line-pad0.15 ps-print-header-frame t ps-header-frame-alist '((fore-color . 0.0) (back-color . 0.9) (border-width . 0.4) (border-color . 0.0) (shadow-color . 0.0)) ps-print-footer nil ps-footer-lines 2 ps-footer-offset 28.346456692913385 ps-footer-line-pad0.15 ps-print-footer-frame t ps-footer-frame-alist '((fore-color . 0.0) (back-color . 0.9) (border-width . 0.4) (border-color . 0.0) (shadow-color . 0.0)) ps-show-n-of-nt ps-spool-config 'lpr-switches ps-spool-duplex nil ps-spool-tumble nil ps-banner-page-when-duplexing nil ps-left-header'(ps-get-buffer-name ps-header-dirpart) ps-right-header '(/pagenumberstring load ps-time-stamp-locale-default ps-time-stamp-hh:mm:ss) ps-left-footer'(ps-get-buffer-name ps-header-dirpart) ps-right-footer '(/pagenumberstring load ps-time-stamp-locale-default ps-time-stamp-hh:mm:ss) ps-n-up-printing 1 ps-n-up-margin 28.346456692913385 ps-n-up-border-p t ps-n-up-filling'left-top ps-multibyte-buffer nil ps-font-family'Courier ps-font-size '(7 . 8.5) ps-header-font-family 'Helvetica ps-header-font-size '(10 . 12) ps-header-title-font-size '(12 . 14) ps-footer-font-family 'Helvetica ps-footer-font-size '(10 . 12) ps-line-number-color black ps-line-number-font Times-Italic ps-line-number-font-size 6 ps-line-spacing 0 ps-paragraph-spacing 0 ps-paragraph-regexp [ ]*$ ps-begin-cut
Re: a bug in ps-print
- Vinicius Jose Latorre (2007-05-13) wrote:- Hi Leo, I've just installed a new ps-print version in CVS Emacs 22 and 23. Now if the foreground or background color is unspecified, the default color is used, that is, black for foreground and white for background. Thanks for your report, Vinicius Seems working fine now. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No F11 and F12 keys in rxvt terminal
- Stefan Monnier (2007-05-09) wrote:- Running emacs in terminal 'urxvt'¹, I seem to lose F11 and F12 keys. For example F11 behaves the same as F1 and F12 as F2. Is this a known problem? Does Emacs use lisp/term/rxvt.el in your case? If so, please see there for a comment around line 95 that talks about this issue. Does [S-f1] means Shift + F1? Yes, it does. But you didn't answer the question, Looks like rxvt is loaded as I noticed a few functions with rxvt-... However, Shift + F1 is the same as F1. In what sense? What does C-h l say after you hit S-f1 and what does it say after you hit f11 ? Stefan In the sense, `S-f1' and `f1' that they invoke the same function. However, I check the lossage and S+f1 is the same as f11. regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
No F11 and F12 keys in rxvt terminal
Hi there, Running emacs in terminal 'urxvt'¹, I seem to lose F11 and F12 keys. For example F11 behaves the same as F1 and F12 as F2. Is this a known problem? Footnotes: ¹ http://software.schmorp.de/pkg/rxvt-unicode.html -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Unicode2] Crash
- Richard Stallman (2007-05-02) wrote:- --=-=-= Content-Disposition: attachment; filename=backtrace_0105.txt Content-Description: backtrace_0105.txt #0 0x4d5967ca in XtWidgetToApplicationContext () from /usr/lib/libXt.so.6 #1 0x4d59eb5f in XtGetValues () from /usr/lib/libXt.so.6 #2 0x080d1630 in x_wm_set_size_hint (f=0xb245f48, flags=0, user_position=0) at xterm.c:9749 Now you can look at the data in the X error packet and see what caused the error. By comparing this with the arguments to these calls, you can find out what is invalid in the arguments. When you report that, someone should be able to fix the bug. I don't understand. Can someone tell me specifically what to do with this? -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Unicode2] Crash
nmaps = 7
nmaps_allocated = 7
defs = (Lisp_Object * volatile) 0xbfc09120
submaps = (Lisp_Object * volatile) 0xbfc09150
orig_local_map = 177837829
orig_keymap = 137595081
localized_local_map = 0
first_binding = 0
first_unbound = 31
mock_input = 0
fkey = {
parent = 137582805,
map = 137582805,
start = 0,
end = 0
}
keytran = {
parent = 143099317,
map = 143099317,
start = 0,
end = 0
}
delayed_switch_frame = 137595081
original_uppercase = -1077898680
original_uppercase_position = -1
starting_buffer = (struct buffer *) 0xa143130
fake_prefixed_keys = 137595081
#52 0x0810b263 in command_loop_1 () at keyboard.c:1618
cmd = value optimized out
lose = value optimized out
nonundocount = 0
keybuf = {192, 784, 137595081, 991, -1208935800, -1208933736,
137595081, 137595081, -1077898502, -1077898440, 135290072, 184254965,
-1077898502, -1077898268, 1275402637, 134517672, -1077898296, 1275086764,
20, 0, -1077898472, -1077898624, 0, 0, 137595081, 146329185, 0, 137961048,
137961032, -1077898440}
i = value optimized out
prev_modiff = 875
prev_buffer = (struct buffer *) 0x870c758
was_locked = 0
already_adjusted = 0
#53 0x08162db2 in internal_condition_case (bfun=0x810b0d0 command_loop_1,
handlers=137634497, hfun=0x8105bf0 cmd_error) at eval.c:1481
val = value optimized out
c = {
tag = 137595081,
val = 137595081,
next = 0xbfc09460,
gcpro = 0x0,
jmp = {{
__jmpbuf = {0, 137961048, 137961032, -1077898200, 112703016,
-1412696761},
__mask_was_saved = 0,
__saved_mask = {
__val = {3217068952, 135588743, 3217069188, 147530756, 17, 17,
135860480, 268435456, 3217069000, 0 repeats 11 times, 1275537948,
3086033560, 0, 4294967295, 1275477952, 134517672, 1275479632,
3217069104, 1275419786, 1275480072, 3086031496, 1}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 137634497,
var = 137595081,
chosen_clause = 137595129,
tag = 0xbfc0934c,
next = 0x0
}
#54 0x08105033 in command_loop_2 () at keyboard.c:1329
val = 0
#55 0x08162e6a in internal_catch (tag=137627681,
func=0x8105010 command_loop_2, arg=137595081) at eval.c:1222
c = {
tag = 137627681,
val = 137595081,
next = 0x0,
gcpro = 0x0,
jmp = {{
__jmpbuf = {0, 137961048, 137961032, -1077897944, 112825896,
-1412592313},
__mask_was_saved = 0,
__saved_mask = {
__val = {135588474, 147634072, 17, 17, 17, 3217069188, 4294967295,
3217068920, 135588661, 147634072, 147634075, 3217068952, 135588743,
3217069188, 147530756, 17, 137820986, 137820984, 137824056,
3217069320, 135612732, 137824057, 137820986, 137595081, 137620928,
137595105, 2, 0, 137824056, 137824057, 137595081, 3217069384}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
#56 0x08105a2c in command_loop () at keyboard.c:1308
No locals.
#57 0x08105dcb in recursive_edit_1 () at keyboard.c:1006
val = value optimized out
#58 0x08105eb6 in Frecursive_edit () at keyboard.c:1067
buffer = value optimized out
#59 0x080fbd52 in main (argc=3, argv=0xbfc099b4) at emacs.c:1786
tem = value optimized out
lib_src_exists = value optimized out
etc_exists = value optimized out
dummy = -1077896920
stack_bottom_variable = 8 '\b'
do_initial_setlocale = 1
skip_args = 0
rlim = {
rlim_cur = 10485760,
rlim_max = 18446744073709551615
}
no_loadup = 0
junk = 0x0
Lisp Backtrace:
x-show-tip (0xb11c81b)
byte-code (0x8278deb)
tooltip-show (0x87e2d43)
tooltip-help-tips (0x83388c9)
run-hook-with-args-until-success (0x8cd0a29)
tooltip-timeout (0x83388c9)
apply (0x8cbcd99)
byte-code (0x82539d3)
timer-event-handler (0xa064e9c)
input-pending-p (0x0)
sit-for (0x0)
erc-scroll-to-bottom (0x8b8d7d4)
The program is running. Exit anyway? (y or n)
--
Leo sdl.web AT gmail.com (GPG Key: 9283AA3F)
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[Unicode2] Crash
,
gcpro = 0x0,
jmp = {{
__jmpbuf = {0, 137961048, 137961032, -1076054232, -1003675709,
1944553422},
__mask_was_saved = 0,
__saved_mask = {
__val = {135588474, 147634072, 17, 17, 17, 3218912900, 4294967295,
3218912632, 135588661, 147634072, 147634075, 3218912664, 135588743,
3218912900, 147530724, 17, 137820986, 137820984, 137824056,
3218913032, 135612732, 137824057, 137820986, 137595081, 137620928,
137595105, 2, 0, 137824056, 137824057, 137595081, 3218913096}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
#60 0x08105a2c in command_loop () at keyboard.c:1308
No locals.
#61 0x08105dcb in recursive_edit_1 () at keyboard.c:1006
val = value optimized out
#62 0x08105eb6 in Frecursive_edit () at keyboard.c:1067
buffer = value optimized out
#63 0x080fbd52 in main (argc=3, argv=0xbfdcbbb4) at emacs.c:1786
tem = value optimized out
lib_src_exists = value optimized out
etc_exists = value optimized out
dummy = -1076053208
stack_bottom_variable = 8 '\b'
do_initial_setlocale = 1
skip_args = 0
rlim = {
rlim_cur = 10485760,
rlim_max = 18446744073709551615
}
no_loadup = 0
junk = 0x0
Lisp Backtrace:
x-show-tip (0xb217bdb)
byte-code (0x8278deb)
tooltip-show (0x87e14a3)
tooltip-help-tips (0x83388c9)
run-hook-with-args-until-success (0x8cd0a29)
tooltip-timeout (0x83388c9)
apply (0x8cbcd99)
byte-code (0x82539d3)
timer-event-handler (0xb45880c)
input-pending-p (0x0)
sit-for (0x0)
erc-scroll-to-bottom (0x8b8d7d4)
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
/usr/local/packages/emacs23/share/emacs/23.0.0/etc/DEBUG for instructions.
In GNU Emacs 23.0.0.18 (i686-pc-linux-gnu, X toolkit)
of 2007-04-29 on Fedora6
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure '--prefix=/usr/local/packages/emacs23'
'--with-kerberos5' '--enable-locallisppath=/usr/local/share/emacs/site-lisp'
'--without-toolkit-scroll-bars' '--with-xft' '--enable-font-backend'
'--with-x-toolkit=yes''
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: en_GB.UTF-8
value of $XMODIFIERS: @im=none
locale-coding-system: utf-8-unix
default-enable-multibyte-characters: t
Major mode: Group
Minor modes in effect:
gnus-topic-mode: t
gnus-undo-mode: t
dired-omit-mode: t
recentf-mode: t
icomplete-mode: t
show-paren-mode: t
delete-selection-mode: t
global-auto-revert-mode: t
display-time-mode: t
shell-dirtrack-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:
down down down down down down down down
down down down down down down down down
down down C-y C-y up up up up up up
up up up up up up return up C-y down
down down down down down down down down
down down down down down down down down
down down down down down down C-y up
up up up up up up up up up up up
up up up up up up up up up up up
down down down down down down down down
down down down down down down down down
down down down down down down down down
down down down down down down down down
down C-y C-y C-y C-y C-y C-y C-y C-y C-y C-y C-y
C-y C-y C-y C-y C-y C-y C-y C-y C-y C-y C-y C-y C-y
C-y C-y C-y C-y C-y C-y C-y C-y C-y C-y C-y C-y C-y
C-y C-y C-y C-y C-y C-y C-y C-y C-y C-y C-y C-y C-y
C-y C-y up up up up up up up up up
up up up up up up up down down down
down down down down down down down down
down down down down down down down C-x
C-s C-x C-j C-x k return C-x k return M-x g n u
s return f7 v return C-x [ down down down
down down down down down down down down
down down down down down down down down
down C-x k return down down down down down
down down down down down down L down
down down down down up up up up up
up down down down down down down down
down down down down down down down up
up up up up up up M-x r e p o tab o backspace
r tab return
Recent messages:
Checking new news...
Opening nntp server on nntp-serv.cam.ac.uk...done
Checking new news...done
Loading gnus-topic...done
Open /home/leo/crash.log
widget-before-change: Text is read-only: Attempt to change text outside
editable field
Making completion list...
Loading eieio-opt...done
Loading emacsbug...done
Loading
[Unicode2] mm-view.el file failed to compile
In latest code: In toplevel form: gnus/mm-view.el:634:31:Error: Autoloading failed to define function gnus-completing-read-maybe-default .. Done (Total of 0 files compiled, 1 failed, 76 skipped in 11 directories) -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [emacs-unicode-2] Segmentation fault 0x081b3df2 in xftfont_draw
Dear Kenichi, - Kenichi Handa (2007-04-17) wrote:- I've just installed w3m and emacs-w3m, visited www.6park.com, moved mouse-cursor and normal cursor onto various links, but couldn't trigger a crash. Since that website is using Chinese font and the flickering problem depends on font and size, I wonder if that is why you can not reproduce the crash. But I can confirm even with a font that *does not* cause flickering, crashes still happen. So seems there is something wrong. BTW, I am using CVS emacs-w3m. I found a suspicious code and just installed a patch. Could you please try with the latest source? The page www.6park.com has a character U+25CF (BLACK CIRCLE) near the center of the top page. I think the crash happened when you put mouse-cursor on it, and the new code stops the crashing. I can confirm the fix. I tried to trigger a crash but was not able to. And, I think the frequency of flickering is also reduced. Flickering is still a problem. regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [emacs-unicode-2] Segmentation fault 0x081b3df2 in xftfont_draw
Dear Kenichi, - Kenichi Handa (2007-04-14) wrote:- It happens usually when there are many links in a buffer such as in ERC or W3M. I can move around mouse in a w3m buffer with tons of links (such as www.6park.com) to catch a crash, which usually happens within a few minutes. I just catch one with 'emacs -Q'. Unfortunately I don't know the exact recipe to trigger a crash. I've just installed w3m and emacs-w3m, visited www.6park.com, moved mouse-cursor and normal cursor onto various links, but couldn't trigger a crash. Since that website is using Chinese font and the flickering problem depends on font and size, I wonder if that is why you can not reproduce the crash. But I can confirm even with a font that *does not* cause flickering, crashes still happen. So seems there is something wrong. BTW, I am using CVS emacs-w3m. The following can help you see the bug although it won't crash Emacs: o emacs -Q --enable-font-backend -fn SOMEFONT o C-u 3 2 M-x hanoi You should see the frame flickering like TV disturbed by static. I can confirm the flickering with some fonts of some size. For instance, this cause flickering: emacs-unicode --enable-font-backend -fn 'dejavu sans mono:pixelsize=16' but these don't cause flickering: emacs-unicode --enable-font-backend -fn 'dejavu sans mono:pixelsize=24' emacs-unicode --enable-font-backend -fn 'lucidatypewriter:pixelsize=16' I think the reason is that font-height of dejavu sans mono:pixelsize=16 is somehow shorter than the glyph '|' in that font. So, every time Emacs redraw '|', the upper and lower lines are also redrawn which leads to the whole buffer redrawing. For instance, when I replace all occurence of ?\| in lisp/play/hanoi.el with ?i, even this: emacs-unicode --enable-font-backend -fn 'dejavu sans mono:pixelsize=16' stops flickering. Indeed, using another font can stop flickering in hanoi. But flickering can still be seen by doing the following in emacs-w3m: 1. go to http://dir.gmane.org/gmane.education.brazil.infoestacio 2. In Line 10, there is All messages from the list, with excerpted texts., now move mouse cursor back and forth on that link and you will see the same phenomena as in hanoi. The font I am using is: , | dejavu lgc sans mono:pixelsize=17:foundry=unknown:weight=bold:slant=r:width=normal (#x24) ` HTH -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [emacs-unicode-2] Segmentation fault 0x081b3df2 in xftfont_draw
- Me (2007-04-14) wrote:- I will try a font that cause flickering and see if I can catch a bug. I mean a font that causes *NO* flickering. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[emacs-xft] Segmentation fault 0x081b3df2 in xftfont_draw
*) 0x8910ee0
key = 187228725
used_mouse_menu = 0
echo_local_start = 0
last_real_key_start = 0
keys_local_start = 0
local_first_binding = 0
from_string = 137595081
count = 2
t = 0
echo_start = 0
keys_start = 0
nmaps = 6
nmaps_allocated = 6
defs = (Lisp_Object * volatile) 0xbfb91a80
submaps = (Lisp_Object * volatile) 0xbfb91ab0
orig_local_map = 181311973
orig_keymap = 137595081
localized_local_map = 0
first_binding = 0
first_unbound = 31
mock_input = 0
fkey = {
parent = 137582805,
map = 137582805,
start = 0,
end = 0
}
keytran = {
parent = 143098533,
map = 143098533,
start = 0,
end = 0
}
delayed_switch_frame = 137595081
original_uppercase = -1078387768
original_uppercase_position = -1
starting_buffer = (struct buffer *) 0xad65150
fake_prefixed_keys = 137595081
#20 0x0810b0d3 in command_loop_1 () at keyboard.c:1618
cmd = value optimized out
lose = value optimized out
nonundocount = 0
keybuf = {186535197, -1078387622, 137684057, 1273850048, -1472036458,
-1078387632, 137595081, 137595081, -1078387622, -1078387560, 135289672,
172702861, -1078387622, 1273890916, 134517672, 1, 1273827264, 1258297472,
-1078387396, 0, -1078387592, -1078387744, 0, 1273823232, 137595081,
147028465, 0, 138027976, 138027960, -1078387560}
i = value optimized out
prev_modiff = 4213
prev_buffer = (struct buffer *) 0xad65150
was_locked = 0
already_adjusted = 0
#21 0x08162ba2 in internal_condition_case (bfun=0x810af40 command_loop_1,
handlers=137634497, hfun=0x8105a60 cmd_error) at eval.c:1481
val = value optimized out
c = {
tag = 137595081,
val = 137595081,
next = 0xbfb91dc0,
gcpro = 0x0,
jmp = {{
__jmpbuf = {0, 138027976, 138027960, -1078387320, 1153812704,
-211091695},
__mask_was_saved = 0,
__saved_mask = {
__val = {3216579832, 135588215, 3216580068, 147518872, 17, 17,
135859952, 268435456, 3216579880, 0 repeats 16 times, 1273871124,
3086608360, 0, 4294967295, 1273827264, 1273829064, 134517672}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 137634497,
var = 137595081,
chosen_clause = 137595129,
tag = 0xbfb91cac,
next = 0x0
}
#22 0x08104ea3 in command_loop_2 () at keyboard.c:1329
val = 1
#23 0x08162c5a in internal_catch (tag=137627681,
func=0x8104e80 command_loop_2, arg=137595081) at eval.c:1222
c = {
tag = 137627681,
val = 137595081,
next = 0x0,
gcpro = 0x0,
jmp = {{
__jmpbuf = {0, 138027976, 138027960, -1078387064, 1153812976,
-211093491},
__mask_was_saved = 0,
__saved_mask = {
__val = {135587946, 147631328, 17, 17, 17, 3216580068, 4294967295,
3216579800, 135588133, 147631328, 147631331, 3216579832, 135588215,
3216580068, 147518872, 17, 137820986, 137820984, 137824056,
3216580200, 135612204, 137824057, 137820986, 137595081, 137620928,
137595105, 2, 0, 137824056, 137824057, 137595081, 3216580264}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
#24 0x0810589c in command_loop () at keyboard.c:1308
No locals.
#25 0x08105c3b in recursive_edit_1 () at keyboard.c:1006
val = value optimized out
#26 0x08105d26 in Frecursive_edit () at keyboard.c:1067
buffer = value optimized out
#27 0x080fbbc2 in main (argc=3, argv=0xbfb92314) at emacs.c:1786
tem = value optimized out
lib_src_exists = value optimized out
etc_exists = value optimized out
dummy = -1078386040
stack_bottom_variable = 8 '\b'
do_initial_setlocale = 1
skip_args = 0
rlim = {
rlim_cur = 10485760,
rlim_max = 18446744073709551615
}
no_loadup = 0
junk = 0x0
(gdb)
HTH
--
Leo sdl.web AT gmail.com (GPG Key: 9283AA3F)
___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [emacs-unicode-2] Segmentation fault 0x081b3df2 in xftfont_draw
- Jan Djärv (2007-04-13) wrote:- Software: GNU Emacs 23.0.0.11 (i686-pc-linux-gnu, X toolkit) of 2007-04-11 Here is a backtrace of an Emacs crash. One can encounter this often by moving cursor over links etc. It only happens when using xft font. If you are using the unicode2 branch, please put that in the subject. If you are not using that, please try that branch instead, it has had a lot more development. Jan D. I just changed the subject. The crash happens with a fresh checkout of emacs-unicode-2 branch the day before. Best, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [emacs-unicode-2] Segmentation fault 0x081b3df2 in xftfont_draw
Dear Kenichi, - Kenichi Handa (2007-04-13) wrote:- Here is a backtrace of an Emacs crash. One can encounter this often by moving cursor over links etc. It only happens when using xft font. Software: GNU Emacs 23.0.0.11 (i686-pc-linux-gnu, X toolkit) of 2007-04-11 [2 xft_crash.log text/plain (7bit)] Program received signal SIGSEGV, Segmentation fault. [...] (gdb) bt full #0 0x081b3df2 in xftfont_draw (s=0xbfb8f4f0, from=0, to=1, x=387, y=275, with_background=0) at xftfont.c:501 f = (FRAME_PTR) 0x8c75490 face = (struct face *) 0xa9a08c8 xftface_info = (struct xftface_info *) 0x0 The crash is because xftface_info is NULL, but I can't reproduce it. My Emacs configuration is almost the same as yours. GNU Emacs 23.0.0.30 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2007-04-13 on etlken I run configure with --enable-font-backend, and start emacs with --enable-font-backend. As you said you are using Xft font, I think you did the same. Can't you show me the exact operation to produce that bug by starting Emacs with -Q --enable-font-backend -fn SOMEFONT? --- Kenichi Handa [EMAIL PROTECTED] It happens usually when there are many links in a buffer such as in ERC or W3M. I can move around mouse in a w3m buffer with tons of links (such as www.6park.com) to catch a crash, which usually happens within a few minutes. I just catch one with 'emacs -Q'. Unfortunately I don't know the exact recipe to trigger a crash. The following can help you see the bug although it won't crash Emacs: o emacs -Q --enable-font-backend -fn SOMEFONT o C-u 3 2 M-x hanoi You should see the frame flickering like TV disturbed by static. Also you can see CPU usage by Xorg and Emacs increased as follows: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 28208 root 15 0 283m 82m 8140 S 69.6 8.4 21:22.20 Xorg 23199 leo 15 0 23284 15m 5964 R 6.5 1.6 0:00.64 emacs I tested this in latest source: GNU Emacs 23.0.0.12 (i686-pc-linux-gnu, X toolkit) of 2007-04-13 on Fedora 6. HTH -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
misbehaviour of outline-backward-same-level
`outline-backward-same-level' will move from a heading line to a non-heading line when on the first level-1 heading. To reproduce: o Open the attached file o Go to * Head 1 o C-c C-b (which runs the command outline-backward-same-level) o Cursor moved to the first line of the buffer -*-outline-*- This is some random text. * Head 1 * Head 2 ** Item 1 ** Item 2 * Head 3 The bug causes some trouble in org mode (which derives from outline mode). See: http://permalink.gmane.org/gmane.emacs.orgmode/1570 -- Leo ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[unicode-2] tmm-menubar breaks in org mode
Here is an easily reproducible bug: o emacs -Q o M-x org-mode o M-x tmm-menubar And backtrace: , | Debugger entered--Lisp error: (wrong-type-argument listp keymap) | tmm-get-keybind([menu-bar]) | tmm-menubar() | call-interactively(tmm-menubar) | execute-extended-command(nil) | call-interactively(execute-extended-command) ` Regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] tmm-menubar breaks in org mode
- Glenn Morris (2007-04-12) wrote:- Nick Roberts wrote: It fails on Emacs 22 too (it would be best if you checked this first). I'm pretty sure it relates to my changes, but I'm not sure yet that the bug is in tmm.el. org-mode has an awesome menubar! [...] Looking at the local map, I see the keyword keymap in the list many times but not as a car. Is that reasonable? According to the lispref Inheritance and Keymaps, yes. Eg: [...] Yes, it fixes the bug. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: misbehaviour of outline-backward-same-level
- Chong Yidong (2007-04-13) wrote:- `outline-backward-same-level' will move from a heading line to a non-heading line when on the first level-1 heading. I checked in a (hopefully pretty safe) fix. I can confirm it fixes the bug. Thanks. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
On 2007-04-10, Nick Roberts said: This bug is due to skeleton-internal-1 relying on char-or-string-p to return non-nil if its argument is an integer, while in fact, char-or-string-p returns nil if its argument is a negative integer. It doesn't on Emacs 22: (char-or-string-p -4) t and if it does on Emacs 23 then I think that must be the bug. In Emacs 23: (char-or-string-p -4) = nil Regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: A funny bug in Emacs Unicode2/xft branch
On 2007-04-09, Kenichi Handa said: In old Emacs 23: ← are shown by: normal: dejavu lgc sans mono:pixelsize=16:foundry=unknown:weight=medium:slant=r:width=normal (#x563) bold: dejavu lgc sans mono:pixelsize=16:foundry=unknown:weight=bold:slant=r:width=normal (#x563) In Emacs 23 with new fontset.c: ← are shown by: normal: dejavu lgc sans mono:pixelsize=16:foundry=unknown:weight=medium:slant=r:width=normal (#x563) bold: dejavu lgc sans mono:pixelsize=16:foundry=unknown:weight=medium:slant=r:width=normal (#x563) Oops, the fontset.c I sent you had a silly bug. Please try with the new one attached at the tail. It seems I don't have settings to see this bug fix. But I can confirm ← is now using the same bold font as with old fontset.c. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[xft-emacs] XFT font in menu-bar
[GNU Emacs 23.0.0.7 (i686-pc-linux-gnu, X toolkit) of 2007-03-29] The default menu bar in Emacs started with --enable-font-backend is using X core font. Is this a known problem? FWIW, I caught a screen shot in XEmacs list and it seems it is possible to use XFT in Lucid menu-bar. http://people.exactcode.de/~rene/xemacs-beta-xft-off-by-one.png Thanks, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Screen flickers with high CPU usage in Emacs unicode 2 branch
Could someone look at this bug? It has caused hanoi, erc and emacs-w3m etc to act weirdly. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [xft-emacs] XFT font in menu-bar
On 2007-04-10, Kenichi Handa said: In article [EMAIL PROTECTED], Leo [EMAIL PROTECTED] writes: [GNU Emacs 23.0.0.7 (i686-pc-linux-gnu, X toolkit) of 2007-03-29] The default menu bar in Emacs started with --enable-font-backend is using X core font. Is this a known problem? --enable-font-backend is just to tell Emacs to use font-backend mechanism (that support both X core fonts and Xft fonts), not to tell Emacs to use only Xft fonts. For the latter, see README.unicode. I was not clear. I mean I am using xft fonts in buffer and modeline but not in menu-bar. This has made the whole Emacs frame looks weird. In addition, as far as I know, the menu bar is impleneted by using some toolkit (gtk, lucid, or ?). I think the font used in the menu bar is decided by which toolkit you compiled Emacs with. I am using Lucid toolkit. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: A funny bug in Emacs Unicode2/xft branch
On 2007-04-06, Kenichi Handa said: Sorry, that is another bug which was not yet completely fixed by the fontset.c I sent. I'm now working on it. By the way, do you have any bold font that contain U+2500? In that case, which do you prefer; use any bold font for U+2500, or use DejaVu LGC Sans Mono to display it in normal (even if the face is bold)? The former seems more correct while the latter could be a fall back. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Screen flickers with high CPU usage in Emacs unicode 2 branch
[It is on a laptop's LCD screen] I noticed Emacs unicode 2 branch has something weird but was not able to reproduce the bug until today. I falsely reported this bug to emacs-w3m list: http://article.gmane.org/gmane.emacs.w3m/6658. It might contains useful information if you cannot reproduce the bug by the following: 1. emacs -q 2. C-u 32 M-x hanoi Now you will see the screen flickers like crazy and my laptop CPU was put to its full speed. In GNU Emacs 23.0.0.7 (i686-pc-linux-gnu, X toolkit) of 2007-03-29 on sl392.st-edmunds.cam.ac.uk Windowing system distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--prefix=/usr/local/packages/emacs23' '--with-kerberos5' '--enable-locallisppath=/usr/local/share/emacs/site-lisp' '--without-toolkit-scroll-bars' '--with-xft' '--enable-font-backend' '--with-x-toolkit=yes'' 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: en_GB.UTF-8 value of $XMODIFIERS: @im=none locale-coding-system: utf-8-unix default-enable-multibyte-characters: t Major mode: Group Minor modes in effect: gnus-topic-mode: t gnus-undo-mode: t rcirc-track-minor-mode: t dired-omit-mode: t recentf-mode: t icomplete-mode: t show-paren-mode: t delete-selection-mode: t global-auto-revert-mode: t display-time-mode: t shell-dirtrack-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: down down down down down down down down down down down down down down down down down down down down down M-w C-x m z h a o tab backspace backspace backspace backspace backspace down down down down down C-y C-u 3 C-k C-k C-k C-x 1 down-mouse-4 mouse-4 double-down-mouse-4 double-mouse-4 triple-down-mouse-4 triple-mouse-4 down-mouse-4 mouse-4 down-mouse-4 mouse-4 double-down-mouse-4 double-mouse-4 down-mouse-1 mouse-1 C-a C-o C-o down-mouse-4 mouse-4 double-down-mouse-4 double-mouse-4 help-echo help-echo M-x b b d b return j i z e return C-x o C-u C-o p h o tab return C-k M o tab return 0 7 9 1 7 3 5 5 1 0 2 return b c h u a n return down C-u e return C-backspace 0 7 7 0 3 7 2 4 3 1 4 return q 0 7 7 2 5 0 2 8 1 6 9 C-x 1 help-echo down-mouse-4 mouse-4 double-down-mouse-4 double-mouse-4 down-mouse-4 mouse-4 double-down-mouse-4 double-mouse-4 down-mouse-5 mouse-5 double-down-mouse-5 double-mouse-5 triple-down-mouse-5 triple-mouse-5 C-c C-k y C-c C-k y y q g help-echo help-echo down-mouse-1 mouse-2 down-mouse-1 mouse-2 help-echo down-mouse-5 mouse-5 down-mouse-4 mouse-4 double-down-mouse-4 double-mouse-4 help-echo down-mouse-1 mouse-1 down-mouse-1 down-mouse-1 mouse-2 help-echo down-mouse-5 mouse-5 down-mouse-5 mouse-5 double-down-mouse-5 double-mouse-5 down-mouse-4 mouse-4 double-down-mouse-4 double-mouse-4 triple-down-mouse-4 triple-mouse-4 q return return help-echo down-mouse-5 mouse-5 help-echo down-mouse-5 mouse-5 down-mouse-5 mouse-5 double-down-mouse-5 double-mouse-5 triple-down-mouse-5 triple-mouse-5 triple-down-mouse-5 triple-mouse-5 down-mouse-4 mouse-4 double-down-mouse-4 double-mouse-4 triple-down-mouse-4 triple-mouse-4 triple-down-mouse-4 triple-mouse-4 triple-down-mouse-4 triple-mouse-4 triple-down-mouse-4 triple-mouse-4 triple-down-mouse-4 triple-mouse-4 triple-down-mouse-4 triple-mouse-4 q up up up up up L down-mouse-5 mouse-5 double-down-mouse-5 double-mouse-5 down-mouse-1 mouse-1 M-g p return return q l g down-mouse-4 mouse-4 double-down-mouse-4 double-mouse-4 down-mouse-5 mouse-5 down-mouse-4 mouse-4 double-down-mouse-4 double-mouse-4 triple-down-mouse-4 triple-mouse-4 z y down-mouse-4 mouse-4 double-down-mouse-4 double-mouse-4 help-echo d down-mouse-5 mouse-5 down-mouse-5 mouse-5 down-mouse-4 mouse-4 double-down-mouse-4 double-mouse-4 C-x b g r return M-x r e p o tab o backspace r tab b tab return Recent messages: Saving /home/leo/GNUS/.newsrc.eld...done byte-code: Beginning of buffer [2 times] Press any key to resume from typing break. Loading hanoi...done Press any key to resume from typing break. Mark set byte-code: Beginning of buffer Making completion list... Loading emacsbug...done call-interactively: End of buffer [2 times] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Toolbar and info mode (and others)
On 2007-03-29, Jan Djärv said: Leo skrev: Hello, Jan! The plan is to make Emacs use stock items when built with Gtk+ at least, so when icons changes due to a Gnome upgrade or a theme change, Emacs changes accordingly. This is more or less automatically done in Gtk+. But it is planned for after the release. Jan D. That would make users suffer for the next release cycle. But anyway, just a suggestion. You have a point, but changing things now will delay the release even further. Users have suffered with gnome 1.x icons for some time now. And I think the hope is that the next release will be done much faster than the time it has taken to do the upcoming release. I am not quite sure about the delay. I can replace the icons with those from gnome 2.18 and submit to you, which probably only takes a few hours. My concern is a lot of users who want to learn Emacs will be driven off by the ugly GUI interface. regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
A funny bug in Emacs Unicode2/xft branch
Hi there, [Sorry I have to come back to unicode 2 branch for a working Emacs.] [GNU Emacs 23.0.0.4 (i686-pc-linux-gnu, GTK+ Version 2.10.8) of 2007-03-28] I just noticed a very weird bug. Two exactly the same characters in a buffer, one is correctly displayed and the other is displayed as square as in the screen shot. Running 'C-u C-x =' shows the following: , | character: ─ (9472, #o22400, #x2500) | preferred charset: chinese-gb2312 (GB2312 Chinese simplified: ISO-IR-58) |code point: 0x2924 |syntax: _ which means: symbol | category: c:Chinese h:Korean j:Japanese | buffer code: #xE2 #x94 #x80 | file code: #xE2 #x94 #x80 (encoded by coding system utf-8-unix) | display: by this font (glyph code) | dejavu lgc sans mono:pixelsize=16:foundry=unknown:weight=medium:slant=r:width=normal (#x685) | | Character code properties are not shown: customize what to show | | There are text properties here: | auto-composedt | face gnus-summary-normal-read | gnus-number 219605 ` , | character: ─ (9472, #o22400, #x2500) | preferred charset: chinese-gb2312 (GB2312 Chinese simplified: ISO-IR-58) |code point: 0x2924 |syntax: _ which means: symbol | category: c:Chinese h:Korean j:Japanese | buffer code: #xE2 #x94 #x80 | file code: #xE2 #x94 #x80 (encoded by coding system utf-8-unix) | display: no font available | | Character code properties are not shown: customize what to show | | There are text properties here: | auto-composedt | face gnus-summary-high-read | gnus-number 219608 ` Regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Toolbar and info mode (and others)
Hello, Miles! On 2007-03-29, Miles Bader said: Leo [EMAIL PROTECTED] writes: My concern is a lot of users who want to learn Emacs will be driven off by the ugly GUI interface. Ugly GUI interface?!? I have no particular objection using the 2.18 icons, but they're not really any prettier than the older icons, just (very slightly) different. -Miles But the new icon theme has been chanted in both Gnome 2.16 and 2.18. I don't think Gnome team would do that if it is just slightly different. regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Toolbar and info mode (and others)
On 2007-03-29, Jan Djärv said: I am not quite sure about the delay. I can replace the icons with those from gnome 2.18 and submit to you, which probably only takes a few hours. My concern is a lot of users who want to learn Emacs will be driven off by the ugly GUI interface. And convert them to xpm, and make black and white variants and low color variants, and test them all on at least 24 bit color display, 8 bit color display and a black and white display. A few hours is not enough. OK. Leave it for now. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: A funny bug in Emacs Unicode2/xft branch
Hello, Kenichi! On 2007-03-29, Kenichi Handa said: In article [EMAIL PROTECTED], Leo [EMAIL PROTECTED] writes: [GNU Emacs 23.0.0.4 (i686-pc-linux-gnu, GTK+ Version 2.10.8) of 2007-03-28] I just noticed a very weird bug. Two exactly the same characters in a buffer, one is correctly displayed and the other is displayed as square as in the screen shot. Their faces are different. The character not displayed correctly has the face gnus-summary-high-read that has bold property. Do you have a bold version of dejavu lgc sans mono? Yes , | character: d (100, #o144, #x64) | preferred charset: ascii (ASCII (ISO646 IRV)) |code point: 0x64 |syntax: w which means: word | category: a:ASCII graphic characters 32-126 (ISO646 IRV:1983[4/0]) l:Latin r:Japanese roman | buffer code: #x64 | file code: #x64 (encoded by coding system undecided-unix) | display: by this font (glyph code) | dejavu lgc sans mono:pixelsize=16:foundry=unknown:weight=bold:slant=r:width=normal (#x47) | | Character code properties are not shown: customize what to show | | There are text properties here: | auto-composedt | face muse-emphasis-2 | fontifiedt ` Anyway, it's a bug that Emacs doesn't show that character with a proper bold font even if you don't have that bold vesion. Please show me from where I can get that font. I want to try by myself. In Fedora 6, you can just do yum install dejavu-lgc-fonts to install it. Otherwise, get it from here: ,[ http://dejavu.sourceforge.net ] | The DejaVu LGC fonts are high-quality Latin/Greek/Cyrillic fonts | based on Bitstream Vera fonts ((http://gnome.org/fonts/)). Its | purpose is to provide a wider range of characters while maintaining | the original look and feel ` regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Toolbar and info mode (and others)
Hello, Jan! The plan is to make Emacs use stock items when built with Gtk+ at least, so when icons changes due to a Gnome upgrade or a theme change, Emacs changes accordingly. This is more or less automatically done in Gtk+. But it is planned for after the release. Jan D. That would make users suffer for the next release cycle. But anyway, just a suggestion. regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line face bug
On 2007-03-11, Chong Yidong said: Chong Yidong [EMAIL PROTECTED] writes: Richard Stallman [EMAIL PROTECTED] writes: Here is an idea. When a face attribute is set by customization, set a flag to record that fact. That flag will cause the X resource to be ignored for that attribute. Do you agree that is feasible? Can you implement it? Like I mentioned, customized faces have a `theme-face' property, which can be used for this. I've checked in a fix along similar lines. I confirm it is indeed fixed. BTW, does that mean this change is redundant? 2007-02-06 Chong Yidong [EMAIL PROTECTED] * faces.el (face-set-after-frame-default): Compile attributes to be set by frame parameters before merging in X resources. Regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line face bug
On 2007-03-09, Nick Roberts said: Can someone please fix that, then ack? The behavior where X resources override Custom (and all other Elisp face settings) seems to have been around since forever --- it can be seen in Emacs 21 ... So we obviously don't need to anything about it before the release. Actually it seems to be present for the mode-line and toolbar, but not the scrollbar. That is, if I start emacs -Q, customize the background of the faces of all three (to white, say), then do `C-x 5 2', the new frame displays the mode-line and toolbar with the previos face, but the scrollbar retains its white background. However, I don't if this is because Emacs implements the scrollbar differently, or because Metacity handles it differently. The scroll bar had a similar bug but it is fixed in http://news.gmane.org/group/gmane.emacs.devel/thread=65822/force_load=t/focus=65839. I am wondering if a similar patch can be created for mode-line and toolbar. Regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line face bug
Hello, Richard! On 2007-03-07, Richard Stallman said: I mean the mode-line face setting in my code is only effective in the initial frame. In any frames created by 'C-x 5 2' the mode-line face is changed to the default as follows: You should have said that explicitly the first time! Sorry about this. Anyway, now I see. And I agree it is a bug. I suspect that the code for creating a frame is letting the X resource for the face override the customization of the face. Could you look at your X resources (do `xrdb -query') and see if you have a resource Emacs.mode-line.attributeBackground? Yes I can see the following: , | Emacs.mode-line.attributeBackground:#fbf8f1 | Emacs.mode-line.attributeForeground:#101010 ` but I don't have such settings in my ~/.Xresources. regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Mode-line face bug
Hello, list! To reproduce: 1. emacs -Q -l ml.el (ml.el is attached) 2. C-x 5 2 You can see the unwanted change of the mode-line face. ml.el Description: ml.el Regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line face bug
Hello, Richard! On 2007-03-06, Richard Stallman said: You can see the unwanted change of the mode-line face. Your code specifies a change in the mode-line face. Would you please be more specific in describing the behavior you think is mistaken? I mean the mode-line face setting in my code is only effective in the initial frame. In any frames created by 'C-x 5 2' the mode-line face is changed to the default as follows: ,[ initial frame ] | Foreground: #1010ff | Background: #00f8f1 ` ,[ other frames ] | Foreground: #101010 | Background: #fbf8f1 ` regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
'C-x v a' broken for svn backend
Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: To reproduce: 1) emacs -Q 2) open a file that is under SVN version control with changes 3) C-x v a An empty *ChangeLog* buffer is open. 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 /usr/local/packages/emacs/share/emacs/22.0.93/etc/DEBUG for instructions. In GNU Emacs 22.0.93.6 (i686-pc-linux-gnu, GTK+ Version 2.10.8) of 2007-02-08 on sl392.st-edmunds.cam.ac.uk X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--prefix=/usr/local/packages/emacs' '--with-gtk' '--with-kerberos5' '--enable-locallisppath=/usr/local/share/emacs/site-lisp' '--without-toolkit-scroll-bars' 'CFLAGS=-O2 -march=pentium-m -pipe -fomit-frame-pointer'' 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: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: erc-page-mode: t erc-menu-mode: t erc-services-mode: t erc-autojoin-mode: t erc-button-mode: t erc-ring-mode: t erc-pcomplete-mode: t erc-track-mode: t erc-match-mode: t erc-fill-mode: t erc-stamp-mode: t erc-netsplit-mode: t erc-smiley-mode: t erc-scrolltobottom-mode: t senator-minor-mode: t semantic-idle-summary-mode: t semantic-idle-scheduler-mode: t paredit-mode: t dired-omit-mode: t recentf-mode: t icomplete-mode: t show-paren-mode: t delete-selection-mode: t global-auto-revert-mode: t display-time-mode: t shell-dirtrack-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 column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: help-echo n q C-x C-f . d / i n return C-x v a C-x k return C-x 0 down-mouse-5 mouse-5 double-down-mouse-5 double-mouse-5 triple-down-mouse-5 triple-mouse-5 down-mouse-5 mouse-5 double-down-mouse-5 double-mouse-5 triple-down-mouse-5 triple-mouse-5 triple-down-mouse-5 triple-mouse-5 triple-down-mouse-5 triple-mouse-5 triple-down-mouse-5 triple-mouse-5 triple-down-mouse-5 triple-mouse-5 triple-down-mouse-5 triple-mouse-5 triple-down-mouse-5 triple-mouse-5 triple-down-mouse-5 triple-mouse-5 triple-down-mouse-5 triple-mouse-5 triple-down-mouse-5 triple-mouse-5 triple-down-mouse-5 triple-mouse-5 down-mouse-5 mouse-5 double-down-mouse-5 double-mouse-5 triple-down-mouse-5 triple-mouse-5 down-mouse-4 mouse-4 double-down-mouse-4 double-mouse-4 triple-down-mouse-4 triple-mouse-4 down-mouse-5 mouse-5 double-down-mouse-5 double-mouse-5 down-mouse-1 mouse-1 down-mouse-4 mouse-4 double-down-mouse-4 double-mouse-4 triple-down-mouse-4 triple-mouse-4 down-mouse-5 mouse-5 double-down-mouse-5 double-mouse-5 triple-down-mouse-5 triple-mouse-5 triple-down-mouse-5 triple-mouse-5 down-mouse-1 mouse-1 help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-b ug Recent messages: Generating summary...done Mark set Loading add-log...done (New file) Mark set Computing change log entries... done byte-code: End of buffer [4 times] Loading semantic-decorate-mode...done Auto-saving... Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: scroll-bar face gets changed in a new frame
On 2007-01-07, Leo said: Hi all, I suspect this is a bug. Tested in GNU Emacs 22.0.92.2 (i686-pc-linux-gnu, GTK+ Version 2.6.4) of 2007-01-07 on soup Start Emacs with emacs -q -l emacs-custom. where emacs-custom is this: ,[ emacs-custom ] | (custom-set-faces | ;; custom-set-faces was added by Custom. | ;; If you edit it by hand, you could mess it up, so be careful. | ;; Your init file should contain only one such instance. | ;; If there is more than one, they won't work right. | '(scroll-bar ((t (:background #2e3436 :foreground #ec) ` In the initial frame: ,[ M-x describe-face RET scroll-bar ] | ... | Foreground: #ec | Background: #2e3436 | ... ` Then make a new frame with 'C-x 5 2' and it becomes ,[ M-x describe-face RET scroll-bar ] | ... | Foreground: #101010 | Background: #fbf8f1 | ... ` In emacs that compiles with --without-toolkit-scroll-bars, you can see the change visually. This bug is still in GNU Emacs 22.0.93.3 (i686-pc-linux-gnu, GTK+ Version 2.10.8) of 2007-02-02 -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ps-print-buffer-with-faces doesn't use selected frame's background
On 2007-01-22, Richard Stallman said: I just tested it. With ps-use-face-background set to t, it seems to print correctly. Should that be the default setting of ps-use-face-background? Since I print to .ps file I don't mind setting it to t. But for others using the REAL printer, that would be quite a waste to print something almost completely black. Would it look good to stay with white background and using reverse-video color for the rest faces? Just a wild guess. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ps-print-buffer-with-faces doesn't use selected frame's background
On 2007-01-21, Vinicius Jose Latorre said: Richard Stallman wrote: If the ~/.emacs file have: (setq initial-frame-alist (append '((background-color DarkSlateGray)) initial-frame-alist)) (setq default-frame-alist (append '((background-color DarkSlateGray)) default-frame-alist)) (require 'printing) ; or (require 'ps-print) then ps-print is loaded before initial-frame-alist has any effect, so, ps-default-bg is set to white. Yes, that is the cause. There is no way it can examine a frame parameter before there is a frame. So your other approach would seem to be needed. Ok, I've just updated Emacs 22 CVS. I just tested it. With ps-use-face-background set to t, it seems to print correctly. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: redundant DOC files
On 2007-01-22, Miles Bader said: Eli Zaretskii [EMAIL PROTECTED] writes: The point is if I have 50 builds then the DOC-* will take up more than 100M disk space. Whoever cares about 100MB of disk space these days? ;-) If you _do_ care about 100MB of disk space (I do, as I have a small disk), you could use the emacs/quick-install-emacs script to install Emacs, instead of make install. It hard links installed files instead of copying them (which allows much faster re-installs as well as saving space), and will optionally purge old cruft like DOC-*. To do this you should give it the -p (--prune) option. -Miles Didn't know about this nice trick. But the script is lying in admin/quick-install-emacs. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: redundant DOC files
On 2007-01-20, Eli Zaretskii said: From: Leo [EMAIL PROTECTED] Date: Sat, 20 Jan 2007 06:34:24 + -rw-r--r-- 1 root root 2.1M Jan 10 10:42 DOC-22.0.92.1 -rw-r--r-- 1 root root 2.1M Jan 10 12:09 DOC-22.0.92.2 -rw-r--r-- 1 root root 2.1M Jan 14 04:52 DOC-22.0.92.3 -rw-r--r-- 1 root root 2.1M Jan 14 04:57 DOC-22.0.92.4 -rw-r--r-- 1 root root 2.1M Jan 18 21:46 DOC-22.0.92.5 -rw-r--r-- 1 root root 2.1M Jan 18 21:48 DOC-22.0.92.6 -rw-r--r-- 1 root root 2.1M Jan 20 06:08 DOC-22.0.92.7 -rw-r--r-- 1 root root 2.1M Jan 20 06:11 DOC-22.0.92.8 Can someone tell me what is the use of this DOC-* file? These are the doc strings for all the functions and variables that are preloaded into Emacs. Thank you for this. And why we have to have that many DOC-* files? Each one goes with the corresponding emacs-22.0.92.N binary which you have in your src directory. The theory behind this is that you might wish to try an older build, e.g. to see whether some problem you find in the latest build happens in earlier builds a swell. When you do that, you will need the corresponding DOC-* file, because otherwise documentation commands could show you garbage. Those emacs-22.0.92.N lying in the emacs/src dir will use the DOC-22.0.92.N in emacs/etc. Thus I agree all versions should be kept for testing purpose etc as you mentioned. But when one does make install/bootstrap, only one emacs version is installed while *ALL* DOC-* versions are installed i.e. the *installed* old DOC-* files can neither be used by the installed emacs binary nor by those in emacs/src. That's why I think they are redundant. Because each time after installing Emacs, the first thing I do is go to the data-directory and delete all of them except the one correspond to current Emacs version. If you don't need the previous emacs-* binaries, it's okay to remove them and the corresponding DOC-* files. The point is if I have 50 builds then the DOC-* will take up more than 100M disk space. Whoever cares about 100MB of disk space these days? ;-) And 50 builds give you 600MB worth of Emacs binaries (which you never mentioned in your message), so adding 100MB more to that is hardly a major issue, is it? -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: redundant DOC files
On 2007-01-20, Eli Zaretskii said: The point is if I have 50 builds then the DOC-* will take up more than 100M disk space. Whoever cares about 100MB of disk space these days? ;-) And 50 builds give you 600MB worth of Emacs binaries (which you never mentioned in your message), so adding 100MB more to that is hardly a major issue, is it? I am thinking about packaging Emacs. Those DOC-files will make my emacs package much bigger. Actually, this is how I notice this DOC file issue. I used to build Emacs in another machine. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: redundant DOC files
On 2007-01-20, Eli Zaretskii said: From: Leo [EMAIL PROTECTED] Date: Sat, 20 Jan 2007 15:01:39 + But when one does make install/bootstrap, only one emacs version is installed while *ALL* DOC-* versions are installed I think the previous emacs-* binaries are supposed to be already in place in the installation directory, from previous installs. But why would an old installed emacs-* binaries needs the new one to bring their DOC files. The current situation is like the example as follows: emacs-22.0.92.8 installs: DOC-22.0.92.8 DOC-22.0.92.7 DOC-22.0.92.6 DOC-22.0.92.5 DOC-22.0.92.4 DOC-22.0.92.3 DOC-22.0.92.2 DOC-22.0.92.1 emacs-22.0.92.7 installs DOC-22.0.92.7 DOC-22.0.92.6 DOC-22.0.92.5 DOC-22.0.92.4 DOC-22.0.92.3 DOC-22.0.92.2 DOC-22.0.92.1 emacs-22.0.92.6 installs DOC-22.0.92.6 DOC-22.0.92.5 DOC-22.0.92.4 DOC-22.0.92.3 DOC-22.0.92.2 DOC-22.0.92.1 .. Shouldn't it be something like this: emacs-22.0.92.8 installs: DOC-22.0.92.8 emacs-22.0.92.7 installs: DOC-22.0.92.7 emacs-22.0.92.6 installs: DOC-22.0.92.6 .. In this case if you have old emacs-* binaries the corresponding DOC-* are also available. And if you don't you get a cleaner install. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: redundant DOC files
On 2007-01-21, Chris Moore said:
Eli Zaretskii [EMAIL PROTECTED] writes:
You are probably packaging only a single version, so you should only
package a single DOC file, the one that goes with the binary you are
packaging.
If you include in the package emacs-XX.YY.ZZ as well as emacs, you
should do the same with DOC.
I think the bug that Leo is reporting is that 'make install' installs
all DOC files, not just the newly built one.
The top level Makefile is quite explicit about doing this:
if [ `(cd ./etc; /bin/pwd)` != `(cd $(DESTDIR)${docdir}; /bin/pwd)` ]; \
then \
echo Copying etc/DOC-* to $(DESTDIR)${docdir} ... ; \
(cd ./etc; tar -chf - DOC*) \
[...]
A problem here is that the Makefile doesn't know which of the DOC-*
files is the correct one to install, since that is determined by some
Lisp code in loadup.el, and not written anywhere that the Makefile can
easily get at it.
Can it just call the newly built emacs-22.0.92.N and get its version
number by doing something like:
src/emacs -batch -Q -eval (message emacs-version)
--
Leo sdl.web AT gmail.com (GPG Key: 9283AA3F)
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: redundant DOC files
On 2006-11-12, Leo said: In data-directory, `ls DOC*' gives: -rw-r--r-- 1 root root 2.1M Jan 10 10:42 DOC-22.0.92.1 -rw-r--r-- 1 root root 2.1M Jan 10 12:09 DOC-22.0.92.2 -rw-r--r-- 1 root root 2.1M Jan 14 04:52 DOC-22.0.92.3 -rw-r--r-- 1 root root 2.1M Jan 14 04:57 DOC-22.0.92.4 -rw-r--r-- 1 root root 2.1M Jan 18 21:46 DOC-22.0.92.5 -rw-r--r-- 1 root root 2.1M Jan 18 21:48 DOC-22.0.92.6 -rw-r--r-- 1 root root 2.1M Jan 20 06:08 DOC-22.0.92.7 -rw-r--r-- 1 root root 2.1M Jan 20 06:11 DOC-22.0.92.8 Can someone tell me what is the use of this DOC-* file? And why we have to have that many DOC-* files? Because each time after installing Emacs, the first thing I do is go to the data-directory and delete all of them except the one correspond to current Emacs version. The point is if I have 50 builds then the DOC-* will take up more than 100M disk space. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ps-print-buffer-with-faces doesn't use selected frame's background
* Vinicius Jose Latorre (2007-01-11 11:07 -0200) said: ^ I made some tests and it is not possible to use frame-parameter in the ps-default-fg and ps-default-bg initialization, because, during Emacs initilization, ps-print is loaded before the frame parameters are set. The settings: (setq ps-zebra-stripes nil ps-use-face-background t ps-default-bg t) seem to do what you want. The above settings could not work if frame parameters are changed dynamically or if you use face remapping. Thank you very much, Vinicius. Do you think we can make a better default setting so that people won't print out something unreadable by accident? -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: scroll-bar face gets changed in a new frame
Hi all, I suspect this is a bug. Tested in GNU Emacs 22.0.92.2 (i686-pc-linux-gnu, GTK+ Version 2.6.4) of 2007-01-07 on soup Start Emacs with emacs -q -l emacs-custom. where emacs-custom is this: ,[ emacs-custom ] | (custom-set-faces | ;; custom-set-faces was added by Custom. | ;; If you edit it by hand, you could mess it up, so be careful. | ;; Your init file should contain only one such instance. | ;; If there is more than one, they won't work right. | '(scroll-bar ((t (:background #2e3436 :foreground #ec) ` In the initial frame: ,[ M-x describe-face RET scroll-bar ] | ... | Foreground: #ec | Background: #2e3436 | ... ` Then make a new frame with 'C-x 5 2' and it becomes ,[ M-x describe-face RET scroll-bar ] | ... | Foreground: #101010 | Background: #fbf8f1 | ... ` In emacs that compiles with --without-toolkit-scroll-bars, you can see the change visually. ping? -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ps-print-buffer-with-faces doesn't use selected frame's background
* Vinicius Jose Latorre (2007-01-10 03:01 -0200) said: ^ Hi Leo, Thanks for the Emacs image. Welcome! [...] Thank you for the answer. However output from ps-print does not look good generally in a dark background? Is this a known problem? Ok, using the ps-default-bg default value (white) is not good when using a dark background. This is neither a problem nor a bug. You could set ps-default-bg and ps-default-fg to a suitable color. A dark background will waste a lot of ink if printed ;) But I think ps-print should choose a different color according to the background type: dark or light. One possible way to improve ps-default-bg initialization could be set it in ps-print with (frame-parameter nil 'background-color) The value of ps-default-fg and ps-default-bg variables are not changed when frame parameters change. Note that even the initialization above will not be good if the frame parameters (background-color and foreground-color) are changed dynamically. ps-print also allows face remapping, so, the initialization above could not be good depending on the colors used. Regards, Vinicius -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: problem with transparent PNG image display
* Chris Moore (2007-01-10 01:49 +0100) said: ^^^ Download this image and open it in Emacs: http://tango-project.org/static/cvs/tango-art-tools/palettes/Tango-Palette.png The image has lots of transparent pixels. Using M-x set-background-colour RET and you'll see the background of the image changes with the background. Now use 'convert' from ImageMagick to make a copy of the image: $ convert Tango-Palette.png Tango-Palette-copy.png Open the new copy in Emacs and the transparent pixels show up as white pixels. Open the copy in The GIMP or gqview and you can see that the background really is still transparent. I'm using this version of convert: Version: ImageMagick 6.2.4 12/13/06 Q16 http://www.imagemagick.org Copyright: Copyright (C) 1999-2005 ImageMagick Studio LLC In GNU Emacs 22.0.92.40 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2007-01-09 on trpaslik X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' I actually have noticed this a long time ago using Gnus' Face/X-Face feature. All transparent parts become black. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ps-print-buffer-with-faces doesn't use selected frame's background (was: ps-print-buffer-with-faces in dark background)
Hi Vinicius, * Vinicius Jose Latorre (2007-01-08 23:21 -0200) said: ^ Hi Eli, Hi Leo, Eli Zaretskii wrote: From: Leo [EMAIL PROTECTED] Date: Sat, 06 Jan 2007 17:29:34 + * Eli Zaretskii (2007-01-06 12:59 +0200) said: ^ `ps-print-buffer-with-faces' will print a dark background buffer into a .ps file with white background. This makes the text difficult to read. This is a feature. See the variable ps-use-face-background for how to override it. I play with it. I put the buffer I want to print in another frame and swap its foreground and background by modifying frame parameters so that the change only happens in that frame. But then printing still uses the global frame parameter's foreground and background colors instead of the selected frame's. Is this a bug? I don't know. Vinicius, could you please look into this? Thanks. ps-print does not get color frame parameters; it only deals with faces. The variables ps-default-fg, ps-default-bg and ps-use-face-background are only relative to faces. So, to get the frame parameters to print you could use some function like: (defun my-ps-print-buffer-with-faces (optional filename) (interactive (list (ps-print-preprint current-prefix-arg))) (let ((ps-default-bg (frame-parameter nil 'background-color)) (ps-default-fg (frame-parameter nil 'foreground-color)) (ps-use-face-background t)) (ps-print-buffer-with-faces filename))) Regards, Thank you for the answer. However output from ps-print does not look good generally in a dark background? Is this a known problem? exampel.ps.bz2 Description: exampel.ps.bz2 Vinicius PS: See also: How Ps-Print Deals With Faces http://www.emacswiki.org/cgi-bin/wiki/PsPrintPackage#PsPrintPackage21 How Ps-Print Deals With Color http://www.emacswiki.org/cgi-bin/wiki/PsPrintPackage#PsPrintPackage22 regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Calc broken in Emacs unicode-2 branch
Can someone give me a hint what has screwed up calc? Another error: 1. Start calc with C-x * * 2. 'x RET 3. a i x RET ,[ error ] | Preparing rule set IntegAfterRules... | if: Syntax error: [ | opt(a) ln(x) + opt(b) ln(y) := 2 a esimplify(arctanh(x-1)) | :: a + b = 0 :: nrat(x + y) = 2 || nrat(x - y) = 2, | a * (b + c) := a b + a c :: constant(a) | ] ` -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
ps-print-buffer-with-faces doesn't use selected frame's background (was: ps-print-buffer-with-faces in dark background)
* Eli Zaretskii (2007-01-06 12:59 +0200) said: ^ `ps-print-buffer-with-faces' will print a dark background buffer into a .ps file with white background. This makes the text difficult to read. This is a feature. See the variable ps-use-face-background for how to override it. I play with it. I put the buffer I want to print in another frame and swap its foreground and background by modifying frame parameters so that the change only happens in that frame. But then printing still uses the global frame parameter's foreground and background colors instead of the selected frame's. Is this a bug? -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Image scroll issue
* Chris Moore (2007-01-05 16:49 +0100) said: ^^^ Great! Could you report this to the w3m maintainers. Sure. One thing I still don't understand, however, is why timer-list is nil when I check it from inside Emacs, but Lisp_Object Vtimer_list in keyboard.c contains the w3m timer when process.c calls keyboard.c's timer_check(1). I thought Lisp's timer-list and C's Vtimer_list were just 2 names for the same data structure, but it seems I'm not seeing the full picture. Thank you for all the testing. I have also seen the bug reported to emacs-w3m. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
scroll-bar face gets changed in a new frame
Hi all, I suspect this is a bug. Tested in GNU Emacs 22.0.92.2 (i686-pc-linux-gnu, GTK+ Version 2.6.4) of 2007-01-07 on soup Start Emacs with emacs -q -l emacs-custom. where emacs-custom is this: ,[ emacs-custom ] | (custom-set-faces | ;; custom-set-faces was added by Custom. | ;; If you edit it by hand, you could mess it up, so be careful. | ;; Your init file should contain only one such instance. | ;; If there is more than one, they won't work right. | '(scroll-bar ((t (:background #2e3436 :foreground #ec) ` In the initial frame: ,[ M-x describe-face RET scroll-bar ] | ... | Foreground: #ec | Background: #2e3436 | ... ` Then make a new frame with 'C-x 5 2' and it becomes ,[ M-x describe-face RET scroll-bar ] | ... | Foreground: #101010 | Background: #fbf8f1 | ... ` In emacs that compiles with --without-toolkit-scroll-bars, you can see the change visually. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
ps-print-buffer-with-faces in dark background
Hi all, [ Tested in: GNU Emacs 22.0.92.1 (i686-pc-linux-gnu, GTK+ Version 2.6.4) of 2006-12-31 on soup ] `ps-print-buffer-with-faces' will print a dark background buffer into a .ps file with white background. This makes the text difficult to read. Try to read the body text in the attachment. example.ps.bz2 Description: example.ps.bz2 -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Executable deleted after first run
* Chris Moore (2007-01-04 10:45 +0100) said: ^^^ On 1/4/07, Leo [EMAIL PROTECTED] wrote: It turns out all hard links will be deleted after user log off. The file system is: `type ncpfs (rw,nosuid,nodev)' as I am running Emacs on my Univ's server. Is there any reason to choose hard link over symbolic link? All regular files are hard links. A hard link is just a name for a file on disk. emacs is one name for the executable and emacs-22.0.92 is another name for the same executable. There's no concept of one being a link to the other, they are both names for the same file on disk. If all hard links are deleted, then both emacs and emacs-22.0.92 will be deleted, along with all your other files. Then I don't know what's going on. 'emacs' is deleted but 'emacs-22.0.92' is not. Any other files I created using 'ln' will also be deleted. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [gmane.emacs.help] Re: raise frame no go
* Jan Djärv (2007-01-04 12:42 +0100) said: ^ Metacity (the default Gnome window manager) is a complete mess when it comes to raise frame. Some versions works, some don't. Some require the code below, some don't. In some configurations (i.e. focus on click vs. focus on mouse) raise frame works, in some raise frame don't work. We must give up on creating workarounds for Metacity, and just tell people that metacity is buggy. Ufortunately they have to figure out a workaround for themselves and their specific verion/configuration of metacity. Unfortunately, metacity is the default WM for gnome which is quite popular and thus many users will encounter this problem. Since Redhat is maintaining metacity (also written by Redhat), I have filed a bug at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221475 -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [gmane.emacs.help] Re: raise frame no go
* Leo (2007-01-04 19:18 +) said: ^^^ * Jan Djärv (2007-01-04 12:42 +0100) said: ^ Metacity (the default Gnome window manager) is a complete mess when it comes to raise frame. Some versions works, some don't. Some require the code below, some don't. In some configurations (i.e. focus on click vs. focus on mouse) raise frame works, in some raise frame don't work. We must give up on creating workarounds for Metacity, and just tell people that metacity is buggy. Ufortunately they have to figure out a workaround for themselves and their specific verion/configuration of metacity. Unfortunately, metacity is the default WM for gnome which is quite popular and thus many users will encounter this problem. Since Redhat is maintaining metacity (also written by Redhat), I have filed a bug at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221475 Moved to: http://bugzilla.gnome.org/show_bug.cgi?id=392889 -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Executable deleted after first run
* Richard Stallman (2007-01-04 17:33 -0500) said: Is it possible for `make install' to detect this defective file system? It would be ok for `make install' to create a symlink conditionally in that case. Otherwise we can only document the problem, perhaps in etc/PROBLEMS. I think 'document it' is good enough and the workaround is easy to do anyway. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [gmane.emacs.help] Re: raise frame no go
* Jan Djärv (2007-01-04 12:42 +0100) said: ^ Metacity (the default Gnome window manager) is a complete mess when it comes to raise frame. Some versions works, some don't. Some require the code below, some don't. In some configurations (i.e. focus on click vs. focus on mouse) raise frame works, in some raise frame don't work. We must give up on creating workarounds for Metacity, and just tell people that metacity is buggy. Ufortunately they have to figure out a workaround for themselves and their specific verion/configuration of metacity. Havoc Pennington from Redhat has commented on this bug¹: I don't know if it's the problem, but the timestamp sent by that Emacs code is gibberish, which could break something even if it isn't the issue here. (Assuming I understand the Emacs code.) I don't believe raise-frame is intended to unconditionally work in metacity, btw. This is legitimate window manager behavior and no spec requires that the WM unconditionally honors a raise request. Footnotes: ¹ http://bugzilla.gnome.org/show_bug.cgi?id=392889 -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Executable deleted after first run
* Richard Stallman (2007-01-02 22:35 -0500) said: I spoke too soon. It happened again but I have no idea how to reproduce. Just make sure the user running Emacs has the 'write' access to file 'emacs' in bin dir and after sometime it will happen. If you make a practice of always running Emacs under gdb, does it still fail? If so, you could then try putting a breakpoint at `unlink' and another breakpoint at `rename'. These breakpoints will be hit occasionally for legitimate reasons, so I hope you can suffer through that for a few days. That way, you will see if the deletion of the executable hits one of these breakpoints. Could anyone provide more help on debugging this? I run Emacs as Richard suggested. I got interrupted from time to time and almost each time I check if 'emacs' is still there by using 'ls -l'. However, 'emacs' is being deleted and I can't tell when it is deleted. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Executable deleted after first run
* Chris Moore (2007-01-04 00:15 +0100) said: ^^^ Leo [EMAIL PROTECTED] writes: Hi all, To reproduce, 1. compile and install Emacs in dir ~/packages/emacs22 Compile it in ~/packages/emacs22 and install it to ~/packages/emacs22 as well? Compile in /tmp/emacs and install to ~/packages/emacs22. Sorry, I was not clear. Can you paste the ./configure line you used exactly? ./configure --prefix=/home/sl392/packages/emacs22/ --with-gtk --enable-locallisppath=/home/sl392/packages/emacs-local/site-lisp-22/ make install make install INSTALL_STRIP=-s -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Executable deleted after first run
* Chris Moore (2007-01-04 02:35 +0100) said: ^^^ Leo [EMAIL PROTECTED] writes: Can you paste the ./configure line you used exactly? ./configure --prefix=/home/sl392/packages/emacs22/ --with-gtk --enable-locallisppath=/home/sl392/packages/emacs-local/site-lisp-22/ make install make install INSTALL_STRIP=-s Thanks. I'll try using something similar tomorrow. Someone asked whether the bug happens if you run ./emacs -Q I always did my test using 'emacs -Q' i.e. gdb ./emacs and then 'r -Q'. [...] Also, did you try compiling and installing Emacs and *not* running it at all? Does it still disappear after a while? I just did a fresh install and we'll see after 24 hours ;) -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Executable deleted after first run
* Chris Moore (2007-01-04 02:35 +0100) said: ^^^ Also, did you try compiling and installing Emacs and *not* running it at all? Does it still disappear after a while? Very good question. It turns out all hard links will be deleted after user log off. The file system is: `type ncpfs (rw,nosuid,nodev)' as I am running Emacs on my Univ's server. ,[ ncpfs ] | ncpfs allows you to mount volumes of NetWare servers under Linux | and to print to NetWare print queues and spool NetWare print queues | to the Linux printing system. ` Is there any reason to choose hard link over symbolic link? -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[gmane.emacs.help] Re: raise frame no go
---BeginMessage---
Leo [EMAIL PROTECTED] writes:
I want to use emacsclient to bring Emacs frame to the front. I tried
several functions including raise-frame, x-focus-frame etc, but none
of them worked. All they do is causing the Emacs frame to flash in
the taskbar. Any ideas?
This is tested in Gnome 2.16 in Fedora 6.
Emacs 23: 20061218.
I just wanted to mention that I have the same problem. Running CVS
Emacs as of 2007-01-1 under Mandriva GNU/Linux, using GNOME with its
Metacity window manager. What I do is this:
$ emacsclient -e (my-function)
and my-function is:
(defun my-function ()
(select-frame-set-input-focus (selected-frame)))
(well, of course it does more than that but...)
Up until today I haven't played with emacsclient under GNU/Linux. I
have just used gnuclient friends under w32. I am currently coding a
small command/url/hatever launcher in Emacs, and the current behavior
is quite frustrating (when Emacs is not the topmost window).
I see this code in xterm.c:
XTframe_raise_lower (f, raise_flag)
FRAME_PTR f;
int raise_flag;
{
if (raise_flag)
{
/* The following code is needed for `raise-frame' to work on
some versions of metacity; see Window Manager
Specification/Extended Window Manager Hints at
http://freedesktop.org/wiki/Standards_2fwm_2dspec
However, on other versions (metacity 2.17.2-1.fc7), it
reportedly causes hangs when resizing frames. */
/* Lisp_Object frame;
const char *atom = _NET_ACTIVE_WINDOW; */
x_raise_frame (f);
/* XSETFRAME (frame, f);
Fx_send_client_event (frame, make_number (0), frame,
make_unibyte_string (atom, strlen (atom)),
make_number (32),
Fcons (make_number (1),
Fcons (make_number (time (NULL) * 1000),
Qnil))); */
}
else
x_lower_frame (f);
}
Is is that piece of code that fails? My version of metaciy is 2.16.1.
/Mathias
---End Message---
--
Leo sdl.web AT gmail.com (GPG Key: 9283AA3F)
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Image scroll issue
* Kim F. Storm (2007-01-02 12:17 +0100) said: Chris Moore [EMAIL PROTECTED] writes: Try using the page up/down keys or the up/down arrow keys. The arrow keys are no use. They're bound to w3m-previous-anchor and w3m-next-anchor, so they skip right past the image. Ok, so what about C-n / C-p ? This works better but need to move to the bottom line of the window before actually scrolling the image. Using page down doesn't work for me: I hit page down again. Momentarily I am 14% through the buffer, and can see all the way down to 'scarlet red' in the image, but a split second later, I'm back to 9%, and can see only 'butter', 'orange' and 'chocolate'. It seems like something is causing unnecessary redisplays / recentering. What is the value of the variables timer-list and timer-idle-list ? I see similar thing. And ,[ C-h v timer-list RET ] | timer-list is a variable defined in `C source code'. | Its value is | ([nil 17818 30706 521209 5 auto-revert-buffers nil nil] | [nil 17818 30752 0 60 appt-check nil nil] | [nil 17818 30752 0 60 display-time-event-handler nil nil] | [nil 17818 33303 986361 nil type-break-time-warning-alarm nil nil] | [nil 17818 33603 986970 nil type-break-alarm nil nil]) | Documentation: | List of active absolute time timers in order of increasing time. ` ,[ C-h v timer-idle-list RET ] | timer-idle-list is a variable defined in `C source code'. | Its value is | ([t 0 0 125000 t show-paren-function nil t] | [t 0 0 20 0.2 slime-update-modeline-package nil t] | [nil 0 0 50 0.5 blink-cursor-start nil t] | [nil 0 0 50 t jit-lock-context-fontify nil t] | [nil 0 16 0 t jit-lock-stealth-fontify nil t]) | Documentation: | List of active idle-time timers in order of increasing time. ` So I can see what the original reporter means about it being hard to see the bottom of long images. A lot of efforts have gone into making Emacs 22 scroll images in a _reasonable_ way (not perfect, but much much better than Emacs 21). I agree it is getting better ;) But if code that displays images (such as w3m seems to do) does not use Emacs' line move and page scrolling functions, such code must do the hard stuff itself... Since w3m is maintained outside Emacs, you can hardly blame Emacs itself for w3m not doing the right thing with respect to image scrolling. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Image scroll issue
Hi all, For image taller than window height, scrolling becomes difficult i.e. the whole image behaves like one line of text and almost impossible to scroll halfway up. For example, go to this page: http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines in emacs-w3m and toggle image with key 'T' and try to see the bottom row of the palette. It takes me countless tries in a screen resolution of 1280x800. In other scenario like an email with very tall in-line image, it is also a problem trying to see the whole image by scrolling. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Executable deleted after first run
Hi all, To reproduce, 1. compile and install Emacs in dir ~/packages/emacs22 2. go to ~/packages/emacs22/bin and run Emacs with ./emacs 3. Quit Emacs and executable emacs is gone. I am left with these files in bin dir: /home/leo/packages/emacs22/bin/ (allfiles) |-(f)b2m |-(f)ctags |-(f)ebrowse |-(f)emacs-22.0.92 |-(f)emacsclient |-(f)etags |-(f)grep-changelog +-(f)rcs-checkin Tested on: GNU Emacs 22.0.92.1 (i686-pc-linux-gnu, GTK+ Version 2.6.4) of 2006-12-30 on soup -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Executable deleted after first run
Hi Lennart, * Lennart Borgman (2006-12-31 17:02 +0100) said: ^^^ Leo wrote: Hi all, To reproduce, 1. compile and install Emacs in dir ~/packages/emacs22 2. go to ~/packages/emacs22/bin and run Emacs with ./emacs 3. Quit Emacs and executable emacs is gone. What did you expect? You quitted Emacs, didn't you ;-) Can't reproduce this on w32, CVS Emacs 2006-12-30. Thanks for testing. In GNU/Linux, in the bin dir, emacs is a hardlink to emacs-22.0.92 when installed. After I run Emacs from that dir by using ./emacs, file 'emacs' is gone. My past experience seems to tell me w32 doesn't support such link. regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Executable deleted after first run
Hi Jan, * Jan Djärv (2006-12-31 18:24 +0100) said: ^ Leo skrev: Hi all, To reproduce, 1. compile and install Emacs in dir ~/packages/emacs22 2. go to ~/packages/emacs22/bin and run Emacs with ./emacs 3. Quit Emacs and executable emacs is gone. I am left with these files in bin dir: /home/leo/packages/emacs22/bin/ (allfiles) |-(f)b2m |-(f)ctags |-(f)ebrowse |-(f)emacs-22.0.92 |-(f)emacsclient |-(f)etags |-(f)grep-changelog +-(f)rcs-checkin Tested on: GNU Emacs 22.0.92.1 (i686-pc-linux-gnu, GTK+ Version 2.6.4) of 2006-12-30 on soup I can't reproduce this on GNU/Linux. Does this happen if you run with ./emacs -Q as well ? Jan D. I did make install to get back emacs but was not able to reproduce this bug. I am running make bootstrap again and will report back. regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Executable deleted after first run
* Eli Zaretskii (2007-01-01 00:15 +0200) said: ^ From: Leo [EMAIL PROTECTED] Date: Sun, 31 Dec 2006 16:14:05 + Cc: emacs-pretest-bug@gnu.org My past experience seems to tell me w32 doesn't support such link. Actually, it does (on NTFS volumes). Try add-name-to-file on such a volume some day. Good to know. Thanks. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Executable deleted after first run
* Jan Djärv (2006-12-31 18:24 +0100) said: ^ Leo skrev: Hi all, To reproduce, 1. compile and install Emacs in dir ~/packages/emacs22 2. go to ~/packages/emacs22/bin and run Emacs with ./emacs 3. Quit Emacs and executable emacs is gone. I am left with these files in bin dir: /home/leo/packages/emacs22/bin/ (allfiles) |-(f)b2m |-(f)ctags |-(f)ebrowse |-(f)emacs-22.0.92 |-(f)emacsclient |-(f)etags |-(f)grep-changelog +-(f)rcs-checkin Tested on: GNU Emacs 22.0.92.1 (i686-pc-linux-gnu, GTK+ Version 2.6.4) of 2006-12-30 on soup I can't reproduce this on GNU/Linux. Does this happen if you run with ./emacs -Q as well ? Weird, I can't reproduce now. But I believe I have seen this problem for a long time. It didn't cause any trouble before because I usually install emacs as root. I will keep an eye on it. Jan D. -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
