Re: [DOC] decoding/encoding in lispref/nonascii.texi
In article <[EMAIL PROTECTED]>, Oliver Scholz <[EMAIL PROTECTED]> writes:
> I just noticed a minor mistake in lispref/nonascii.texi. Minor, but it
> might confuse people who try to understand the meaning of the various
> encoding/decoding functions:
You are right. I've just installed your change.
---
Kenichi Handa
[EMAIL PROTECTED]
> Index: lispref/nonascii.texi
> ===
> RCS file: /cvsroot/emacs/emacs/lispref/nonascii.texi,v
> retrieving revision 1.54
> diff -u -r1.54 nonascii.texi
> --- lispref/nonascii.texi 6 Feb 2006 11:55:10 - 1.54
> +++ lispref/nonascii.texi 14 May 2006 21:32:03 -
> @@ -1174,7 +1174,7 @@
> @code{no-conversion}.
>Here are the functions to perform explicit encoding or decoding. The
> -decoding functions produce sequences of bytes; the encoding functions
> +encoding functions produce sequences of bytes; the decoding functions
> are meant to operate on sequences of bytes. All of these functions
> discard text properties.
> The standard in Emacs w.r.t. the use of the words "decoding" and
> "encoding" is as follows:
> decoding: stream (file or process output) ==> internal representation
> encoding: internal representation ==> stream
> Or in other words:
> decoding: sequence of bytes ==> sequence of characters
> encoding: sequence of characters ==> sequence of bytes
> The documentation for the functions below the cited pararagraph
> (`encode-coding-region' and others) conform to this.
> Oliver
> --
> Oliver Scholz 25 Floréal an 214 de la Révolution
> Ostendstr. 61 Liberté, Egalité, Fraternité!
> 60314 Frankfurt a. M.
> ___
> emacs-pretest-bug mailing list
> emacs-pretest-bug@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GNU Emacs 23.0.0 does not compile: ‘struct co ding_system’ has no member named ‘eol_type’
In article <[EMAIL PROTECTED]>, Peter Dyballa <[EMAIL PROTECTED]> writes: > Hello! > Here are details from the *compile* buffer: > process.c: In function ‘setup_process_coding_systems’: > process.c:699: error: ‘struct coding_system’ has no member named > ‘eol_type’ This was because of incomplete (semi-auto) synching with HEAD. I've already install fixes. --- Kenichi Handa [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Sporadic segmentation faults
Is this a good fix?
*** xterm.c 31 Mar 2006 12:37:36 -0500 1.910
--- xterm.c 14 May 2006 13:19:01 -0400
***
*** 6083,6090
f = x_any_window_to_frame (dpyinfo, event.xkey.window);
if (!dpyinfo->mouse_face_hidden && INTEGERP (Vmouse_highlight)
! && !EQ (f->tool_bar_window, dpyinfo->mouse_face_window))
{
clear_mouse_face (dpyinfo);
dpyinfo->mouse_face_hidden = 1;
--- 6083,6093
f = x_any_window_to_frame (dpyinfo, event.xkey.window);
+ /* If mouse-highlight is an integer, input clears out
+mouse highlighting. */
if (!dpyinfo->mouse_face_hidden && INTEGERP (Vmouse_highlight)
! /* But not input on the tool bar. */
! && !(f != 0 && EQ (f->tool_bar_window, dpyinfo->mouse_face_window)))
{
clear_mouse_face (dpyinfo);
dpyinfo->mouse_face_hidden = 1;
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Big desktop undo buffer crashes Emacs
Luc Teirlinck wrote: >Is there any reason to keep this buffer hanging around >consuming some memory and being user visible? > > I don't think there is. I suggest to use with-temp-buffer (and buffer-disable-undo) Patch attached. *** desktop.el.~1.99.~ 2006-02-19 15:43:52.0 +0100 --- desktop.el 2006-05-12 08:47:57.615841646 +0200 *** *** 763,772 (setq locals (cdr locals))) ll))) (buffer-list))) ! (eager desktop-restore-eager) ! (buf (get-buffer-create "*desktop*"))) ! (set-buffer buf) ! (erase-buffer) (insert ";; -*- mode: emacs-lisp; coding: emacs-mule; -*-\n" --- 763,771 (setq locals (cdr locals))) ll))) (buffer-list))) ! (eager desktop-restore-eager)) ! (with-temp-buffer ! (buffer-disable-undo) (insert ";; -*- mode: emacs-lisp; coding: emacs-mule; -*-\n" *** *** 801,807 info) (setq default-directory dirname) (let ((coding-system-for-write 'emacs-mule)) ! (write-region (point-min) (point-max) filename nil 'nomessage (setq desktop-dirname dirname)) ;; --- 800,806 info) (setq default-directory dirname) (let ((coding-system-for-write 'emacs-mule)) ! (write-region (point-min) (point-max) filename nil 'nomessage) (setq desktop-dirname dirname)) ;; ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[DOC] decoding/encoding in lispref/nonascii.texi
I just noticed a minor mistake in lispref/nonascii.texi. Minor, but it
might confuse people who try to understand the meaning of the various
encoding/decoding functions:
Index: lispref/nonascii.texi
===
RCS file: /cvsroot/emacs/emacs/lispref/nonascii.texi,v
retrieving revision 1.54
diff -u -r1.54 nonascii.texi
--- lispref/nonascii.texi 6 Feb 2006 11:55:10 - 1.54
+++ lispref/nonascii.texi 14 May 2006 21:32:03 -
@@ -1174,7 +1174,7 @@
@code{no-conversion}.
Here are the functions to perform explicit encoding or decoding. The
-decoding functions produce sequences of bytes; the encoding functions
+encoding functions produce sequences of bytes; the decoding functions
are meant to operate on sequences of bytes. All of these functions
discard text properties.
The standard in Emacs w.r.t. the use of the words "decoding" and
"encoding" is as follows:
decoding: stream (file or process output) ==> internal representation
encoding: internal representation ==> stream
Or in other words:
decoding: sequence of bytes ==> sequence of characters
encoding: sequence of characters ==> sequence of bytes
The documentation for the functions below the cited pararagraph
(`encode-coding-region' and others) conform to this.
Oliver
--
Oliver Scholz 25 Floréal an 214 de la Révolution
Ostendstr. 61 Liberté, Egalité, Fraternité!
60314 Frankfurt a. M.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash in foreach_window_1 (delete-frame)
*** line 6818*** if (!NILP (w->hchild)) If optimization is not confusing this somehow, then corruption of W->hchild would not be sufficient to cause a crash there. It would require an invalid value of W itself. It is possible that the invalid value came out of the hchild field in a window handled in an outer call to foreach_window_1. Something must have been wrong with the window structure, because a window which is an hchild should never have an hchild. Horizontal and vertical splittings are supposed to alternate; the only exception is that the initial window has a vertical sibling (the minibuffer window) and may be split vertically as well. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash in foreach_window_1 (delete-frame)
> On Sun, 14 May 2006 13:18:36 +0100, David Reitter <[EMAIL PROTECTED]>
> said:
> I had this crash the other day. I had a frame with a Completions
> buffer (lower window in 2-window config.) open, and wanted to delete
> the frame. Can't reproduce, but maybe someone can tell from looking
> at the stack trace below.
> Exception: EXC_BAD_ACCESS (0x0001)
> Codes: KERN_INVALID_ADDRESS (0x0001) at 0x110bc0d0
> 0 org.gnu.AquamacsEmacs 0x0004f5d8 foreach_window_1 + 52
> (window.c:6818)
> 1 org.gnu.AquamacsEmacs 0x0004f60c foreach_window_1 + 104
> (window.c:6821)
> 2 org.gnu.AquamacsEmacs 0x0004f60c foreach_window_1 + 104
> (window.c:6821)
> 3 org.gnu.AquamacsEmacs 0x0004566c window_from_coordinates +
> 120 (window.c:949)
> 4 org.gnu.AquamacsEmacs 0x0001e3b0 remember_mouse_glyph + 60
> (xdisp.c:2061)
> 5 org.gnu.AquamacsEmacs 0x0013f83c note_mouse_movement + 332
> (macterm.c:4321)
> 6 org.gnu.AquamacsEmacs 0x0014780c XTread_socket + 2228
> (macterm.c:10366)
> 7 org.gnu.AquamacsEmacs 0x00085dc4 read_avail_input + 140
> (keyboard.c:6751)
> 8 org.gnu.AquamacsEmacs 0x00085fbc handle_async_input + 48
> (keyboard.c:6898)
> 9 org.gnu.AquamacsEmacs 0x000f175c Fdelq + 280 (fns.c:1724)
> 10 org.gnu.AquamacsEmacs 0x00015ab0 Fdelete_frame + 884
> (frame.c:1284)
Looks interesting.
frame.c:
1274/* Mark all the windows that used to be on FRAME as deleted, and then
1275 remove the reference to them. */
1276delete_all_subwindows (XWINDOW (f->root_window));
1277f->root_window = Qnil;
1278
1279Vframe_list = Fdelq (frame, Vframe_list);
Fdelete_frame sets f->root_window to Qnil at line 1277. If it is
interrupted (or read_socket_hook is called by QUIT if SYNC_INPUT is
defined) inside Fdelq, foreach_window might be called through the path
shown in the above backtrace.
window.c:
6793 void
6794 foreach_window (f, fn, user_data)
6795 struct frame *f;
6796 int (* fn) P_ ((struct window *, void *));
6797 void *user_data;
6798 {
6799foreach_window_1 (XWINDOW (FRAME_ROOT_WINDOW (f)), fn, user_data);
6800 }
In such a case, FRAME_ROOT_WINDOW (f) is Qnil and XWINDOW (...) does not
return a valid pointer.
I think this scenario can also happen on X11. Maybe test WINDOWP
(FRAME_ROOT_WINDOW (f)) before line 6799?
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GNU Emacs 23.0.0 does not compile: ‘struct co ding_system’ has no member named ‘eol_type’
Peter Dyballa <[EMAIL PROTECTED]> writes: > Hello! > > Here are details from the *compile* buffer: > > process.c: In function ‘setup_process_coding_systems’: > process.c:699: error: ‘struct coding_system’ has no member named > ‘eol_type’ > process.c:699: error: ‘CODING_EOL_UNDECIDED’ undeclared (first use in > this function) > process.c:699: error: (Each undeclared identifier is reported only once > process.c:699: error: for each function it appears in.) > process.c:700: error: ‘struct coding_system’ has no member named > ‘eol_type’ > > process.c:5078: error: ‘struct coding_system’ has no member named > ‘eol_type’ > process.c:5079: error: ‘CODING_EOL_UNDECIDED’ undeclared (first use > in this function) > process.c:5080: error: ‘struct coding_system’ has no member named > ‘eol_type’ > > process.c:5191: error: ‘struct coding_system’ has no member named > ‘eol_type’ > process.c:5193: error: ‘struct coding_system’ has no member named > ‘eol_type’ > > callproc.c: In function ‘Fcall_process’: > callproc.c:298: error: ‘struct coding_system’ has no member named > ‘eol_type’ > callproc.c:298: error: ‘CODING_EOL_UNDECIDED’ undeclared (first use > in this function) > callproc.c:298: error: (Each undeclared identifier is reported only once > callproc.c:298: error: for each function it appears in.) > callproc.c:299: error: ‘struct coding_system’ has no member named > ‘eol_type’ > > It seems that the struct coding_system in src/coding.h wasn't patched > correctly so it does not include the eol_type component ... > > > > gcc-3.3 -I/sw/include -L/sw/lib -c -I/usr/local/include -I/sw/include/ > libpng12 -I/sw/lib/pango-ft219/include -I/sw/include/pango-1.0 -I/sw/ > lib/freetype219/include -I/sw/include -Demacs -DHAVE_CONFIG_H - > DUSE_LUCID -I. -I/Users/pete/Quellen/Emacs_CVS/ > emacs-23.0.0_NS-9.0pre2a/src -I/usr/X11R6/include -fpascal-strings - > DMAC_OSX -I../mac/src -Dtemacs -ggdb -O2 -pipe -faltivec -maltivec - > mabi=altivec -mcpu=7450 -no-cpp-precomp -fomit-frame-pointer - > foptimize-register-move -fcprop-registers -frename-registers - > freorder-blocks -fpeephole -mpowerpc-gfxopt -mpowerpc-gpopt - > DUSE_ATSUI process.c > > gcc-3.3 -I/sw/include -L/sw/lib -c -I/usr/local/include -I/sw/include/ > libpng12 -I/sw/lib/pango-ft219/include -I/sw/include/pango-1.0 -I/sw/ > lib/freetype219/include -I/sw/include -Demacs -DHAVE_CONFIG_H - > DUSE_LUCID -I. -I/Users/pete/Quellen/Emacs_CVS/ > emacs-23.0.0_NS-9.0pre2a/src -I/usr/X11R6/include -fpascal-strings - > DMAC_OSX -I../mac/src -Dtemacs -ggdb -O2 -pipe -faltivec -maltivec - > mabi=altivec -mcpu=7450 -no-cpp-precomp -fomit-frame-pointer - > foptimize-register-move -fcprop-registers -frename-registers - > freorder-blocks -fpeephole -mpowerpc-gfxopt -mpowerpc-gpopt - > DUSE_ATSUI callproc.c > > env CC=gcc-3.3 ./configure --without-sound --without-pop --with-xpm -- > with-jpeg --with-tiff --with-gif --with-png --enable-locallisppath=/ > Library/Application\ Support/Emacs/calendar23:/Library/Application\ > Support/Emacs/preview:/Library/Application\ Support/Emacs/auctex/ > images:/Library/Application\ Support/Emacs/auctex:/Library/Application > \ Support/Emacs CFLAGS="-ggdb -O2 -pipe -faltivec -maltivec - > mabi=altivec -mcpu=7450 -no-cpp-precomp -fomit-frame-pointer - > foptimize-register-move -fcprop-registers -frename-registers - > freorder-blocks -fpeephole -mpowerpc-gfxopt -mpowerpc-gpopt - > DUSE_ATSUI" CPPFLAGS="-I/usr/local/include -I/sw/include/libpng12 -I/ > sw/lib/pango-ft219/include -I/sw/include/pango-1.0 -I/sw/lib/ > freetype219/include -I/sw/include" LDFLAGS="-dead_strip -L/usr/X11R6/ > lib -L/usr/local/lib -L/sw/lib/ncurses -L/sw/lib/freetype219/lib -L/ > sw/lib/pango-ft219/lib -L/sw/lib" > > checking build system type... powerpc-apple-darwin8.6.0 > checking host system type... powerpc-apple-darwin8.6.0 > checking for gcc... gcc-3.3 > > Mac OS X 10.4.6 PPC Exactly same problem here. -- Leon ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs crash (hang, CPU 100%) if change internal-border-width
> Cc: emacs-pretest-bug@gnu.org, [EMAIL PROTECTED] > From: [EMAIL PROTECTED] (Kim F. Storm) > Date: Sun, 14 May 2006 12:54:27 +0200 > > > I can confirm that Emacs no longer hangs like Drew described, on > > MS-Windows as well, but the display is GL! What kind of frame > > do you see on X after typing this command? > > > Mine is UGLY too (on X) -- but only as ugly as you would expect for an > internal border width of 50 pixels ;-) Then I guess we can regard this as ``fixed'' on all supported displays. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: add info about safe-local-variable to describe-variable
On Sun, May 14 2006, Johan Bockgård wrote: > Reiner Steib <[EMAIL PROTECTED]> writes: > >> Emacs 21 doesn't look at the safe-local-variable property at all. > > It does. Thanks for the correction. If `allout.el' wants to be compatible with Emacs 21, also `string-or-null-p' shouldn't be used. Or `booleanp' and `string-or-null-p' might be conditionally, e.g.: (put 'TeX-PDF-mode 'safe-local-variable (if (fboundp 'booleanp) 'booleanp '(lambda (x) (memq x '(nil t) Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Crash in foreach_window_1 (delete-frame)
I had this crash the other day. I had a frame with a Completions
buffer (lower window in 2-window config.) open, and wanted to delete
the frame.
Can't reproduce, but maybe someone can tell from looking at the stack
trace below.
This is a Carbon port (CVS 13 May 06) build with a number of patches
- none of them to delete-frame though. I thought I'd point out what
line 6818 of window.c is in the build.
Is w->hchild corrupted?
Please ignore if this is not enough information.
foreach_window_1 (w, fn, user_data)
struct window *w;
int (* fn) P_ ((struct window *, void *));
void *user_data;
{
int cont;
for (cont = 1; w && cont;)
{
*** line 6818*** if (!NILP (w->hchild))
cont = foreach_window_1 (XWINDOW (w->hchild), fn, user_data);
else if (!NILP (w->vchild))
cont = foreach_window_1 (XWINDOW (w->vchild), fn, user_data);
else
cont = fn (w, user_data);
w = NILP (w->next) ? 0 : XWINDOW (w->next);
}
return cont;
}
Date/Time: 2006-05-13 16:39:12.453 +0100
OS Version: 10.4.6 (Build 8I127)
Report Version: 4
Command: Aquamacs Emacs
Path:/Applications/Aquamacs Emacs.app/Contents/MacOS/Aquamacs Emacs
Parent: WindowServer [78]
Version: Aquamacs 0.9.9, GNU Emacs 22 (1.2a)
PID:405
Thread: 0
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0x110bc0d0
Thread 0 Crashed:
0 org.gnu.AquamacsEmacs 0x0004f5d8 foreach_window_1 + 52
(window.c:6818)
1 org.gnu.AquamacsEmacs 0x0004f60c foreach_window_1 + 104
(window.c:6821)
2 org.gnu.AquamacsEmacs 0x0004f60c foreach_window_1 + 104
(window.c:6821)
3 org.gnu.AquamacsEmacs 0x0004566c
window_from_coordinates + 120 (window.c:949)
4 org.gnu.AquamacsEmacs 0x0001e3b0 remember_mouse_glyph +
60 (xdisp.c:2061)
5 org.gnu.AquamacsEmacs 0x0013f83c note_mouse_movement +
332 (macterm.c:4321)
6 org.gnu.AquamacsEmacs 0x0014780c XTread_socket + 2228
(macterm.c:10366)
7 org.gnu.AquamacsEmacs 0x00085dc4 read_avail_input + 140
(keyboard.c:6751)
8 org.gnu.AquamacsEmacs 0x00085fbc handle_async_input +
48 (keyboard.c:6898)
9 org.gnu.AquamacsEmacs 0x000f175c Fdelq + 280 (fns.c:1724)
10 org.gnu.AquamacsEmacs 0x00015ab0 Fdelete_frame + 884
(frame.c:1284)
11 org.gnu.AquamacsEmacs 0x000e9860 Feval + 1072 (eval.c:
2246)
12 org.gnu.AquamacsEmacs 0x000e65c0 Fif + 72 (eval.c:381)
13 org.gnu.AquamacsEmacs 0x000e9848 Feval + 1048 (eval.c:
2243)
14 org.gnu.AquamacsEmacs 0x000e66b8 Fprogn + 60 (eval.c:433)
15 org.gnu.AquamacsEmacs 0x000eac50 funcall_lambda + 740
(eval.c:3082)
16 org.gnu.AquamacsEmacs 0x000ea900 apply_lambda + 252
(eval.c:3014)
17 org.gnu.AquamacsEmacs 0x000e9a00 Feval + 1488 (eval.c:
2300)
18 org.gnu.AquamacsEmacs 0x000e65c0 Fif + 72 (eval.c:381)
19 org.gnu.AquamacsEmacs 0x000e9848 Feval + 1048 (eval.c:
2243)
20 org.gnu.AquamacsEmacs 0x000e819c
internal_lisp_condition_case + 524 (eval.c:1420)
21 org.gnu.AquamacsEmacs 0x000e7f7c Fcondition_case + 76
(eval.c:1360)
22 org.gnu.AquamacsEmacs 0x000e9848 Feval + 1048 (eval.c:
2243)
23 org.gnu.AquamacsEmacs 0x000e66b8 Fprogn + 60 (eval.c:433)
24 org.gnu.AquamacsEmacs 0x000e9848 Feval + 1048 (eval.c:
2243)
25 org.gnu.AquamacsEmacs 0x000e65c0 Fif + 72 (eval.c:381)
26 org.gnu.AquamacsEmacs 0x000e9848 Feval + 1048 (eval.c:
2243)
27 org.gnu.AquamacsEmacs 0x000e66b8 Fprogn + 60 (eval.c:433)
28 org.gnu.AquamacsEmacs 0x000e7844 Flet + 556 (eval.c:1054)
29 org.gnu.AquamacsEmacs 0x000e9848 Feval + 1048 (eval.c:
2243)
30 org.gnu.AquamacsEmacs 0x000e66b8 Fprogn + 60 (eval.c:433)
31 org.gnu.AquamacsEmacs 0x000eac50 funcall_lambda + 740
(eval.c:3082)
32 org.gnu.AquamacsEmacs 0x000ea900 apply_lambda + 252
(eval.c:3014)
33 org.gnu.AquamacsEmacs 0x000e9a00 Feval + 1488 (eval.c:
2300)
34 org.gnu.AquamacsEmacs 0x000e65c0 Fif + 72 (eval.c:381)
35 org.gnu.AquamacsEmacs 0x000e9848 Feval + 1048 (eval.c:
2243)
36 org.gnu.AquamacsEmacs 0x000e66b8 Fprogn + 60 (eval.c:433)
37 org.gnu.AquamacsEmacs 0x000eac50 funcall_lambda + 740
(eval.c:3082)
38 org.gnu.AquamacsEmacs 0x000ea750 Ffuncall + 1200
(eval.c:2957)
39 org.gnu.AquamacsEmacs 0x000ea13c call1 + 40 (eval.c:2687)
40 org.gnu.AquamacsEmacs 0x000f49a8 mapcar1 + 560 (fns.c:
3143)
41 org.gnu.AquamacsEmacs 0x000f4ca4 Fmapc + 52 (fns.c:3231)
42 org.gnu.AquamacsEmacs 0x000e9860 Feval + 1072 (eval.c:
2246)
43 org.gnu.AquamacsEmacs 0x000e66b8 Fprogn + 60 (eval.c:433)
44 org.gnu.AquamacsEmacs
Re: Emacs crash (hang, CPU 100%) if change internal-border-width
Eli Zaretskii <[EMAIL PROTECTED]> writes: >> From: [EMAIL PROTECTED] (Kim F. Storm) >> Date: Sun, 14 May 2006 02:34:51 +0200 >> Cc: Emacs-Pretest-Bug >> >> "Drew Adams" <[EMAIL PROTECTED]> writes: >> >> > emacs -Q >> > >> > M-: (modify-frame-parameters (selected-frame) '((internal-border-width . >> > 50))) >> > >> > Frame turns all white, CPU goes to 100%, Emacs is unresponsive, need >> > to kill it externally. >> >> I believe that I've already fixed this with the following change: >> >> 2006-05-11 Kim F. Storm <[EMAIL PROTECTED]> >> >> * xdisp.c (redisplay_tool_bar): Handle large tool-bar-border values. > > For some value of ``fixed'' ;-) > > I can confirm that Emacs no longer hangs like Drew described, on > MS-Windows as well, but the display is GL! What kind of frame > do you see on X after typing this command? Mine is UGLY too (on X) -- but only as ugly as you would expect for an internal border width of 50 pixels ;-) -- Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
