Re: [PATCH] xmine.
26 years, 7 months
Hrvoje Niksic
Hrvoje Niksic
Jens Lautenbacher <jens(a)tellux.de> writes:
> - (if (and (eq window-system 'x) (featurep 'xpm))
> + (if (and window-system (featurep 'xpm))
^^^^^^^^^^^^^
AAAAAAAAAAaaaaaaaaaaaaaaaarghhhhh!
Please, *please*, pretty pretty please with sugar, chocolate sprinkles,
ice-cream and a cherry on top, make this `(console-on-window-system-p)'.
The `window-system' variable is evil and obsolete. How do we expect
our users to stop using it if we keep using it ourselves? :-(
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Then... his face does a complete change of expression. It goes from
a "Vengeance is mine" expression, to a "What the fuck" blank look.
- 1 participants
- 0 comments
De-GIFfing (was Re: beta38-pre3 has been uploaded)
26 years, 7 months
William M. Perry
William M. Perry
SL Baur <steve(a)xemacs.org> writes:
> This XEmacs has been de-GIFfed. If you are going to try the patch (based
> on vanilla beta37, reverse all patches to beta37 before attempting to
> apply it), you will need to download the file in beta/testing
> xemacs-gif-to-png.tar, then do from the top-level XEmacs source
> directory:
[...]
> -- All GIFs in core distribution converted to PNGs -- screw Unisys
This is all well and good for XEmacs' internal stuff to be all PNG, but
this is going to essentially cripple Emacs/W3 for displaying images. And
VM for displaying attached GIFs, as well as TM, etc. Could we _please_
investigate either crippling GIFlib so that it cannot _create_ GIFs, but
can still decode them, or using the bogus-encoding that Ghostscript uses?
-Bill P.
- 2 participants
- 1 comments
Sort minor mode menu
26 years, 7 months
SL Baur
SL Baur
The minor mode menu is chaotic. The following patch sorts the menu
alphabetically.
1998-05-01 SL Baur <steve(a)altair.xemacs.org>
* modeline.el (modeline-minor-mode-menu): Alphabetize the minor
mode menu.
Index: lisp/modeline.el
===================================================================
RCS file: /usr/local/xemacs/xemacs-20.0/lisp/modeline.el,v
retrieving revision 1.13
diff -u -r1.13 modeline.el
--- lisp/modeline.el 1998/05/01 01:10:51 1.13
+++ lisp/modeline.el 1998/05/01 22:07:26
＠＠ -419,7 +419,8 ＠＠
(popup-menu-and-execute-in-window
(cons
"Minor Mode Toggles"
- (delq nil (mapcar
+ (sort
+ (delq nil (mapcar
#'(lambda (x)
(let* ((toggle-sym (car x))
(toggle-fun (or (get toggle-sym
＠＠ -446,7 +447,9 ＠＠
:style 'toggle
:selected (and (boundp toggle-sym)
toggle-sym)))))
- minor-mode-alist)))
+ minor-mode-alist))
+ (lambda (e1 e2)
+ (string< (aref e1 0) (aref e2 0)))))
event)))
(defvar modeline-minor-mode-map (make-sparse-keymap 'modeline-minor-mode-map)
- 1 participants
- 0 comments
Re: [Failure] 21.0 "Repartida-pre1" XEmacs Lucid (beta38) on sparc-sun-solaris2.6
26 years, 7 months
Gunnar Evermann
Gunnar Evermann
Martin Buchholz <martin(a)xemacs.org> writes:
> >>>>> "Gunnar" == Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes:
>
>
> Gunnar> in FPrin1: (dbx) pobj object
> Gunnar> warning: subscript out of range
> Gunnar> Unknown Lisp Object type
> Gunnar> object = 6067492
>
> This is a sign that a Lisp_Object has been corrupted or was never
> initialized. These bugs are very hard to track down. If the bug is
> completely reproducible, down to the memory addresses involved, you
> can put a debugger watchpoint on the actual memory locations that are
> being corrupted, and track it down that way.
OK, I tried that. First of all it is reproducible down to
address. Aparently it is related to a GC triggered during some
XPM-related stuff. This might also explain why this bug doesn't show
up in xemacs -nw. btw this b38-pre2.
If you need further info, drop me a mail.
Gunnar
I'm not sure wheter the size is right, but maybe this helps:
(dbx) stop modify 6067492, sizeof(Lisp_Object)
(2) stop modify 6067492, sizeof(Lisp_Object )
(dbx)
(dbx) run
Running: xemacs
(process id 13833)
watchpoint 6067492 (0x5c9524[4]) at line 456 in file "alloc.c"
456 (*ptr4++) = 0xDEADBEEF;
(dbx)
(dbx) where
=>[1] deadbeef_memory(ptr = 0x5c9524, size = 16U), line 456 in "alloc.c"
[2] sweep_strings(), line 4185 in "alloc.c"
[3] gc_sweep(), line 4254 in "alloc.c"
[4] garbage_collect_1(), line 4557 in "alloc.c"
[5] Feval(form = 5610556), line 2919 in "eval.c"
[6] evaluate_xpm_color_symbols(), line 1585 in "glyphs.c"
[7] x_xpm_normalize(inst = 7683168, console_type = 6096420), line 1410 in "glyphs-x.c"
[8] xpm_normalize(inst = 7683168, console_type = 6096420), line 1601 in "glyphs.c"
[9] normalize_image_instantiator(instantiator = 7683168, contype = 6096420, dest_mask = 95), line 477 in "glyphs.c"
[10] primitive_funcall(fn = 0x2210b8 = &`xemacs`glyphs.c`normalize_image_instantiator(Lisp_Object instantiator, Lisp_Object contype, Lisp_Object dest_mask), nargs = 3, args = 0xefffaeec), line 2862 in "eval.c"
[11] call_with_suspended_errors_1(opaque_arg = 5974592), line 2061 in "eval.c"
[12] internal_catch(tag = 5974720, func = 0xfd668 = &`xemacs`eval.c`call_with_suspended_errors_1(Lisp_Object opaque_arg), arg = 5974592, threw = 0xefffaed4), line 1328 in "eval.c"
[13] call_with_suspended_errors(fun = 0x2210b8 = &`xemacs`glyphs.c`normalize_image_instantiator(Lisp_Object instantiator, Lisp_Object contype, Lisp_Object dest_mask), retval = 5992452, class = 5992452, errb = RECORD, nargs = 3, ...), line 2169 in "eval.c"
[14] image_going_to_add(specifier = 7640448, locale = 6094400, tag_set = 5992452, instantiator = 7638484), line 1911 in "glyphs.c"
[15] build_up_processed_list(specifier = 7640448, locale = 6094400, inst_list = 7685576), line 1600 in "specifier.c"
[16] specifier_add_spec(specifier = 7640448, locale = 6094400, inst_list = 7685576, add_meth = SPEC_REMOVE_TAG_SET_PREPEND), line 1641 in "specifier.c"
[17] Fadd_spec_list_to_specifier(specifier = 7640448, spec_list = 7685600, how_to_add = 5992452), line 1912 in "specifier.c"
[18] funcall_recording_as(recorded_as = 6109552, nargs = 3, args = 0xefffb500), line 3197 in "eval.c"
[19] Ffuncall(nargs = 4, args = 0xefffb500), line 3238 in "eval.c"
[20] Fbyte_code(bytestr = 5112944, vector = 5113080, maxdepth = 17), line 416 in "bytecode.c"
[21] funcall_lambda(fun = 5113252, nargs = 5, arg_vector = 0xefffb9a4), line 3599 in "eval.c"
[22] funcall_recording_as(recorded_as = 6091848, nargs = 5, args = 0xefffb9a0), line 3200 in "eval.c"
[23] Ffuncall(nargs = 6, args = 0xefffb9a0), line 3238 in "eval.c"
[24] Fbyte_code(bytestr = 5140216, vector = 5140300, maxdepth = 13), line 416 in "bytecode.c"
[25] funcall_lambda(fun = 5140368, nargs = 6, arg_vector = 0xefffbd5c), line 3599 in "eval.c"
[26] funcall_recording_as(recorded_as = 6497828, nargs = 6, args = 0xefffbd58), line 3200 in "eval.c"
[27] Ffuncall(nargs = 7, args = 0xefffbd58), line 3238 in "eval.c"
[28] Fbyte_code(bytestr = 5141300, vector = 5141328, maxdepth = 15), line 416 in "bytecode.c"
[29] funcall_lambda(fun = 5141372, nargs = 2, arg_vector = 0xefffc12c), line 3599 in "eval.c"
[30] funcall_recording_as(recorded_as = 6091876, nargs = 2, args = 0xefffc128), line 3200 in "eval.c"
[31] Ffuncall(nargs = 3, args = 0xefffc128), line 3238 in "eval.c"
[32] Fbyte_code(bytestr = 5142472, vector = 5142504, maxdepth = 7), line 416 in "bytecode.c"
[33] funcall_lambda(fun = 5142540, nargs = 1, arg_vector = 0xefffc6c0), line 3599 in "eval.c"
[34] funcall_recording_as(recorded_as = 6468792, nargs = 1, args = 0xefffc6bc), line 3200 in "eval.c"
[35] Ffuncall(nargs = 2, args = 0xefffc6bc), line 3238 in "eval.c"
[36] Fbyte_code(bytestr = 5519576, vector = 5519724, maxdepth = 15), line 416 in "bytecode.c"
[37] funcall_lambda(fun = 5519792, nargs = 6, arg_vector = 0xefffcb08), line 3599 in "eval.c"
[38] funcall_recording_as(recorded_as = 6963172, nargs = 6, args = 0xefffcb04), line 3200 in "eval.c"
[39] Ffuncall(nargs = 7, args = 0xefffcb04), line 3238 in "eval.c"
[40] Fbyte_code(bytestr = 5647640, vector = 5647704, maxdepth = 19), line 416 in "bytecode.c"
[41] funcall_lambda(fun = 5647956, nargs = 1, arg_vector = 0xefffcea4), line 3599 in "eval.c"
[42] funcall_recording_as(recorded_as = 5647956, nargs = 1, args = 0xefffcea0), line 3200 in "eval.c"
[43] Ffuncall(nargs = 2, args = 0xefffcea0), line 3238 in "eval.c"
[44] call1(fn = 5647956, arg0 = 6938868), line 3912 in "eval.c"
[45] mapcar1(leni = 17, vals = 0xefffcfb0, fn = 5647956, seq = 6942416), line 3235 in "fns.c"
[46] Fmapcar(fn = 5647956, seq = 6942416), line 3285 in "fns.c"
[47] funcall_recording_as(recorded_as = 6089884, nargs = 2, args = 0xefffd1c8), line 3197 in "eval.c"
[48] Ffuncall(nargs = 3, args = 0xefffd1c8), line 3238 in "eval.c"
[49] Fbyte_code(bytestr = 5648020, vector = 5648052, maxdepth = 7), line 416 in "bytecode.c"
[50] funcall_lambda(fun = 5648092, nargs = 1, arg_vector = 0xefffd574), line 3599 in "eval.c"
[51] funcall_recording_as(recorded_as = 6991172, nargs = 1, args = 0xefffd570), line 3200 in "eval.c"
[52] Ffuncall(nargs = 2, args = 0xefffd570), line 3238 in "eval.c"
[53] Fbyte_code(bytestr = 5647480, vector = 5647508, maxdepth = 7), line 416 in "bytecode.c"
[54] funcall_lambda(fun = 5647544, nargs = 0, arg_vector = 0xefffda8c), line 3599 in "eval.c"
[55] funcall_recording_as(recorded_as = 6988508, nargs = 0, args = 0xefffda88), line 3200 in "eval.c"
[56] Ffuncall(nargs = 1, args = 0xefffda88), line 3238 in "eval.c"
[57] Fbyte_code(bytestr = 5641072, vector = 5641192, maxdepth = 9), line 416 in "bytecode.c"
[58] funcall_lambda(fun = 5641372, nargs = 0, arg_vector = 0xefffde68), line 3599 in "eval.c"
[59] funcall_recording_as(recorded_as = 6116088, nargs = 0, args = 0xefffde64), line 3200 in "eval.c"
[60] Ffuncall(nargs = 1, args = 0xefffde64), line 3238 in "eval.c"
[61] call0(fn = 6116088), line 3897 in "eval.c"
[62] x_finish_init_device(d = 0x5e8800, props = 5992452), line 595 in "device-x.c"
[63] Fmake_device(type = 6096420, connection = 5992452, props = 5992452), line 580 in "device.c"
[64] funcall_recording_as(recorded_as = 6075240, nargs = 2, args = 0xefffe0d8), line 3193 in "eval.c"
[65] Ffuncall(nargs = 3, args = 0xefffe0d8), line 3238 in "eval.c"
[66] Fbyte_code(bytestr = 5094848, vector = 5094872, maxdepth = 7), line 416 in "bytecode.c"
[67] funcall_lambda(fun = 5094900, nargs = 1, arg_vector = 0xefffe4f4), line 3599 in "eval.c"
[68] funcall_recording_as(recorded_as = 6449800, nargs = 1, args = 0xefffe4f0), line 3200 in "eval.c"
[69] Ffuncall(nargs = 2, args = 0xefffe4f0), line 3238 in "eval.c"
[70] Fbyte_code(bytestr = 5640508, vector = 5640564, maxdepth = 5), line 416 in "bytecode.c"
[71] funcall_lambda(fun = 5640660, nargs = 0, arg_vector = 0xefffe9f4), line 3599 in "eval.c"
[72] funcall_recording_as(recorded_as = 6988424, nargs = 0, args = 0xefffe9f0), line 3200 in "eval.c"
[73] Ffuncall(nargs = 1, args = 0xefffe9f0), line 3238 in "eval.c"
[74] Fbyte_code(bytestr = 5298512, vector = 5298628, maxdepth = 9), line 416 in "bytecode.c"
[75] funcall_lambda(fun = 5298848, nargs = 0, arg_vector = 0xeffff01c), line 3599 in "eval.c"
[76] funcall_recording_as(recorded_as = 6815296, nargs = 0, args = 0xeffff018), line 3200 in "eval.c"
[77] Ffuncall(nargs = 1, args = 0xeffff018), line 3238 in "eval.c"
[78] Fbyte_code(bytestr = 5296360, vector = 5296548, maxdepth = 13), line 416 in "bytecode.c"
[79] funcall_lambda(fun = 5297088, nargs = 0, arg_vector = 0xeffff278), line 3599 in "eval.c"
[80] apply_lambda(fun = 5297088, numargs = 0, unevalled_args = 5992452), line 3501 in "eval.c"
[81] Feval(form = 6275124), line 3067 in "eval.c"
[82] condition_case_1(handlers = 5992564, bfun = 0x100650 = &Feval(Lisp_Object form), barg = 6275124, hfun = 0xa5710 = &cmd_error(), harg = 5992452), line 1653 in "eval.c"
[83] top_level_1(dummy = 5992452), line 206 in "cmdloop.c"
[84] internal_catch(tag = 6070780, func = 0xa57f0 = &`xemacs`cmdloop.c`top_level_1(Lisp_Object dummy), arg = 5992452, threw = (nil)), line 1328 in "eval.c"
[85] initial_command_loop(load_me = 5992452), line 285 in "cmdloop.c"
[86] xemacs_21_0_b38_sparc_sun_solaris2_6(argc = 1, argv = 0xeffff7cc, envp = 0xeffff7d4, restart = 0), line 1673 in "emacs.c"
[87] main(argc = 1, argv = 0xeffff7cc, envp = 0xeffff7d4), line 2090 in "emacs.c"
(dbx)
(dbx) cont
watchpoint 6067492 (0x5c9524[4]) at line 4185 in file "alloc.c"
4185 SWEEP_FIXED_TYPE_BLOCK (string, struct Lisp_String);
(dbx)
(dbx) where
=>[1] sweep_strings(), line 4185 in "alloc.c"
[2] gc_sweep(), line 4254 in "alloc.c"
[3] garbage_collect_1(), line 4557 in "alloc.c"
[4] Feval(form = 5610556), line 2919 in "eval.c"
[5] evaluate_xpm_color_symbols(), line 1585 in "glyphs.c"
[6] x_xpm_normalize(inst = 7683168, console_type = 6096420), line 1410 in "glyphs-x.c"
[7] xpm_normalize(inst = 7683168, console_type = 6096420), line 1601 in "glyphs.c"
[8] normalize_image_instantiator(instantiator = 7683168, contype = 6096420, dest_mask = 95), line 477 in "glyphs.c"
[9] primitive_funcall(fn = 0x2210b8 = &`xemacs`glyphs.c`normalize_image_instantiator(Lisp_Object instantiator, Lisp_Object contype, Lisp_Object dest_mask), nargs = 3, args = 0xefffaeec), line 2862 in "eval.c"
[10] call_with_suspended_errors_1(opaque_arg = 5974592), line 2061 in "eval.c"
[11] internal_catch(tag = 5974720, func = 0xfd668 = &`xemacs`eval.c`call_with_suspended_errors_1(Lisp_Object opaque_arg), arg = 5974592, threw = 0xefffaed4), line 1328 in "eval.c"
[12] call_with_suspended_errors(fun = 0x2210b8 = &`xemacs`glyphs.c`normalize_image_instantiator(Lisp_Object instantiator, Lisp_Object contype, Lisp_Object dest_mask), retval = 5992452, class = 5992452, errb = RECORD, nargs = 3, ...), line 2169 in "eval.c"
[13] image_going_to_add(specifier = 7640448, locale = 6094400, tag_set = 5992452, instantiator = 7638484), line 1911 in "glyphs.c"
[14] build_up_processed_list(specifier = 7640448, locale = 6094400, inst_list = 7685576), line 1600 in "specifier.c"
[15] specifier_add_spec(specifier = 7640448, locale = 6094400, inst_list = 7685576, add_meth = SPEC_REMOVE_TAG_SET_PREPEND), line 1641 in "specifier.c"
[16] Fadd_spec_list_to_specifier(specifier = 7640448, spec_list = 7685600, how_to_add = 5992452), line 1912 in "specifier.c"
[17] funcall_recording_as(recorded_as = 6109552, nargs = 3, args = 0xefffb500), line 3197 in "eval.c"
[18] Ffuncall(nargs = 4, args = 0xefffb500), line 3238 in "eval.c"
[19] Fbyte_code(bytestr = 5112944, vector = 5113080, maxdepth = 17), line 416 in "bytecode.c"
[20] funcall_lambda(fun = 5113252, nargs = 5, arg_vector = 0xefffb9a4), line 3599 in "eval.c"
[21] funcall_recording_as(recorded_as = 6091848, nargs = 5, args = 0xefffb9a0), line 3200 in "eval.c"
[22] Ffuncall(nargs = 6, args = 0xefffb9a0), line 3238 in "eval.c"
[23] Fbyte_code(bytestr = 5140216, vector = 5140300, maxdepth = 13), line 416 in "bytecode.c"
[24] funcall_lambda(fun = 5140368, nargs = 6, arg_vector = 0xefffbd5c), line 3599 in "eval.c"
[25] funcall_recording_as(recorded_as = 6497828, nargs = 6, args = 0xefffbd58), line 3200 in "eval.c"
[26] Ffuncall(nargs = 7, args = 0xefffbd58), line 3238 in "eval.c"
[27] Fbyte_code(bytestr = 5141300, vector = 5141328, maxdepth = 15), line 416 in "bytecode.c"
[28] funcall_lambda(fun = 5141372, nargs = 2, arg_vector = 0xefffc12c), line 3599 in "eval.c"
[29] funcall_recording_as(recorded_as = 6091876, nargs = 2, args = 0xefffc128), line 3200 in "eval.c"
[30] Ffuncall(nargs = 3, args = 0xefffc128), line 3238 in "eval.c"
[31] Fbyte_code(bytestr = 5142472, vector = 5142504, maxdepth = 7), line 416 in "bytecode.c"
[32] funcall_lambda(fun = 5142540, nargs = 1, arg_vector = 0xefffc6c0), line 3599 in "eval.c"
[33] funcall_recording_as(recorded_as = 6468792, nargs = 1, args = 0xefffc6bc), line 3200 in "eval.c"
[34] Ffuncall(nargs = 2, args = 0xefffc6bc), line 3238 in "eval.c"
[35] Fbyte_code(bytestr = 5519576, vector = 5519724, maxdepth = 15), line 416 in "bytecode.c"
[36] funcall_lambda(fun = 5519792, nargs = 6, arg_vector = 0xefffcb08), line 3599 in "eval.c"
[37] funcall_recording_as(recorded_as = 6963172, nargs = 6, args = 0xefffcb04), line 3200 in "eval.c"
[38] Ffuncall(nargs = 7, args = 0xefffcb04), line 3238 in "eval.c"
[39] Fbyte_code(bytestr = 5647640, vector = 5647704, maxdepth = 19), line 416 in "bytecode.c"
[40] funcall_lambda(fun = 5647956, nargs = 1, arg_vector = 0xefffcea4), line 3599 in "eval.c"
[41] funcall_recording_as(recorded_as = 5647956, nargs = 1, args = 0xefffcea0), line 3200 in "eval.c"
[42] Ffuncall(nargs = 2, args = 0xefffcea0), line 3238 in "eval.c"
[43] call1(fn = 5647956, arg0 = 6938868), line 3912 in "eval.c"
[44] mapcar1(leni = 17, vals = 0xefffcfb0, fn = 5647956, seq = 6942416), line 3235 in "fns.c"
[45] Fmapcar(fn = 5647956, seq = 6942416), line 3285 in "fns.c"
[46] funcall_recording_as(recorded_as = 6089884, nargs = 2, args = 0xefffd1c8), line 3197 in "eval.c"
[47] Ffuncall(nargs = 3, args = 0xefffd1c8), line 3238 in "eval.c"
[48] Fbyte_code(bytestr = 5648020, vector = 5648052, maxdepth = 7), line 416 in "bytecode.c"
[49] funcall_lambda(fun = 5648092, nargs = 1, arg_vector = 0xefffd574), line 3599 in "eval.c"
[50] funcall_recording_as(recorded_as = 6991172, nargs = 1, args = 0xefffd570), line 3200 in "eval.c"
[51] Ffuncall(nargs = 2, args = 0xefffd570), line 3238 in "eval.c"
[52] Fbyte_code(bytestr = 5647480, vector = 5647508, maxdepth = 7), line 416 in "bytecode.c"
[53] funcall_lambda(fun = 5647544, nargs = 0, arg_vector = 0xefffda8c), line 3599 in "eval.c"
[54] funcall_recording_as(recorded_as = 6988508, nargs = 0, args = 0xefffda88), line 3200 in "eval.c"
[55] Ffuncall(nargs = 1, args = 0xefffda88), line 3238 in "eval.c"
[56] Fbyte_code(bytestr = 5641072, vector = 5641192, maxdepth = 9), line 416 in "bytecode.c"
[57] funcall_lambda(fun = 5641372, nargs = 0, arg_vector = 0xefffde68), line 3599 in "eval.c"
[58] funcall_recording_as(recorded_as = 6116088, nargs = 0, args = 0xefffde64), line 3200 in "eval.c"
[59] Ffuncall(nargs = 1, args = 0xefffde64), line 3238 in "eval.c"
[60] call0(fn = 6116088), line 3897 in "eval.c"
[61] x_finish_init_device(d = 0x5e8800, props = 5992452), line 595 in "device-x.c"
[62] Fmake_device(type = 6096420, connection = 5992452, props = 5992452), line 580 in "device.c"
[63] funcall_recording_as(recorded_as = 6075240, nargs = 2, args = 0xefffe0d8), line 3193 in "eval.c"
[64] Ffuncall(nargs = 3, args = 0xefffe0d8), line 3238 in "eval.c"
[65] Fbyte_code(bytestr = 5094848, vector = 5094872, maxdepth = 7), line 416 in "bytecode.c"
[66] funcall_lambda(fun = 5094900, nargs = 1, arg_vector = 0xefffe4f4), line 3599 in "eval.c"
[67] funcall_recording_as(recorded_as = 6449800, nargs = 1, args = 0xefffe4f0), line 3200 in "eval.c"
[68] Ffuncall(nargs = 2, args = 0xefffe4f0), line 3238 in "eval.c"
[69] Fbyte_code(bytestr = 5640508, vector = 5640564, maxdepth = 5), line 416 in "bytecode.c"
[70] funcall_lambda(fun = 5640660, nargs = 0, arg_vector = 0xefffe9f4), line 3599 in "eval.c"
[71] funcall_recording_as(recorded_as = 6988424, nargs = 0, args = 0xefffe9f0), line 3200 in "eval.c"
[72] Ffuncall(nargs = 1, args = 0xefffe9f0), line 3238 in "eval.c"
[73] Fbyte_code(bytestr = 5298512, vector = 5298628, maxdepth = 9), line 416 in "bytecode.c"
[74] funcall_lambda(fun = 5298848, nargs = 0, arg_vector = 0xeffff01c), line 3599 in "eval.c"
[75] funcall_recording_as(recorded_as = 6815296, nargs = 0, args = 0xeffff018), line 3200 in "eval.c"
[76] Ffuncall(nargs = 1, args = 0xeffff018), line 3238 in "eval.c"
[77] Fbyte_code(bytestr = 5296360, vector = 5296548, maxdepth = 13), line 416 in "bytecode.c"
[78] funcall_lambda(fun = 5297088, nargs = 0, arg_vector = 0xeffff278), line 3599 in "eval.c"
[79] apply_lambda(fun = 5297088, numargs = 0, unevalled_args = 5992452), line 3501 in "eval.c"
[80] Feval(form = 6275124), line 3067 in "eval.c"
[81] condition_case_1(handlers = 5992564, bfun = 0x100650 = &Feval(Lisp_Object form), barg = 6275124, hfun = 0xa5710 = &`xemacs`cmdloop.c`cmd_error(Lisp_Object data, Lisp_Object dummy), harg = 5992452), line 1653 in "eval.c"
[82] top_level_1(dummy = 5992452), line 206 in "cmdloop.c"
[83] internal_catch(tag = 6070780, func = 0xa57f0 = &`xemacs`cmdloop.c`top_level_1(Lisp_Object dummy), arg = 5992452, threw = (nil)), line 1328 in "eval.c"
[84] initial_command_loop(load_me = 5992452), line 285 in "cmdloop.c"
[85] xemacs_21_0_b38_sparc_sun_solaris2_6(argc = 1, argv = 0xeffff7cc, envp = 0xeffff7d4, restart = 0), line 1673 in "emacs.c"
[86] main(argc = 1, argv = 0xeffff7cc, envp = 0xeffff7d4), line 2090 in "emacs.c"
(dbx)
(dbx) cont
signal ILL (illegal opcode) in (unknown) at 0x4b0360
0x004b0360: pure+0x597c: illtrap 0x4
Current function is print_internal
1203 (obj, printcharfun, escapeflag));
(dbx) pobj obj
dbx: warning: subscript out of range
Unknown Lisp Object type
obj = 6067492
(dbx)
- 2 participants
- 1 comments
Re: select-window focus problem [was: Re: minor compile.el bug]
26 years, 7 months
Hrvoje Niksic
Hrvoje Niksic
greg(a)alphatech.com (Greg Klanderman) writes:
> Hrvoje> Maybe `set-frame-focus' would be a better name.
>
> I can do this. I assume Ben meant a C primitive, not a lisp function
> using the same bind focus-follows-mouse and sit-for 0 hack.
Yup. From the outside, `set-frame-focus' would do what `select-frame'
used to do.
> This should be easy, and I will clean up those messy externs while
> I'm at it. Then I'll update the docs not to mention that
> abomination.
:-) Please do.
> BTW Hrvoje, thanks for cleaning up my docs patch.
> >> Also, do there exist forms save-selected-frame and
> >> with-selected-frame? If not, there should be.
> Hrvoje>
> Hrvoje> I can code and document these.
>
> OK. Ben do you intend these to just be macros using select-frame
> and unwind-protect?
(defmacro save-selected-frame (&rest body)
"Execute forms in BODY, then restore the selected frame.
The value returned is the value of the last form in BODY.
The frame selection is not accompanied by changes to the actual window
manager focus and is not affected by the value of `focus-follows-mouse'.
See also `with-selected-frame'."
(let ((old-frame (gensym "ssf")))
`(let ((,old-frame (selected-frame))
(focus-follows-mouse t))
(unwind-protect
(progn ,＠body)
(select-frame ,old-frame)))))
The macro binds `focus-follows-mouse' to t to avoid focus flicker even
if focus-follows-mouse is nil. There is a potential problem with code
within BODY that might want to check focus-follows-mouse, but I don't
think the problem is serious enough to be worth solving (it might be
solved by introducing an `overriding-focus-follows-mouse' or something
like that.)
Here is an implementation of `with-selected-frame':
(defmacro with-selected-frame (frame &rest body)
"Execute forms in BODY with FRAME as the selected frame.
The value returned is the value of the last form in BODY.
The frame selection is not accompanied by changes to the actual window
manager focus and is not affected by the value of `focus-follows-mouse'.
See also `with-selected-frame'."
`(save-selected-frame
(select-frame ,frame)
,＠body))
If you like these, I'll send out a patch. I'll also expand the news
entry to cover all this new stuff in some detail.
> >> Also, the default value of focus-follows-mouse should be set
> >> according to the window manager's focus policy. This might entail
> >> some special case code for particular window managers (each of which
> >> has their own protocol for obtaining this property), with a default
> >> value of nil under Unix and true under Windows.
> Hrvoje>
> Hrvoje> Why not the opposite -- nil under Windows, and true under Unix?
>
> OK, but I have no clue how to do these last two....
No problem, that code can be added later.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
- Now what did we learn from this?
- I learned what my liver looks like!
- 1 participants
- 0 comments
[PATCH] xmine.
26 years, 7 months
Jens Lautenbacher
Jens Lautenbacher
A very small patchlet incorporating some changes from Andy Piper and a
very little change by me enabling Zippy the Pinhead talking to you
(via balloon help over the tiles...)
jtl
Index: xmine.el
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs-packages/games/mine/xmine.el,v
retrieving revision 1.2
diff -u -r1.2 xmine.el
--- xmine.el 1998/04/05 10:29:09 1.2
+++ xmine.el 1998/05/02 06:18:25
＠＠ -44,7 +44,7 ＠＠
;;
;;; First of all we'll define the needed varibles.
-(defconst xmine-version-number "1.8" "XEmacs Mine version number.")
+(defconst xmine-version-number "1.9" "XEmacs Mine version number.")
(defconst xmine-version (format "XEmacs Mine v%s by Jens Lautenbacher © 1997"
xmine-version-number)
"Full XEmacs Mine version number.")
＠＠ -89,13 +89,13 ＠＠
(defvar xmine-pad-glyph
(make-glyph
- (if (and (eq window-system 'x) (featurep 'xpm))
+ (if (and window-system (featurep 'xpm))
(concat xmine-glyph-dir "pad.xpm")
" ")))
(defvar xmine-title-glyph
(make-glyph
- (if (and (eq window-system 'x) (featurep 'xpm))
+ (if (and window-system (featurep 'xpm))
(concat xmine-glyph-dir "splash.xpm")
"------------------ XEmacs XMine ------------------")))
＠＠ -144,7 +144,7 ＠＠
face (cadddr elem))
(set (intern var)
(make-glyph (if (and (not xmine-force-textual)
- (eq window-system 'x))
+ window-system)
(concat xmine-glyph-dir gif)
text)))
(if face
＠＠ -173,17 +173,15 ＠＠
:group 'xmine
:type 'integer)
-(defcustom xmine-balloon-list (list "What are you waiting for?"
- "Push me!"
- "Come on. Don't sleep."
+(defcustom xmine-balloon-list (list "Push Me!"
+ "Don't Sleep."
"Are you sure?"
- "Are you sleeping?"
- "Yes! Do it!"
- "I'm getting bored."
- "You will NEVER beat me.")
- "(Random) texts for the balloon-help property of the tiles"
+ "I'm getting bored.")
+ "(Random) texts for the balloon-help property of the tiles.
+This can be a list of strings or the symbol 'yow, in which case a random quote from
+Zippy The Pinhead will be used..."
:group 'xmine
- :type '(repeat (string)))
+ :type '(choice (repeat string) (const yow)))
(defcustom xmine-background "white"
"The background color of XMine's buffer.
＠＠ -334,7 +332,8 ＠＠
;;; object.
(defun xmine-balloon-text ()
- (nth (random (length xmine-balloon-list)) xmine-balloon-list))
+ (if (and (featurep 'yow) (eq xmine-balloon-list 'yow)) (yow)
+ (nth (random (length xmine-balloon-list)) xmine-balloon-list)))
(defun xmine-beep (&rest forget)
(beep))
＠＠ -695,7 +694,7 ＠＠
(format "Mines: %2d" xmine-number-of-mines)))
(goto-char (point-min))
(setq buffer-read-only 't)
- (if (eq window-system 'x)
+ (if window-system
(set-specifier (face-background 'default)
xmine-background xmine-buffer))
(set-specifier (face-background 'text-cursor)
- 1 participants
- 0 comments
Re: select-window focus problem [was: Re: minor compile.el bug]
26 years, 7 months
Greg Klanderman
Greg Klanderman
>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes:
Hrvoje>
Hrvoje> Ben Wing <ben(a)666.com> writes:
>> This business of binding focus follows mouse to nil and then calling
>> sit-for 0 is really really evil. I think the correct solution is to
>> make a new command focus-on-frame, somewhat analogous to
>> switch-to-buffer, that directly changes the window manager's focus.
Hrvoje>
Hrvoje> Maybe `set-frame-focus' would be a better name.
I can do this. I assume Ben meant a C primitive, not a lisp function
using the same bind focus-follows-mouse and sit-for 0 hack. This
should be easy, and I will clean up those messy externs while I'm at
it. Then I'll update the docs not to mention that abomination.
BTW Hrvoje, thanks for cleaning up my docs patch.
>> Also, do there exist forms save-selected-frame and
>> with-selected-frame? If not, there should be.
Hrvoje>
Hrvoje> I can code and document these.
OK. Ben do you intend these to just be macros using select-frame and
unwind-protect?
>> Also, focus-follows-mouse needs to be a console property instead of
>> just a simple variable.
Hrvoje>
Hrvoje> Oops! Yes, you are right. Should we make it a console method, and
Hrvoje> use the magic symbol stuff for compatibility? Or, should we make it a
Hrvoje> console-local variable, which is kludgier but creates less problems?
Hrvoje>
>> Also, the default value of focus-follows-mouse should be set
>> according to the window manager's focus policy. This might entail
>> some special case code for particular window managers (each of which
>> has their own protocol for obtaining this property), with a default
>> value of nil under Unix and true under Windows.
Hrvoje>
Hrvoje> Why not the opposite -- nil under Windows, and true under Unix?
OK, but I have no clue how to do these last two....
- 1 participants
- 0 comments
[jerry@cs.ucsb.edu (Jeremiah W. James)] [20.4] PROBLEMS file update
26 years, 7 months
Martin Buchholz
Martin Buchholz
fyi
------- Start of forwarded message -------
Date: Fri May 1 14:34:13 1998
From: jerry(a)cs.ucsb.edu (Jeremiah W. James)
Subject: [20.4] PROBLEMS file update
Topics:
[20.4] PROBLEMS file update
----------------------------------------------------------------------
Date: 24 Apr 1998 15:31:37 -0700
From: jerry(a)cs.ucsb.edu (Jeremiah W. James)
Subject: [20.4] PROBLEMS file update
Message-ID: <tpr7m4ec0mu.fsf(a)cs.ucsb.edu>
Content-Type: text/plain; charset=US-ASCII
In the PROBLEMS file that ships with XEmacs 20.4, there is the following
snippet:
** Motif dialog boxes lose on Irix.
Larry Auton <lda(a)control.att.com> writes:
Beware of not specifying
--with-dialogs=athena
if it builds with the motif dialogs [boom!] you're a dead man.
Did anyone bother to note what version of Irix Larry Auton was running
when he wrote that? I found this note *after* I had already built
XEmacs for both Irix 5.3 and Irix 6.2. I used the Motif dialogs on
both, and both of them are running just fine, thank you. If, as I
suspect, Mr. Auton was running a pre-5.3 version of Irix, that should be
noted in the PROBLEMS file.
- -
Jerry James
Email: jerry(a)cs.ucsb.edu
WWW: http://www.cs.ucsb.edu/~jerry/
------------------------------
End of forwardV-DV_j Digest
***************************
------- End of forwarded message -------
- 2 participants
- 1 comments
Re: [PATCH] Ghost specifiers
26 years, 7 months
Hrvoje Niksic
Hrvoje Niksic
"Kirill M. Katsnelson" <kkm(a)kis.ru> writes:
> A related topic: should not copy-tree copy strings and bit vectors
> as well?
Because that is not what that function is supposed to do. `copy-tree'
copies conses, and even the VECP argument is a hack (it doesn't exist
in Common Lisp). We could of course add a BIT-VECTORP argument, etc.
but I don't see how that would be useful.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Try to use "ad nauseam" at least once per flame. It doesn't mean
anything; but it gives that polished feel to your postings.
- 1 participants
- 0 comments
Re: [PATCH] Ghost specifiers
26 years, 7 months
Hrvoje Niksic
Hrvoje Niksic
wmperry(a)aventail.com (William M. Perry) writes:
> This is totally bogus behaviour. We should be returning a duplicate
> copy of the string to begin with.
You are missing the point. We already *are* returning copies of
things only to prevent their modification. This is generally bogus
and wasteful of memory.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Reporter: Mr Gandhi, what do you think of Western Civilization?
Gandhi: I think it would be a good idea.
- 1 participants
- 0 comments