April 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: CC Mode 5.22 (C); indentation weirdness 27 years

Barry A. Warsaw

AJK> The following code segment displays different indentation AJK> behavior for multi-line function calls. If first arg is a AJK> quoted string, next line's indentation is incorrect. If 1st AJK> arg is not a quoted string, everything is OK. I've changed the follow up to xemacs-beta instead of bug-gnu-emacs. I wonder if we should likewise change c-help-address temporarily during the XEmacs beta phase? Especially since I can't reproduce your problem under XEmacs 20.4 with our working version of CC Mode. I can't see why a string as the first arg would make the difference. What does C-c C-s on the continuation lines? Here's what I get using your settings. -------------------- snip snip -------------------- int test_Post (void) { printf ("hello\n", xx); /* ((arglist-cont-nonempty . 27)) */ fopen (x,y, z); /* ((arglist-cont-nonempty . 132)) */ fubar ("xyzzy", xxx); /* ((arglist-cont-nonempty . 231)) */ } -------------------- snip snip -------------------- Don't worry so much if your relpos's are off, but those lines should all be arglist-cont-nonempty. -Barry

1 participants
0 comments

request for #'= 27 years

David Bakhash

I'd like to request that the function `=' take &rest args so that it has the potential to check equality of more than two nos. thanks, dave

1 participants
0 comments

[PATCH] build b37pre1 under cygwin 27 years

Andy Piper

Unfortunately cygwin doesn't have InitCommonControlsEx at the moment to link against so pre1 fails. Here's the fix. andy Index: src/device-msw.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/src/device-msw.c,v retrieving revision 1.12 diff -u -r1.12 device-msw.c --- src/device-msw.c 1998/04/23 02:08:01 1.12 +++ src/device-msw.c 1998/04/23 17:42:05 ＠＠ -121,7 +121,11 ＠＠ #ifdef HAVE_TOOLBARS iccex.dwSize = sizeof (iccex); iccex.dwICC = ICC_BAR_CLASSES; +#ifdef __CYGWIN32__ + InitCommonControls (); +#else InitCommonControlsEx (&iccex); +#endif #endif }

2 participants
3 comments

[PATCH] tm broken vs. nil encoding 27 years

Didier Verna

