In article <[EMAIL PROTECTED]>, Leo <[EMAIL PROTECTED]> writes:
> 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. > 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. 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. --- Kenichi Handa [EMAIL PROTECTED] _______________________________________________ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
