Re: CC Mode 5.22 (C); indentation weirdness
27 years, 6 months
Barry A. Warsaw
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, 6 months
David Bakhash
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, 6 months
Andy Piper
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, 6 months
Didier Verna
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, 6 months
Karl M. Hegbloom
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, 6 months
Didier Verna
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, 6 months
Jan Vroonhof
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, 6 months
Hrvoje Niksic
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, 6 months
Didier Verna
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, 6 months
Adrian Aichner
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