Try to mime-insert a text file in a mail, then undo, and repeat-complex-command. tm will kindly give you the mime encapsulation back, but with an empty file inside. The following patch fixes it. BTW, this bring another question to my mind: this problem was due to repeating the command in a non interactive fashion. What if repeat-complex-command let us choose to repeat in a [non]interactive way ? I'm not sure it's worth it, but ... 1998-04-23 Didier Verna <verna(a)inf.enst.fr> * tm-edit.el (mime-editor/insert-file): if nil encoding, ask the user which one to use. --- lisp/tm/tm-edit.el.orig Thu Apr 23 14:27:28 1998 +++ lisp/tm/tm-edit.el Thu Apr 23 14:28:17 1998 ＠＠ -910,7 +910,7 ＠＠ (setq type (mime-prompt-for-type type) subtype (mime-prompt-for-subtype type subtype) )) - (if (or (interactive-p) verbose) + (if (or (interactive-p) verbose (null encoding)) (setq encoding (mime-prompt-for-encoding encoding)) ) (if (or (consp parameters) (stringp disposition-type))

1 participants
0 comments

[crash] assertion failed, file specifier.c, line 2451, abort() 27 years

Karl M. Hegbloom

opened, when I started an ediff session. I think that may be the common thing between this crash and the two others where it bombed when I opened up a speedbar frame. Both times there's a minibuffer only frame. Fatal error: assertion failed, file specifier.c, line 2451, abort() Fatal error (6). Your files have been auto-saved. Use `M-x recover-session' to recover them. Please report this bug by running the send-pr script included with XEmacs, or selecting `Send Bug Report' from the help menu. As a last resort send ordinary email to `crashes(a)xemacs.org'. *MAKE SURE* to include as much configuration information as possible; at the very least what OS and hardware you are running on, and hopefully also what compiler and compiler options the binary was compiled with, what options XEmacs was compiled with, whether you are using a prebuilt binary from ftp.xemacs.org or compiled XEmacs yourself for your system, etc. If at all possible, *please* try to obtain a C stack backtrace; it will help us immensely in determining what went wrong. To do this, locate the core file that was produced as a result of this crash (it's usually called `core' and is located in the directory in which you started XEmacs, or maybe in your home directory), and type gdb /usr/local/bin/xemacs core then type `where' when the debugger prompt comes up. (If you don't have GDB on your system, you might have DBX, or XDB, or SDB. A similar procedure should work for all of these. Ask your system administrator if you need more help.) Lisp backtrace follows: # bind (frame-being-created) make-frame(((name . "Ediff") (minibuffer) (user-position . t) (vertical-scroll-bars) (scrollbar-width . 0) (menu-bar-lines . 0) (auto-lower) (auto-raise . t) (top . 769) (left . 1025))) # (unwind-protect ...) # bind (window-min-height ctl-frame-iconified-p dont-iconify-ctl-frame deiconify-ctl-frame ctl-frame old-ctl-frame lines fheight fwidth adjusted-parameters designated-minibuffer-frame ctl-buffer) ediff-setup-control-frame(#<buffer "*Ediff Control Panel*"> #<x-frame "emacs" 0x1eb4>) # bind (done-C done-B done-A designated-minibuffer-frame wind-B-start wind-A-start use-same-frame orig-wind three-way-comparison split-window-function force-one-frame ctl-frame-exists-p frame-C frame-B frame-A wind-C wind-B wind-A window-min-height control-buf buf-C buf-B buf-A) ediff-setup-windows-multiframe-compare(#<buffer "control<guile/debian>"> #<buffer "control<guile-1.2/debian>"> nil #<buffer "*Ediff Control Panel*">) # bind (control-buf buf-C buf-B buf-A) ediff-setup-windows-multiframe(#<buffer "control<guile/debian>"> #<buffer "control<guile-1.2/debian>"> nil #<buffer "*Ediff Control Panel*">) # bind (control-buffer buffer-C buffer-B buffer-A) ediff-setup-windows(#<buffer "control<guile/debian>"> #<buffer "control<guile-1.2/debian>"> nil #<buffer "*Ediff Control Panel*">) # (unwind-protect ...) # bind (control-buffer control-buffer-name merge-buffer-file setup-parameters startup-hooks file-C buffer-C file-B buffer-B file-A buffer-A) ediff-setup(#<buffer "control<guile/debian>"> "/tmp/controlS8CXdh" #<buffer "control<guile-1.2/debian>"> "/tmp/controlS8CYdh" nil nil ((lambda nil (delete-file "/tmp/controlS8CXdh") (delete-file "/tmp/controlS8CYdh") (if ... ...))) ((ediff-job-name . ediff-buffers)) nil) # bind (file-C file-B file-A buf-C-file-name buf-C-is-alive buf-B-file-name buf-A-file-name merge-buffer-file job-name startup-hooks buf-C buf-B buf-A) ediff-buffers-internal("control<guile/debian>" "control<guile-1.2/debian>" nil nil ediff-buffers) # bind (job-name startup-hooks buffer-B buffer-A) #<compiled-function (buffer-A buffer-B &optional startup-hooks job-name) "...(14)" [job-name ediff-buffers ediff-buffers-internal buffer-A buffer-B nil startup-hooks] 6 ("/usr/local/src/XEmacs/Packages/lisp/ediff/ediff.elc" . 4830) (let (bf) (list ... ...))>("control<guile/debian>" "control<guile-1.2/debian>") call-interactively(ediff-buffers) # (condition-case ... . error) # (catch top-level ...) /usr/local/bin/xg: line 7: 12050 Aborted (core dumped) xemacs "$＠" There are few people more often in the wrong than those who cannot endure to be thought so. % gdb xemacs core GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16.patched (i586-debian-linux), Copyright 1996 Free Software Foundation, Inc... Core was generated by `xemacs'. Program terminated with signal 6, Aborted. find_solib: Can't read pathname for load map: Input/output error #0 0x402bb3b1 in ?? () from /lib/libc.so.6 (gdb) where #0 0x402bb3b1 in ?? () from /lib/libc.so.6 #1 0x8098940 in fatal_error_signal (sig=6) at emacs.c:255 #2 0xbfffaba4 in ?? () #3 0x402bc3ff in ?? () from /lib/libc.so.6 #4 0x809a566 in assert_failed (file=0x81651b1 "specifier.c", line=2451, expr=0x81656a4 "abort()") at emacs.c:2518 #5 0x811c9c0 in specifier_instance (specifier={gu = {type = Lisp_Type_Record, val = 34229602}, s = {bits = 0, val = 68459204}, u = {bits = 0, val = 68459204}, ui = 136918408, i = 136918408, v = 0x8293588, cv = 0x8293588}, matchspec={gu = {type = Lisp_Type_Record, val = 34138227}, s = {bits = 0, val = 68276454}, u = {bits = 0, val = 68276454}, ui = 136552908, i = 136552908, v = 0x823a1cc, cv = 0x823a1cc}, domain={gu = {type = Lisp_Type_Record, val = 37183628}, s = {bits = 0, val = 74367256}, u = {bits = 0, val = 74367256}, ui = 148734512, i = 148734512, v = 0x8dd8230, cv = 0x8dd8230}, errb=ERROR_ME_WARN, no_quit=0, no_fallback=0, depth={gu = { type = Lisp_Type_Int_Even, val = 0}, s = {bits = 1, val = 0}, u = { bits = 1, val = 0}, ui = 1, i = 1, v = 0x1, cv = 0x1}) at specifier.c:2451 #6 0x811d19d in recompute_one_cached_specifier_in_frame (specifier={gu = { type = Lisp_Type_Record, val = 34229602}, s = {bits = 0, val = 68459204}, u = {bits = 0, val = 68459204}, ui = 136918408, i = 136918408, v = 0x8293588, cv = 0x8293588}, f=0x8dd8230) ---Type <return> to continue, or q <return> to quit--- at specifier.c:2767 #7 0x811d237 in recompute_all_cached_specifiers_in_frame (f=0x8dd8230) at specifier.c:2806 #8 0x80da2e2 in Fmake_frame (props={gu = {type = Lisp_Type_Record, val = 38426407}, s = {bits = 0, val = 76852814}, u = {bits = 0, val = 76852814}, ui = 153705628, i = 153705628, v = 0x9295c9c, cv = 0x9295c9c}, device={gu = {type = Lisp_Type_Record, val = 34444014}, s = {bits = 0, val = 68888028}, u = {bits = 0, val = 68888028}, ui = 137776056, i = 137776056, v = 0x8364bb8, cv = 0x8364bb8}) at frame.c:480 #9 0x809efda in funcall_recording_as (recorded_as={gu = { type = Lisp_Type_Record, val = 34213640}, s = {bits = 0, val = 68427280}, u = {bits = 0, val = 68427280}, ui = 136854560, i = 136854560, v = 0x8283c20, cv = 0x8283c20}, nargs=1, args=0xbfffb990) at eval.c:3196 #10 0x809f372 in Ffuncall (nargs=2, args=0xbfffb990) at eval.c:3241 #11 0x80810be in Fbyte_code (bytestr={gu = {type = Lisp_Type_Record, val = 38292667}, s = {bits = 0, val = 76585334}, u = {bits = 0, val = 76585334}, ui = 153170668, i = 153170668, v = 0x92132ec, cv = 0x92132ec}, vector={gu = {type = Lisp_Type_Record, val = 38510670}, s = {bits = 0, val = 77021340}, u = {bits = 0, val = 77021340}, ui = 154042680, i = 154042680, v = 0x92e8138, cv = 0x92e8138}, maxdepth={ gu = {type = Lisp_Type_Int_Odd, val = 5}, s = {bits = 1, val = 11}, u = { ---Type <return> to continue, or q <return> to quit--- bits = 1, val = 11}, ui = 23, i = 23, v = 0x17, cv = 0x17}) at bytecode.c:416 #12 0x809fe40 in funcall_lambda (fun={gu = {type = Lisp_Type_Record, val = 38275270}, s = {bits = 0, val = 76550540}, u = {bits = 0, val = 76550540}, ui = 153101080, i = 153101080, v = 0x9202318, cv = 0x9202318}, nargs=2, arg_vector=0xbfffc904) at eval.c:3602 #13 0x809f316 in funcall_recording_as (recorded_as={gu = { type = Lisp_Type_Record, val = 38449868}, s = {bits = 0, val = 76899736}, u = {bits = 0, val = 76899736}, ui = 153799472, i = 153799472, v = 0x92acb30, cv = 0x92acb30}, nargs=2, args=0xbfffc900) at eval.c:3217 #14 0x809f372 in Ffuncall (nargs=3, args=0xbfffc900) at eval.c:3241 #15 0x80810be in Fbyte_code (bytestr={gu = {type = Lisp_Type_Record, val = 38334633}, s = {bits = 0, val = 76669266}, u = {bits = 0, val = 76669266}, ui = 153338532, i = 153338532, v = 0x923c2a4, cv = 0x923c2a4}, vector={gu = {type = Lisp_Type_Record, val = 37130382}, s = {bits = 0, val = 74260764}, u = {bits = 0, val = 74260764}, ui = 148521528, i = 148521528, v = 0x8da4238, cv = 0x8da4238}, maxdepth={ gu = {type = Lisp_Type_Int_Odd, val = 1}, s = {bits = 1, val = 3}, u = { bits = 1, val = 3}, ui = 7, i = 7, v = 0x7, cv = 0x7}) at bytecode.c:416 #16 0x809fe40 in funcall_lambda (fun={gu = {type = Lisp_Type_Record, val = 38275235}, s = {bits = 0, val = 76550470}, u = {bits = 0, ---Type <return> to continue, or q <return> to quit--- val = 76550470}, ui = 153100940, i = 153100940, v = 0x920228c, cv = 0x920228c}, nargs=4, arg_vector=0xbfffcc98) at eval.c:3602 #17 0x809f316 in funcall_recording_as (recorded_as={gu = { type = Lisp_Type_Record, val = 38447094}, s = {bits = 0, val = 76894188}, u = {bits = 0, val = 76894188}, ui = 153788376, i = 153788376, v = 0x92a9fd8, cv = 0x92a9fd8}, nargs=4, args=0xbfffcc94) at eval.c:3217 #18 0x809f372 in Ffuncall (nargs=5, args=0xbfffcc94) at eval.c:3241 #19 0x80810be in Fbyte_code (bytestr={gu = {type = Lisp_Type_Record, val = 38325913}, s = {bits = 0, val = 76651826}, u = {bits = 0, val = 76651826}, ui = 153303652, i = 153303652, v = 0x9233a64, cv = 0x9233a64}, vector={gu = {type = Lisp_Type_Record, val = 37151842}, s = {bits = 0, val = 74303684}, u = {bits = 0, val = 74303684}, ui = 148607368, i = 148607368, v = 0x8db9188, cv = 0x8db9188}, maxdepth={ gu = {type = Lisp_Type_Int_Odd, val = 2}, s = {bits = 1, val = 5}, u = { bits = 1, val = 5}, ui = 11, i = 11, v = 0xb, cv = 0xb}) at bytecode.c:416 #20 0x809fe40 in funcall_lambda (fun={gu = {type = Lisp_Type_Record, val = 38275221}, s = {bits = 0, val = 76550442}, u = {bits = 0, val = 76550442}, ui = 153100884, i = 153100884, v = 0x9202254, cv = 0x9202254}, nargs=4, arg_vector=0xbfffd08c) at eval.c:3602 #21 0x809f316 in funcall_recording_as (recorded_as={gu = { type = Lisp_Type_Record, val = 34440568}, s = {bits = 0, ---Type <return> to continue, or q <return> to quit--- val = 68881136}, u = {bits = 0, val = 68881136}, ui = 137762272, i = 137762272, v = 0x83615e0, cv = 0x83615e0}, nargs=4, args=0xbfffd088) at eval.c:3217 #22 0x809f372 in Ffuncall (nargs=5, args=0xbfffd088) at eval.c:3241 #23 0x80810be in Fbyte_code (bytestr={gu = {type = Lisp_Type_Record, val = 38286873}, s = {bits = 0, val = 76573746}, u = {bits = 0, val = 76573746}, ui = 153147492, i = 153147492, v = 0x920d864, cv = 0x920d864}, vector={gu = {type = Lisp_Type_Record, val = 38449744}, s = {bits = 0, val = 76899488}, u = {bits = 0, val = 76899488}, ui = 153798976, i = 153798976, v = 0x92ac940, cv = 0x92ac940}, maxdepth={ gu = {type = Lisp_Type_Int_Odd, val = 2}, s = {bits = 1, val = 5}, u = { bits = 1, val = 5}, ui = 11, i = 11, v = 0xb, cv = 0xb}) at bytecode.c:416 #24 0x809fe40 in funcall_lambda (fun={gu = {type = Lisp_Type_Record, val = 38275193}, s = {bits = 0, val = 76550386}, u = {bits = 0, val = 76550386}, ui = 153100772, i = 153100772, v = 0x92021e4, cv = 0x92021e4}, nargs=4, arg_vector=0xbfffea80) at eval.c:3602 #25 0x809f316 in funcall_recording_as (recorded_as={gu = { type = Lisp_Type_Record, val = 38446919}, s = {bits = 0, val = 76893838}, u = {bits = 0, val = 76893838}, ui = 153787676, i = 153787676, v = 0x92a9d1c, cv = 0x92a9d1c}, nargs=4, args=0xbfffea7c) at eval.c:3217 #26 0x809f372 in Ffuncall (nargs=5, args=0xbfffea7c) at eval.c:3241 ---Type <return> to continue, or q <return> to quit--- #27 0x80810be in Fbyte_code (bytestr={gu = {type = Lisp_Type_Record, val = 38534717}, s = {bits = 0, val = 77069434}, u = {bits = 0, val = 77069434}, ui = 154138868, i = 154138868, v = 0x92ff8f4, cv = 0x92ff8f4}, vector={gu = {type = Lisp_Type_Record, val = 36028936}, s = {bits = 0, val = 72057872}, u = {bits = 0, val = 72057872}, ui = 144115744, i = 144115744, v = 0x8970820, cv = 0x8970820}, maxdepth={ gu = {type = Lisp_Type_Int_Odd, val = 3}, s = {bits = 1, val = 7}, u = { bits = 1, val = 7}, ui = 15, i = 15, v = 0xf, cv = 0xf}) at bytecode.c:416 #28 0x809fe40 in funcall_lambda (fun={gu = {type = Lisp_Type_Record, val = 38456773}, s = {bits = 0, val = 76913546}, u = {bits = 0, val = 76913546}, ui = 153827092, i = 153827092, v = 0x92b3714, cv = 0x92b3714}, nargs=9, arg_vector=0xbffff0a0) at eval.c:3602 #29 0x809f316 in funcall_recording_as (recorded_as={gu = { type = Lisp_Type_Record, val = 38457438}, s = {bits = 0, val = 76914876}, u = {bits = 0, val = 76914876}, ui = 153829752, i = 153829752, v = 0x92b4178, cv = 0x92b4178}, nargs=9, args=0xbffff09c) at eval.c:3217 #30 0x809f372 in Ffuncall (nargs=10, args=0xbffff09c) at eval.c:3241 #31 0x80810be in Fbyte_code (bytestr={gu = {type = Lisp_Type_Record, val = 38465907}, s = {bits = 0, val = 76931814}, u = {bits = 0, val = 76931814}, ui = 153863628, i = 153863628, v = 0x92bc5cc, cv = 0x92bc5cc}, vector={gu = {type = Lisp_Type_Record, val = 38547632}, ---Type <return> to continue, or q <return> to quit--- s = {bits = 0, val = 77095264}, u = {bits = 0, val = 77095264}, ui = 154190528, i = 154190528, v = 0x930c2c0, cv = 0x930c2c0}, maxdepth={ gu = {type = Lisp_Type_Int_Even, val = 8}, s = {bits = 1, val = 16}, u = {bits = 1, val = 16}, ui = 33, i = 33, v = 0x21, cv = 0x21}) at bytecode.c:416 #32 0x809fe40 in funcall_lambda (fun={gu = {type = Lisp_Type_Record, val = 38544920}, s = {bits = 0, val = 77089840}, u = {bits = 0, val = 77089840}, ui = 154179680, i = 154179680, v = 0x9309860, cv = 0x9309860}, nargs=5, arg_vector=0xbffff3b8) at eval.c:3602 #33 0x809f316 in funcall_recording_as (recorded_as={gu = { type = Lisp_Type_Record, val = 38449183}, s = {bits = 0, val = 76898366}, u = {bits = 0, val = 76898366}, ui = 153796732, i = 153796732, v = 0x92ac07c, cv = 0x92ac07c}, nargs=5, args=0xbffff3b4) at eval.c:3217 #34 0x809f372 in Ffuncall (nargs=6, args=0xbffff3b4) at eval.c:3241 #35 0x80810be in Fbyte_code (bytestr={gu = {type = Lisp_Type_Record, val = 38282945}, s = {bits = 0, val = 76565890}, u = {bits = 0, val = 76565890}, ui = 153131780, i = 153131780, v = 0x9209b04, cv = 0x9209b04}, vector={gu = {type = Lisp_Type_Record, val = 38547608}, s = {bits = 0, val = 77095216}, u = {bits = 0, val = 77095216}, ui = 154190432, i = 154190432, v = 0x930c260, cv = 0x930c260}, maxdepth={ gu = {type = Lisp_Type_Int_Even, val = 3}, s = {bits = 1, val = 6}, u = { bits = 1, val = 6}, ui = 13, i = 13, v = 0xd, cv = 0xd}) ---Type <return> to continue, or q <return> to quit--- at bytecode.c:416 #36 0x809fe40 in funcall_lambda (fun={gu = {type = Lisp_Type_Record, val = 38544906}, s = {bits = 0, val = 77089812}, u = {bits = 0, val = 77089812}, ui = 154179624, i = 154179624, v = 0x9309828, cv = 0x9309828}, nargs=2, arg_vector=0xbffff66c) at eval.c:3602 #37 0x809f316 in funcall_recording_as (recorded_as={gu = { type = Lisp_Type_Record, val = 38544906}, s = {bits = 0, val = 77089812}, u = {bits = 0, val = 77089812}, ui = 154179624, i = 154179624, v = 0x9309828, cv = 0x9309828}, nargs=2, args=0xbffff668) at eval.c:3217 #38 0x809f372 in Ffuncall (nargs=3, args=0xbffff668) at eval.c:3241 #39 0x809f989 in Fapply (nargs=2, args=0xbffff6c4) at eval.c:3466 #40 0x80a0362 in apply1 (fn={gu = {type = Lisp_Type_Record, val = 38544906}, s = {bits = 0, val = 77089812}, u = {bits = 0, val = 77089812}, ui = 154179624, i = 154179624, v = 0x9309828, cv = 0x9309828}, arg={ gu = {type = Lisp_Type_Record, val = 38460194}, s = {bits = 0, val = 76920388}, u = {bits = 0, val = 76920388}, ui = 153840776, i = 153840776, v = 0x92b6c88, cv = 0x92b6c88}) at eval.c:3889 #41 0x80830bb in Fcall_interactively (function={gu = {type = Lisp_Type_Record, val = 34440379}, s = {bits = 0, val = 68880758}, u = {bits = 0, val = 68880758}, ui = 137761516, i = 137761516, v = 0x83612ec, cv = 0x83612ec}, record_flag={gu = {type = Lisp_Type_Record, val = 34189837}, s = {bits = 0, val = 68379674}, u = {bits = 0, ---Type <return> to continue, or q <return> to quit--- val = 68379674}, ui = 136759348, i = 136759348, v = 0x826c834, cv = 0x826c834}, keys={gu = {type = Lisp_Type_Record, val = 34189837}, s = {bits = 0, val = 68379674}, u = {bits = 0, val = 68379674}, ui = 136759348, i = 136759348, v = 0x826c834, cv = 0x826c834}) at callint.c:397 #42 0x809effa in funcall_recording_as (recorded_as={gu = { type = Lisp_Type_Record, val = 34208014}, s = {bits = 0, val = 68416028}, u = {bits = 0, val = 68416028}, ui = 136832056, i = 136832056, v = 0x827e438, cv = 0x827e438}, nargs=1, args=0xbffff860) at eval.c:3196 #43 0x809f372 in Ffuncall (nargs=2, args=0xbffff860) at eval.c:3241 #44 0x80a040f in call1 (fn={gu = {type = Lisp_Type_Record, val = 34208014}, s = {bits = 0, val = 68416028}, u = {bits = 0, val = 68416028}, ui = 136832056, i = 136832056, v = 0x827e438, cv = 0x827e438}, arg0={ gu = {type = Lisp_Type_Record, val = 34440379}, s = {bits = 0, val = 68880758}, u = {bits = 0, val = 68880758}, ui = 137761516, i = 137761516, v = 0x83612ec, cv = 0x83612ec}) at eval.c:3915 #45 0x80be036 in execute_command_event (command_builder=0x83648b8, event={ gu = {type = Lisp_Type_Record, val = 35774693}, s = {bits = 0, val = 71549386}, u = {bits = 0, val = 71549386}, ui = 143098772, i = 143098772, v = 0x8878394, cv = 0x8878394}) at event-stream.c:4284 #46 0x80be54c in Fdispatch_event (event={gu = {type = Lisp_Type_Record, val = 35774693}, s = {bits = 0, val = 71549386}, u = {bits = 0, ---Type <return> to continue, or q <return> to quit--- val = 71549386}, ui = 143098772, i = 143098772, v = 0x8878394, cv = 0x8878394}) at event-stream.c:4631 #47 0x8087d87 in Fcommand_loop_1 () at cmdloop.c:574 #48 0x8087bc5 in command_loop_1 (dummy={gu = {type = Lisp_Type_Record, val = 34189837}, s = {bits = 0, val = 68379674}, u = {bits = 0, val = 68379674}, ui = 136759348, i = 136759348, v = 0x826c834, cv = 0x826c834}) at cmdloop.c:494 #49 0x809c7e2 in condition_case_1 (handlers={gu = {type = Lisp_Type_Record, val = 34189865}, s = {bits = 0, val = 68379730}, u = {bits = 0, val = 68379730}, ui = 136759460, i = 136759460, v = 0x826c8a4, cv = 0x826c8a4}, bfun=0x8087ba4 <command_loop_1>, barg={gu = { type = Lisp_Type_Record, val = 34189837}, s = {bits = 0, val = 68379674}, u = {bits = 0, val = 68379674}, ui = 136759348, i = 136759348, v = 0x826c834, cv = 0x826c834}, hfun=0x8087674 <cmd_error>, harg={gu = {type = Lisp_Type_Record, val = 34189837}, s = {bits = 0, val = 68379674}, u = {bits = 0, val = 68379674}, ui = 136759348, i = 136759348, v = 0x826c834, cv = 0x826c834}) at eval.c:1656 #50 0x808779d in command_loop_3 () at cmdloop.c:256 #51 0x80877bc in command_loop_2 (dummy={gu = {type = Lisp_Type_Record, val = 34189837}, s = {bits = 0, val = 68379674}, u = {bits = 0, val = 68379674}, ui = 136759348, i = 136759348, v = 0x826c834, cv = 0x826c834}) at cmdloop.c:267 ---Type <return> to continue, or q <return> to quit--- #52 0x809c458 in internal_catch (tag={gu = {type = Lisp_Type_Record, val = 34208423}, s = {bits = 0, val = 68416846}, u = {bits = 0, val = 68416846}, ui = 136833692, i = 136833692, v = 0x827ea9c, cv = 0x827ea9c}, func=0x80877b0 <command_loop_2>, arg={gu = { type = Lisp_Type_Record, val = 34189837}, s = {bits = 0, val = 68379674}, u = {bits = 0, val = 68379674}, ui = 136759348, i = 136759348, v = 0x826c834, cv = 0x826c834}, threw=0x0) at eval.c:1331 #53 0x8087933 in initial_command_loop (load_me={gu = {type = Lisp_Type_Record, val = 34189837}, s = {bits = 0, val = 68379674}, u = {bits = 0, val = 68379674}, ui = 136759348, i = 136759348, v = 0x826c834, cv = 0x826c834}) at cmdloop.c:305 #54 0x80997ac in sort_args (argc=1, argv=0xbffffc24) at emacs.c:1664 #55 0x8099eed in main (argc=1, argv=0xbffffc24, envp=0xbffffc2c) at emacs.c:2081 (gdb) quit %

1 participants
0 comments

Re: why is the line-number-mode option commented ? 27 years

Didier Verna

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Ben Wing <ben(a)666.com> writes: > > > Blame Chuck, not Jamie. It is commented out because it has never > > been implemented efficiently -- its current implementation is > > quadratic on large files, which is very bad. > > I've implemented it efficiently for 21.0 (look at src/line-number.c.) > So it's safe to promote it. OK. So I'll restore the option in the menu. BTW, may I add a "column number mode" entry too ? Didier

1 participants
0 comments

Re: options menu port to Custom 2/2 27 years

Jan Vroonhof

Didier Verna <verna(a)inf.enst.fr> writes: > Is it really what we want ? That means that people will be able to > edit the faces, but not save their modifications. No that is not what we want. However this is best we can have at the moment. edit-faces is good for trying out new X fonts... Jan P.S. Some truetype fonts with xfsft look very very nice with XEmacs

1 participants
0 comments

Re: why is the line-number-mode option commented ? 27 years

Hrvoje Niksic

Ben Wing <ben(a)666.com> writes: > Blame Chuck, not Jamie. It is commented out because it has never > been implemented efficiently -- its current implementation is > quadratic on large files, which is very bad. I've implemented it efficiently for 21.0 (look at src/line-number.c.) So it's safe to promote it. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- "A Real Programmer's code can awe with its fiendish brilliance, even as its crockishness appalls."

1 participants
0 comments

Re: options menu port to Custom 2/2 27 years

Didier Verna

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Didier Verna <verna(a)inf.enst.fr> writes: > > > OK. Then, we should keep the functionalities related to saving the > > faces that were not customized too (I mean in the option saving process). > > No. Just ditch is from the options menu altogether but keep the M-x > edit-faces command somewhere. Is it really what we want ? That means that people will be able to edit the faces, but not save their modifications.

1 participants
0 comments

[Success] XEmacs 21.0-b37 "Pygmy-pre1", sparc-sun-solaris2.5.1 27 years

Adrian Aichner

...without external-widgets this time (from CVS). Adrian > XEmacs Build Report as generated > by build-report-version $Revision: 1.39 $ follows: > Contents of /export/home/tmp/CVSroot/xemacs-20/Installation: > (Output from most recent run of ./configure)

1 participants
0 comments

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta April 1998