Re: Emacs trunk needs to increase PURESIZE
On 2007-07-30 21:47 +0100, Richard Stallman wrote: > The following change solves it, however it seems to become > insufficient sooner or later. > > Please add 1 to the value. I am curious of how is the value for PURESIZE decided? -- Leo (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 (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 (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: >> 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 (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 (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 (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 (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 (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->Font&Colors 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 (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: > I'm not sure. Is the font size of ASCII characters the same > in emacs and xterm? The font size of ASCII characters are the same in emacs and xterm. -- Leo (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 (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 (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 (GPG Key: 9283AA3F) <>___ 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 (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 doc string of `gnus-level-unsubscribed'?
- Reiner Steib (2007-06-11) wrote:- > [ Please report Gnus issues directly to the Gnus list [EMAIL PROTECTED], > or at least Cc ding ] > > On Mon, Jun 11 2007, Leo wrote: > >> , >> | 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? > > No, see (info "(gnus)Group Levels"). Is the following doc string more > clear? > > ,[ v gnus-level-unsubscribed RET ] > | 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. This sentence looks redundant to me. The rest is clear. > | Groups with levels less than `gnus-level-subscribed', which should > | be less than this variable, are subscribed. Groups with levels from > | `gnus-level-subscribed' (exclusive) upto this variable (inclusive) > | are unsubscribed. See also `gnus-level-zombie', `gnus-level-killed' > | and the Info node `Group Levels' for details. > ` > > Bye, Reiner. -- Leo (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 (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 (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 (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 (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 (# 141973 (6 > | . 24) 72100380 nil 141973 (6 . 23) nil (0 . 0) (1 . 0))) t) > | mouse-drag-region((down-mouse-1 (# 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 (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 (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 (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 (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 (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 (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 (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 (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
flyspell-correct-word-before-point errs in terminal
Hi all,
The error message when invoking flyspell-correct-word-before-point in an
emacs running in terminal is not clear.
,
| Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p
| nil) flyspell-emacs-popup(nil ("musick" 1 ("mu sick" "mu-sick" "music"
| "musk" "musics" "misc" "musical" "musky" "Mick" "Mosaic" "mick"
| "mosaic" "muck" "musicked" "muskie" "sick" "music's" "masc" "mask"
| "muskier" "Muzak" "muzak") nil) "musick")
| flyspell-correct-word-before-point()
| call-interactively(flyspell-correct-word-before-point)
`
BTW, should this function be made to work in terminal?
Best,
--
Leo (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 (# 141973 (6 | . 24) 72100380 nil 141973 (6 . 23) nil (0 . 0) (1 . 0))) t) | mouse-drag-region((down-mouse-1 (# 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 (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 (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 #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 , arg=173083029, handlers=137634497, hfun=0x8192380 ) 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 , handlers=137634497, hfun=0x8105ed0 ) at eval.c:1481 #44 0x08105313 in command_loop_2 () at keyboard.c:1329 #45 0x081633
Re: [emacs-unicode-2] Segmentation fault 0x081b3df2 in xftfont_draw
- Kenichi Handa (2007-04-17) wrote:- >> > 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. > > Thank you for checking that. > >> > And, I think the frequency of flickering is also reduced. > >> Flickering is still a problem. > > Yes. What I've done is just to reduce it. I'm now working > on improving it. Any news on this? -- Leo (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:- > 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 (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(# 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-fon
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(# 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 (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 (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, > > > Stefan Looks like rxvt is loaded as I noticed a few functions with "rxvt-..". However, "Shift + F1" is the same as "F1". -- Leo (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
Dear Eli, - Eli Zaretskii (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"? regards, -- Leo (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 (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 (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
0 , 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 , 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 =
#58 0x08105eb6 in Frecursive_edit () at keyboard.c:1067
buffer =
#59 0x080fbd52 in main (argc=3, argv=0xbfc099b4) at emacs.c:1786
tem =
lib_src_exists =
etc_exists =
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 (GPG Key: 9283AA3F)
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[Unicode2] Crash
e /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: 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 C-y C-y C-y C-y C-x C-s C-x C-j C-x k C-x k M-x g n u s v C-x [ C-x k L M-x r e p o o r 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 skeleton...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[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 (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 (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
- 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 (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-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 (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-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. I will try a font that cause flickering and see if I can catch a bug. > >> 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. I can confirm this. Do you think that's a bug in dejavu sans mono? > > Perhaps we must do something like this: > > o When we open a font for a frame, check the ascents and > descents of ASCII characters (perhaps checking only "\|/" > is ok), and set font's ascent and descent to the maximum > of them if the font's data is shorter than glyphs' data. regards, -- Leo (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 ] >> 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 (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 (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
0
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 =
lose =
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 =
prev_modiff = 4213
prev_buffer = (struct buffer *) 0xad65150
was_locked = 0
already_adjusted = 0
#21 0x08162ba2 in internal_condition_case (bfun=0x810af40 ,
handlers=137634497, hfun=0x8105a60 ) at eval.c:1481
val =
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 , 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 , 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 =
#26 0x08105d26 in Frecursive_edit () at keyboard.c:1067
buffer =
#27 0x080fbbc2 in main (argc=3, argv=0xbfb92314) at emacs.c:1786
tem =
lib_src_exists =
etc_exists =
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 (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 (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 (GPG Key: 9283AA3F) ___ 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 (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
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 (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 (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 (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 (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 (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 (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:
> In article <[EMAIL PROTECTED]>, Leo <[EMAIL PROTECTED]> writes:
>
>> Thank you. Could you give me a test case? I use "‐", but it has bold
>> face even without the new fontset.c. So I can't see which bug it has
>> fixed.
>
> Ah, it depends on which font you have. By default,
> emacs-unicode has these as fallback fonts (FAMILY
> . REGISTRY):
>
> (nil . "gb2312.1980")
> (nil . "gbk-0")
> (nil . "gb18030")
> (nil . "jisx0208")
> (nil . "ksc5601.1987")
> (nil . "CNS11643.1992-1")
> (nil . "CNS11643.1992-2")
> (nil . "CNS11643.1992-3")
> (nil . "CNS11643.1992-4")
> (nil . "CNS11643.1992-5")
> (nil . "CNS11643.1992-6")
> (nil . "CNS11643.1992-7")
> (nil . "big5")
> (nil . "jisx0213.2000-1")
> (nil . "jisx0213.2004-1")
> (nil . "jisx0212"))
> (nil . "iso10646-1")
> ("gnu-unifont" . "iso10646-1")
> ("mutt-clearlyu" . "iso10646-1")
>
> The previous bug was that when you have gnu-unifont (which
> has a glyph for "‐"), that font is used instead of bold
> version of "DejaVu LGC Sans Mono". But, it seems that you
> don't have gnu-unifont. If you have any of GB/JIS/KSC/BIG5
> fonts, I think you can confirm that bug by the character
> U+2190 (LEFTWARDS ARROW).
I seem to see the other way around.
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)
>> I am still seeing square box for bold version of "─" with the new
>> fontset.c.
>
> Sorry, that is another bug which was not yet completely fixed by the
> fontset.c I sent. I'm now working on it.
Thanks.
> ---
> Kenichi Handa
> [EMAIL PROTECTED]
--
Leo (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-05, Kenichi Handa said: > In article <[EMAIL PROTECTED]>, Leo <[EMAIL PROTECTED]> writes: > >> > 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 >> ` > > The bold font I downloaded from > http://dejavu.sourceforge.net doesn't contain a glyph for > U+2500. But, I tested with U+2010 (both normal and bold > fonts contain a glyph for that character0, and found a bug. > Could you please try with the attached > emacs-unicode-2/src/fontset.c? I have not yet committed it > because the change is big and I think more comments should > be attached. > > --- > Kenichi Handa > [EMAIL PROTECTED] Thank you. Could you give me a test case? I use "‐", but it has bold face even without the new fontset.c. So I can't see which bug it has fixed. I am still seeing square box for bold version of "─" with the new fontset.c. Regards, -- Leo (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
I caught a crash (backtrace attached). I am not sure if it is related to this bug so I guess I'd just put it here. crash_20070401.log.bz2 Description: crash_20070401.log.bz2 -- Leo (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: M-w C-x m z h a o C-y C-u 3 C-k C-k C-k C-x 1 C-a C-o C-o M-x b b d b j i z e C-x o C-u C-o p h o C-k M o 0 7 9 1 7 3 5 5 1 0 2 b c h u a n C-u e 0 7 7 0 3 7 2 4 3 1 4 q 0 7 7 2 5 0 2 8 1 6 9 C-x 1 C-c C-k y C-c C-k y y q g q q L M-g p q l g z y d C-x b g r M-x r e p o o r b 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: 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 (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 (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 (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 (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: > 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 (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 Does this script work with gawk? I don't have nawk in my system. -- Leo (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 (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! On 2007-03-28, Jan Djärv said: > Richard Stallman skrev: >> A suggestion is that Info should use some sort of Quit icon >> instead of the delete, like for example >> http://developer.gnome.org/doc/API/2.0/gtk/gtk-quit.png. >> >> That sounds good, if there is no copyright issue for the icon. >> Can we use it without a delay? > > I think so. This is a stock GTK icon and we use a lot of other stock > GTK icons, see emacs/etc/images/README. > > Jan D. Any plan to update the icons taken from gnome-icon-themes? I think those icons are taken from gnome <= 2.14. Now 2.18 was out and >= 2.20 will be once emacs 22.1 is ready to release. They look outdated. See these screenshots: New icons: Old icons: It is more user friendly if Emacs 22.1 fit well in the major desktop environment namely Gnome. regards, -- Leo (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 (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 (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 (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 (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 (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: n q C-x C-f . d / i n C-x v a C-x k C-x 0 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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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 (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-10 01:01 +0100) said: ^^^ >> Katsumi Yamaoka <[EMAIL PROTECTED]> writes: >> >> > Thank you for the bug report. I see the present behavior of >> > displaying big images in emacs-w3m buffers is really bad. [...] >> > I will fix it anyway, next week. > > I received notice that this image scroll issue has been fixed in the > CVS version of emacs-w3m now: Thanks. -- Leo (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 (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 3. a i x ,[ 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 (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Calc broken in Emacs unicode-2 branch
Hi,
Trying units conversion in (info "(calc)Demonstration of Calc"), I hit
an error like this,
,
| Debugger entered--Lisp error: (error "Format error in definition of mfi in
units table: Expected a number")
| signal(error ("Format error in definition of mfi in units table: Expected a
number"))
| byte-code("[EMAIL PROTECTED]@;[EMAIL PROTECTED]" ÂÅ!'[EMAIL
PROTECTED]"Æ" [err calc-aborted-prefix error string-match
"max-specpdl-size\\|max-lisp-eval-depth" "Computation got stuck or ran too
long. Type `M' to increase the limit" nil signal] 3)
| calc-do(#[nil
"ÆÇ!ÈÉ Ê\"H \f3 ËÌ!Í% ÎÇ3 ÏÐ\n\"0 Î\nPÑ\n! ¢Ò=B ÒÓ
[EMAIL PROTECTED]"Ô
\") ] Ë\nY Ì\nÕQZ Ö! ÏÐ \"k Î P Ñ !¢Ò=~ ÒÓ×8\"ÉÊ\"[EMAIL
PROTECTED] [EMAIL PROTECTED]"!#¿ ¯ ÒÝ!ÙÇÚÞ \n
½ \nÎ?##." [units unew
uoldname expr old-units uold calc-top-n 1 nil math-units-in-expr-p t
read-string "Old units: " "" "1" string-match "\\` */" math-read-expr error
"Bad format in units expression: %s" math-mul ", new units: " "New units: " 2
var calc-enter-result "cvun" math-simplify-units math-to-standard-units "No
units specified" math-convert-units new-units math-standard-units-systems std]
9] 87)
| calc-convert-units()
| call-interactively(calc-convert-units)
`
*NB* This error only happens in emacs-unicode-2 branch.
--
Leo (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 (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 (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 (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 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. Thanks. -- Leo (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 (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 (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
