21.1.12 crash
24 years, 1 month
Neal D. Becker
Neal D. Becker
Crash when running M-x gnus.
uname -a: Linux adglinux1.hns.com 2.4.0-test8 #1 Mon Sep 11 08:39:02 EDT 2000 i686 unknown
../configure
XEmacs 21.1.12 "Channel Islands" configured for `i686-pc-linux'.
Where should the build process find the source code? /usr/local/src/xemacs-21.1.12
What installation prefix should install use? /usr/local
What operating system and machine description files should XEmacs use?
`s/linux.h' and `m/intel386.h'
What compiler should XEmacs be built with? gcc -g -O3 -Wall -Wno-switch
Should XEmacs use the GNU version of malloc? yes
(Using Doug Lea's new malloc from the GNU C Library.)
Should XEmacs use the relocating allocator for buffers? yes
What window system should XEmacs use? x11
Where do we find X Windows header files? /usr/X11R6/include
Where do we find X Windows libraries? /usr/X11R6/lib
Compiling in support for XAUTH.
Compiling in support for XPM images.
Compiling in support for PNG image handling.
Compiling in support for (builtin) GIF image handling.
Compiling in support for JPEG image handling.
Compiling in support for TIFF image handling.
Compiling in native sound support.
Compiling in support for Berkeley DB.
Compiling in support for ncurses.
Compiling in support for proper session-management.
Using Lucid menubars.
Using Lucid scrollbars.
Using Motif dialog boxes.
Compiling in DLL support.
movemail will use "dot-locking" for locking mail spool files.
Using Lisp_Objects with minimal tagbits.
(gdb) where
#0 0x403d7d41 in __kill () from /lib/libc.so.6
#1 0x80a1c0b in fatal_error_signal (sig=6)
at /usr/local/src/xemacs-21.1.12/src/emacs.c:263
#2 <signal handler called>
#3 0x403d7d41 in __kill () from /lib/libc.so.6
#4 0x403d79b6 in raise (sig=6) at ../sysdeps/posix/raise.c:27
#5 0x403d90d8 in abort () at ../sysdeps/generic/abort.c:88
#6 0x80a1b51 in assert_failed ()
at /usr/local/src/xemacs-21.1.12/src/emacs.c:2627
#7 0x80a3139 in signal_1 (sig=136890300, data=166355720)
at /usr/local/src/xemacs-21.1.12/src/eval.c:1877
#8 0x80a3815 in Fsignal (error_symbol=136890300, data=166355720)
at /usr/local/src/xemacs-21.1.12/src/eval.c:2044
#9 0x80a825c in signal_error (sig=136890300, data=166355720)
at /usr/local/src/xemacs-21.1.12/src/eval.c:2053
#10 0x80926e5 in dead_wrong_type_argument ()
at /usr/local/src/xemacs-21.1.12/src/data.c:115
#11 0x810937f in set_marker_internal (marker=143817956, pos=136890132,
buffer=136890132, restricted_p=0)
at /usr/local/src/xemacs-21.1.12/src/marker.c:173
#12 0x8109869 in Fset_marker (marker=143817956, number=136890132,
buffer=136890132) at /usr/local/src/xemacs-21.1.12/src/marker.c:266
#13 0x81128c6 in Fdelete_process (proc=163862992)
---Type <return> to continue, or q <return> to quit---
at /usr/local/src/xemacs-21.1.12/src/process.c:1868
#14 0x81129b5 in kill_buffer_processes (buffer=136890132)
at /usr/local/src/xemacs-21.1.12/src/process.c:1922
#15 0x80a0ebf in shut_down_emacs (sig=11, stuff=136890132)
at /usr/local/src/xemacs-21.1.12/src/emacs.c:2323
#16 0x80a1bd0 in fatal_error_signal (sig=11)
at /usr/local/src/xemacs-21.1.12/src/emacs.c:244
#17 <signal handler called>
#18 garbage_collect_1 () at /usr/local/src/xemacs-21.1.12/src/alloc.c:3192
#19 0x80a4eff in funcall_recording_as (recorded_as=139091788, nargs=4,
args=0xbfffa2ec) at /usr/local/src/xemacs-21.1.12/src/eval.c:3114
#20 0x80a87e1 in call3 (fn=139091788, arg0=136980016, arg1=167409956,
arg2=136890132) at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#21 0x80d9920 in Fexpand_file_name (name=167409956,
default_directory=136890132)
at /usr/local/src/xemacs-21.1.12/src/fileio.c:406
#22 0x80dbba4 in Ffile_symlink_p (filename=167409956)
at /usr/local/src/xemacs-21.1.12/src/fileio.c:2370
#23 0x80dd922 in Fwrite_region_internal (start=281917, end=287677,
filename=167409956, append=136890132, visit=136890132, lockname=167409956,
codesys=136890132) at /usr/local/src/xemacs-21.1.12/src/fileio.c:3429
#24 0x80a531a in funcall_recording_as (recorded_as=136981344, nargs=7,
args=0xbfffa5d0) at /usr/local/src/xemacs-21.1.12/src/eval.c:3197
---Type <return> to continue, or q <return> to quit---
#25 0x80a95b9 in Ffuncall (nargs=8, args=0xbfffa5d0)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#26 0x80864e9 in Fbyte_code (bytestr=136343560, vector=136343636, maxdepth=17)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:416
#27 0x80a5f1d in funcall_lambda (fun=136343684, nargs=7, arg_vector=0xbfffa724)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#28 0x80a53b2 in funcall_recording_as (recorded_as=136980784, nargs=7,
args=0xbfffa720) at /usr/local/src/xemacs-21.1.12/src/eval.c:3214
#29 0x80a5a09 in Fapply (nargs=2, args=0xbfffa894)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3463
#30 0x80a510b in funcall_recording_as (recorded_as=136973988, nargs=2,
args=0xbfffa890) at /usr/local/src/xemacs-21.1.12/src/eval.c:3178
#31 0x80a95b9 in Ffuncall (nargs=3, args=0xbfffa890)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#32 0x80864e9 in Fbyte_code (bytestr=142197860, vector=142667672, maxdepth=9)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:416
#33 0x80a5f1d in funcall_lambda (fun=142615560, nargs=8, arg_vector=0xbfffa9ec)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#34 0x80a53b2 in funcall_recording_as (recorded_as=139091788, nargs=8,
args=0xbfffa9e8) at /usr/local/src/xemacs-21.1.12/src/eval.c:3214
#35 0x80a8a25 in call8 (fn=139091788, arg0=136980784, arg1=281917,
arg2=287677, arg3=167409956, arg4=136890132, arg5=136890132,
arg6=167409956, arg7=136890132)
---Type <return> to continue, or q <return> to quit---
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#36 0x80dd361 in Fwrite_region_internal (start=281917, end=287677,
filename=167409956, append=136890132, visit=136890132, lockname=167409956,
codesys=136890132) at /usr/local/src/xemacs-21.1.12/src/fileio.c:3213
#37 0x80a531a in funcall_recording_as (recorded_as=136981344, nargs=7,
args=0xbfffac70) at /usr/local/src/xemacs-21.1.12/src/eval.c:3197
#38 0x80a95b9 in Ffuncall (nargs=8, args=0xbfffac70)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#39 0x80864e9 in Fbyte_code (bytestr=136343560, vector=136343636, maxdepth=17)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:416
#40 0x80a5f1d in funcall_lambda (fun=136343684, nargs=6, arg_vector=0xbfffae54)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#41 0x80a53b2 in funcall_recording_as (recorded_as=136980784, nargs=6,
args=0xbfffae50) at /usr/local/src/xemacs-21.1.12/src/eval.c:3214
#42 0x80a95b9 in Ffuncall (nargs=7, args=0xbfffae50)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#43 0x80864e9 in Fbyte_code (bytestr=140364860, vector=140895120, maxdepth=15)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:416
#44 0x80a5f1d in funcall_lambda (fun=141097356, nargs=5, arg_vector=0xbfffb1d4)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#45 0x80a53b2 in funcall_recording_as (recorded_as=140891640, nargs=5,
args=0xbfffb1d0) at /usr/local/src/xemacs-21.1.12/src/eval.c:3214
#46 0x80a95b9 in Ffuncall (nargs=6, args=0xbfffb1d0)
---Type <return> to continue, or q <return> to quit---
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#47 0x80864e9 in Fbyte_code (bytestr=141778804, vector=141782744, maxdepth=17)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:416
#48 0x80a5f1d in funcall_lambda (fun=141502860, nargs=1, arg_vector=0xbfffb5b4)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#49 0x80a53b2 in funcall_recording_as (recorded_as=141745208, nargs=1,
args=0xbfffb5b0) at /usr/local/src/xemacs-21.1.12/src/eval.c:3214
#50 0x80a95b9 in Ffuncall (nargs=2, args=0xbfffb5b0)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#51 0x80864e9 in Fbyte_code (bytestr=140340780, vector=140894432, maxdepth=9)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:416
#52 0x80a5f1d in funcall_lambda (fun=141097188, nargs=3, arg_vector=0xbfffbc44)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#53 0x80a53b2 in funcall_recording_as (recorded_as=141092976, nargs=3,
args=0xbfffbc40) at /usr/local/src/xemacs-21.1.12/src/eval.c:3214
#54 0x80a95b9 in Ffuncall (nargs=4, args=0xbfffbc40)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#55 0x80864e9 in Fbyte_code (bytestr=140055148, vector=140889696, maxdepth=19)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:416
#56 0x80a5f1d in funcall_lambda (fun=141096460, nargs=2, arg_vector=0xbfffbf74)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#57 0x80a53b2 in funcall_recording_as (recorded_as=141093060, nargs=2,
args=0xbfffbf70) at /usr/local/src/xemacs-21.1.12/src/eval.c:3214
---Type <return> to continue, or q <return> to quit---
#58 0x80a95b9 in Ffuncall (nargs=3, args=0xbfffbf70)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#59 0x80864e9 in Fbyte_code (bytestr=140084780, vector=140890168, maxdepth=7)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:416
#60 0x80a5f1d in funcall_lambda (fun=141096544, nargs=5, arg_vector=0xbfffc040)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#61 0x80a5ace in apply_lambda (fun=141096544, numargs=5,
unevalled_args=136890132) at /usr/local/src/xemacs-21.1.12/src/eval.c:3501
#62 0x80a4d6f in Feval (form=159125840)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3085
#63 0x80a5ea1 in funcall_lambda (fun=159125804, nargs=2, arg_vector=0xbfffc3e4)
at /usr/local/src/xemacs-21.1.12/src/eval.c:758
#64 0x80a53b2 in funcall_recording_as (recorded_as=159125804, nargs=2,
args=0xbfffc3e0) at /usr/local/src/xemacs-21.1.12/src/eval.c:3214
#65 0x80a95b9 in Ffuncall (nargs=3, args=0xbfffc3e0)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#66 0x80864e9 in Fbyte_code (bytestr=139256036, vector=140752368, maxdepth=11)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:416
#67 0x80a5f1d in funcall_lambda (fun=141087676, nargs=2, arg_vector=0xbfffc624)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#68 0x80a53b2 in funcall_recording_as (recorded_as=140849396, nargs=2,
args=0xbfffc620) at /usr/local/src/xemacs-21.1.12/src/eval.c:3214
#69 0x80a95b9 in Ffuncall (nargs=3, args=0xbfffc620)
---Type <return> to continue, or q <return> to quit---
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#70 0x80864e9 in Fbyte_code (bytestr=139416564, vector=140751952, maxdepth=13)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:416
#71 0x80a5f1d in funcall_lambda (fun=141087872, nargs=2, arg_vector=0xbfffc794)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#72 0x80a53b2 in funcall_recording_as (recorded_as=141141484, nargs=2,
args=0xbfffc790) at /usr/local/src/xemacs-21.1.12/src/eval.c:3214
#73 0x80a95b9 in Ffuncall (nargs=3, args=0xbfffc790)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#74 0x80a49ee in Feval (form=140133956)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3023
#75 0x80a3042 in condition_case_3 (bodyform=140133956, var=137418828,
handlers=140112020) at /usr/local/src/xemacs-21.1.12/src/eval.c:1653
#76 0x80868cf in Fbyte_code (bytestr=139084700, vector=140851576, maxdepth=11)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:576
#77 0x80a5f1d in funcall_lambda (fun=141087620, nargs=2, arg_vector=0xbfffd124)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#78 0x80a53b2 in funcall_recording_as (recorded_as=140849340, nargs=2,
args=0xbfffd120) at /usr/local/src/xemacs-21.1.12/src/eval.c:3214
#79 0x80a95b9 in Ffuncall (nargs=3, args=0xbfffd120)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#80 0x80864e9 in Fbyte_code (bytestr=140351524, vector=140894656, maxdepth=31)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:416
---Type <return> to continue, or q <return> to quit---
#81 0x80a5f1d in funcall_lambda (fun=141097244, nargs=4, arg_vector=0xbfffd2f4)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#82 0x80a53b2 in funcall_recording_as (recorded_as=140892004, nargs=4,
args=0xbfffd2f0) at /usr/local/src/xemacs-21.1.12/src/eval.c:3214
#83 0x80a95b9 in Ffuncall (nargs=5, args=0xbfffd2f0)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#84 0x80864e9 in Fbyte_code (bytestr=141748060, vector=141331904, maxdepth=11)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:416
#85 0x80a5f1d in funcall_lambda (fun=141502300, nargs=2, arg_vector=0xbfffd544)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#86 0x80a53b2 in funcall_recording_as (recorded_as=141744676, nargs=2,
args=0xbfffd540) at /usr/local/src/xemacs-21.1.12/src/eval.c:3214
#87 0x80a95b9 in Ffuncall (nargs=3, args=0xbfffd540)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#88 0x80864e9 in Fbyte_code (bytestr=139229940, vector=140120928, maxdepth=9)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:416
#89 0x80a5f1d in funcall_lambda (fun=140819980, nargs=2, arg_vector=0xbfffddd4)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#90 0x80a53b2 in funcall_recording_as (recorded_as=140313636, nargs=2,
args=0xbfffddd0) at /usr/local/src/xemacs-21.1.12/src/eval.c:3214
#91 0x80a95b9 in Ffuncall (nargs=3, args=0xbfffddd0)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#92 0x80864e9 in Fbyte_code (bytestr=140420732, vector=140877200, maxdepth=13)
---Type <return> to continue, or q <return> to quit---
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:416
#93 0x80a5f1d in funcall_lambda (fun=140731448, nargs=2, arg_vector=0xbfffdeb0)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#94 0x80a5ace in apply_lambda (fun=140731448, numargs=2,
unevalled_args=136890132) at /usr/local/src/xemacs-21.1.12/src/eval.c:3501
#95 0x80a4d6f in Feval (form=140860772)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3085
#96 0x80a3042 in condition_case_3 (bodyform=140860772, var=136890132,
handlers=140860712) at /usr/local/src/xemacs-21.1.12/src/eval.c:1653
#97 0x80868cf in Fbyte_code (bytestr=140421468, vector=140874936, maxdepth=11)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:576
#98 0x80a5f1d in funcall_lambda (fun=140731420, nargs=2, arg_vector=0xbfffe744)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#99 0x80a53b2 in funcall_recording_as (recorded_as=139381268, nargs=2,
args=0xbfffe740) at /usr/local/src/xemacs-21.1.12/src/eval.c:3214
#100 0x80a95b9 in Ffuncall (nargs=3, args=0xbfffe740)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#101 0x80864e9 in Fbyte_code (bytestr=140353692, vector=140816144, maxdepth=11)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:416
#102 0x80a5f1d in funcall_lambda (fun=140730692, nargs=3,
arg_vector=0xbfffe9e4) at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#103 0x80a53b2 in funcall_recording_as (recorded_as=140811568, nargs=3,
args=0xbfffe9e0) at /usr/local/src/xemacs-21.1.12/src/eval.c:3214
---Type <return> to continue, or q <return> to quit---
#104 0x80a95b9 in Ffuncall (nargs=4, args=0xbfffe9e0)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#105 0x80864e9 in Fbyte_code (bytestr=140224532, vector=140736856, maxdepth=9)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:416
#106 0x80a4c13 in Feval (form=140814732)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3063
#107 0x80a95fd in Fprogn (args=140815044)
at /usr/local/src/xemacs-21.1.12/src/eval.c:758
#108 0x80a930c in unbind_to (count=12, value=136890132)
at /usr/local/src/xemacs-21.1.12/src/eval.c:4694
#109 0x8086531 in Fbyte_code (bytestr=140225140, vector=140815400, maxdepth=7)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:431
#110 0x80a5f1d in funcall_lambda (fun=140730384, nargs=3,
arg_vector=0xbfffef24) at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#111 0x80a53b2 in funcall_recording_as (recorded_as=140588040, nargs=3,
args=0xbfffef20) at /usr/local/src/xemacs-21.1.12/src/eval.c:3214
#112 0x80a95b9 in Ffuncall (nargs=4, args=0xbfffef20)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#113 0x80864e9 in Fbyte_code (bytestr=140821564, vector=140247784, maxdepth=9)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:416
#114 0x80a5f1d in funcall_lambda (fun=140819084, nargs=1,
arg_vector=0xbffff094) at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#115 0x80a53b2 in funcall_recording_as (recorded_as=137910248, nargs=1,
---Type <return> to continue, or q <return> to quit---
args=0xbffff090) at /usr/local/src/xemacs-21.1.12/src/eval.c:3214
#116 0x80a95b9 in Ffuncall (nargs=2, args=0xbffff090)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#117 0x8088ea4 in Fcall_interactively (function=137910248,
record_flag=136890160, keys=136890132)
at /usr/local/src/xemacs-21.1.12/src/callint.c:949
#118 0x80a4058 in Fcommand_execute (cmd=137910248, record=136890160,
keys=136890132) at /usr/local/src/xemacs-21.1.12/src/eval.c:2584
#119 0x80a51a3 in funcall_recording_as (recorded_as=136973932, nargs=2,
args=0xbffff490) at /usr/local/src/xemacs-21.1.12/src/eval.c:3193
#120 0x80a95b9 in Ffuncall (nargs=3, args=0xbffff490)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#121 0x80864e9 in Fbyte_code (bytestr=136074376, vector=136074536, maxdepth=17)
at /usr/local/src/xemacs-21.1.12/src/bytecode.c:416
#122 0x80a5f1d in funcall_lambda (fun=136074860, nargs=1,
arg_vector=0xbffff614) at /usr/local/src/xemacs-21.1.12/src/eval.c:3597
#123 0x80a53b2 in funcall_recording_as (recorded_as=137408096, nargs=1,
args=0xbffff610) at /usr/local/src/xemacs-21.1.12/src/eval.c:3214
#124 0x80a95b9 in Ffuncall (nargs=2, args=0xbffff610)
at /usr/local/src/xemacs-21.1.12/src/eval.c:3238
#125 0x8088ea4 in Fcall_interactively (function=137408096,
record_flag=136890132, keys=136890132)
at /usr/local/src/xemacs-21.1.12/src/callint.c:949
---Type <return> to continue, or q <return> to quit---
#126 0x80a4058 in Fcommand_execute (cmd=137408096, record=136890132,
keys=136890132) at /usr/local/src/xemacs-21.1.12/src/eval.c:2584
#127 0x80c800a in execute_command_event (command_builder=0x83ed298,
event=139531996) at /usr/local/src/xemacs-21.1.12/src/event-stream.c:4346
#128 0x80c8742 in Fdispatch_event (event=139531996)
at /usr/local/src/xemacs-21.1.12/src/event-stream.c:4685
#129 0x808ca52 in Fcommand_loop_1 ()
at /usr/local/src/xemacs-21.1.12/src/cmdloop.c:579
#130 0x808cc6d in command_loop_1 (dummy=136890132)
at /usr/local/src/xemacs-21.1.12/src/cmdloop.c:494
#131 0x80a9252 in condition_case_1 (handlers=136890244,
bfun=0x808cc54 <command_loop_1>, barg=136890132,
hfun=0x808cce0 <cmd_error>, harg=136890132)
at /usr/local/src/xemacs-21.1.12/src/eval.c:1653
#132 0x808cdd7 in command_loop_2 (dummy=136890132)
at /usr/local/src/xemacs-21.1.12/src/cmdloop.c:256
#133 0x80a9120 in internal_catch (tag=136964504,
func=0x808cd9c <command_loop_2>, arg=136890132, threw=0x0)
at /usr/local/src/xemacs-21.1.12/src/eval.c:1328
#134 0x808c75e in initial_command_loop (load_me=136890132)
at /usr/local/src/xemacs-21.1.12/src/cmdloop.c:305
#135 0x80a0675 in xemacs_21_1_12_i686_pc_linux ()
at /usr/local/src/xemacs-21.1.12/src/emacs.c:1720
---Type <return> to continue, or q <return> to quit---
#136 0x80a1e24 in main (argc=1, argv=0xbffffb94, envp=0xbffffb9c)
at /usr/local/src/xemacs-21.1.12/src/emacs.c:2137
#137 0x403d19cb in __libc_start_main (main=0x80a1d1c <main>, argc=1,
argv=0xbffffb94, init=0x8077e08 <_init>, fini=0x816f164 <_fini>,
rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffffb8c)
at ../sysdeps/generic/libc-start.c:92
(gdb)
(gdb) quit
Inferior GDB finished
- 1 participants
- 0 comments
RE: auto-save-list-file-name
24 years, 1 month
Troy Noble
Troy Noble
Yoshiki,
You need to change:
+ (if auto-save-list-file-name
to
+ (if auto-save-list-file-prefix
But please read my code below too since it replaces this section with a
call to a new function.
I agree a patch is a good idea because it fixes the problem for most users,
but the one provided will not fix it in all cases (see code below that I
think does).
Your patch addresses the problem if the auto-save-list-file-prefix is
set in the user's initialization file. If they later toggle
auto-save-list-file-prefix to nil (like Steve did), the
auto-save-list-file-name will still be set to the value to which it was
initialized in normal-top-level unless the user also sets
auto-save-list-file-name to nil.
That's the second half of the problem Steve was alluding to I
believe.
Steve, I was setting auto-save-list-file-prefix to nil in my init file,
that's probably why I saw different behavior than the test case you
showed (you were exec'ing the setq in the *scratch* buffer I believe).
I would propose a more permanent solution by adding the following to
startup.el,
or maybe files.el. Not sure which is better.
One added benefit to this approach is that the user can now define their own
auto-save-make-list-file-name in similar fashion to
make-auto-save-file-name.
Oooohhhhh! I just got a warm fuzzy! More configuration options, that's
just what XEmacs needs!
I'm no lisp expert... so forgive any style errors, and feel free to change
the names as desired. The code does seem to work though.
(defconst auto-save-default-list-file-prefix "~/.saves-"
"*Default value for auto-save-list-file-prefix.")
(defun auto-save-make-list-file-name ()
"Make a name suitable for auto-save-list-file-name based on
auto-save-list-file-prefix. If auto-save-list-file-prefix is nil,
returns nil"
(if auto-save-list-file-prefix
(expand-file-name
(format "%s%d-%s"
auto-save-list-file-prefix
(emacs-pid)
(system-name)))
nil))
(defun auto-save-disable-list-file ()
"Turn off creation of auto save list file by clearing the
auto-save-list-file-name and auto-save-list-file-prefix.
WARNING: Turning off auto save list file creation does not
disable auto saving, but will cause recover-session to
be unusable for files edited during this session"
(setq auto-save-list-file-prefix nil
auto-save-list-file-name nil))
(defun auto-save-enable-list-file ()
"Turn on creation of auto save list file by setting the
auto-save-list-file-name and auto-save-list-file-prefix."
(setq auto-save-list-file-prefix auto-save-default-list-file-prefix
auto-save-list-file-name (auto-save-make-list-file-name)))
Then inside normal-top-level you can change:
+ (if auto-save-list-file-name
+ (setq auto-save-list-file-name
+ (expand-file-name
+ (format "%s%d-%s"
+ auto-save-list-file-prefix
+ (emacs-pid)
+ (system-name)))))
to:
+ (setq auto-save-list-file-name (auto-save-make-list-file-name))
since that code has been moved to the function instead.
Troy
-----Original Message-----
From: Yoshiki Hayashi [mailto:yoshiki＠xemacs.org]
Sent: Wednesday, October 25, 2000 2:11 AM
To: Steve Youngs
Cc: Troy Noble; XEmacs beta; 'Adrian Aichner'; xemacs-patches(a)xemacs.org
Subject: Re: auto-save-list-file-name
Steve Youngs <youngs(a)xemacs.org> writes:
> In the scratch buffer:
> (setq auto-save-list-file-prefix nil)
> M-x eval-current-buffer
> C-x C-f ~/temp/fred RET
> C-x C-s
> <bang on the keyboard repeatedly until 'auto-save-interval' expires>
>
> The result:
>
> ,----[ ~/nil5896-slackware.mynet.pc ]
> | /home/steve/temp/#fred#
> | /home/steve/temp/fred
> `----
This patch fixes it. Recommended for 21.1.
2000-10-25 Yoshiki Hayashi <yoshiki(a)xemacs.org>
* startup.el (normal-top-level): Set up auto-save-list-file-name
iff auto-save-list-prefix is non-nil.
- 3 participants
- 2 comments
Re: RFC: xemacsweb - XEmacs vs. GNU Emacs
24 years, 1 month
Michael Livshin
Michael Livshin
Ben Wing <ben(a)666.com> writes:
> face it, xemacs is in its death throes.
IME, *absolutely* wrong.
> what it desperately needs is advocacy, not moral high-mindedness.
this might be thought adequate if one accepts the fallacy above (that
XEmacs is in death throes). as things stand, it would only be
harmful.
anecdotal stuff: the two companies I last worked (and work now) for
use XEmacs for all editing tasks. the first probably chose it just
for the pretty pictures, but the current one does so based also on
some features that it has and FSF Emacs doesn't. like, for instance,
the ability to open a frame on anothor display or a tty. this is a
*crucial* feature, as many people here frequently work from home (hey,
like I'm doing just now).
another feature I like is the ability to build XEmacs without MULE, so
that I make it (with the rest of my X environment) cyrillic-friendly
just by setting appropriate fonts in the X resources.
the ability to update packages (like Gnus) without having to maintain
a manual installation and without waiting for the next Emacs release
is also nice, if not that critical.
in short: XEmacs has real features that keep it wanted.
the other argument used when arguing that some piece of software is
dying is lack of maintainers. I don't know if that's true, but I hope
not.
--
For those who like this sort of thing, this is the sort of thing they like.
-- fortune
- 1 participants
- 0 comments
It is impossible to open a file with tilde char anywhere in path
24 years, 1 month
Matej Mihelic
Matej Mihelic
This bug report will be sent to the XEmacs Development Team,
not to your local site managers!!
Please write in English, because the XEmacs maintainers do not have
translators to read other languages for them.
In XEmacs 21.2 (beta36) "Notus" [Lucid] (i586-pc-win32) of Wed Oct 11 2000 on NEVERYON
configured using `configure UNKNOWN'
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
It is impossible to open a file with tilde character anywhere in path or to
open a directory with a tilde anywhere in path. The same goes for EFS paths.
I have tested the behavior with -vanilla.
Steps to repeat:
shell: md c:\~test
xemacs: C-xC-f c:\~test
Similar problems:
xemacs (dired): C-xD c:\~test
xemacs (EFS): C-xC-f /host:/~test
- 1 participants
- 0 comments
Re: Package Release
24 years, 1 month
Carsten Dominik
Carsten Dominik
Dear XEmacs devellopers,
I have a question about my IDLWAVE package. Some time ago (1.5years?)
I submitted a patch to files.el (auto-mode-alist) which would turn on
IDLWAVE mode automatically for files with the extension ".pro". This
patch started a discussion if auto-mode-alist entries related to
packages should be in files.el or if they should be installed
dynamically by the autoload forms in package. I don't know what the
outcome of this discussion was (I don't read the develloper mailing
lists), but the result is that my package is not automatically used
for ".pro" files and user have to install autoload forms by hand.
This is not the way it should be. Could someone please decide what
the policy about this is, so that I can make a patch to either
files.el (adding an entry to auto-mode-alist) or to IDLWAVE (adding an
autoload form which does
(setq auto-mode-alist (cons ("\.[Pp][Rr][Oo]\\'" . idlwave-mode)
auto-mode-alist))
- Carsten
PS. Please CC me on replies. Thanks!
--
Carsten Dominik <dominik(a)astro.uva.nl> \ _ /
Sterrenkundig Instituut "Anton Pannekoek" |X| _
Kruislaan 403; NL-1098 SJ Amsterdam /| |\ _ _ _/ \
phone +31 (20) 525-7477; FAX +31 (20) 525-7484 __|o|___/ ~~ \___/ ~~~
- 4 participants
- 5 comments
Re: RFC: xemacsweb - XEmacs vs. GNU Emacs
24 years, 1 month
Hrvoje Niksic
Hrvoje Niksic
Ben Wing <ben(a)666.com> writes:
> but i completely agree with it. xemacs has ZERO name recognition
> compared to emacs outside [and inside, for that matter!] of the
> miniscule and insulated free software community.
...
> face it, xemacs is in its death throes.
Ben, where do you get this from? Maybe that's the case under MS
Windows, but in the Unix world XEmacs is quite popular. For instance,
in my company (ArsDigita), there are quite a few people using XEmacs
rather than GNU Emacs. Also, XEmacs has been made popular by Linux
distributions. In Croatian Linux newsgroups, most people start with
(and ask questions about) XEmacs because they feel it's gentler to
beginners, even if it's not exactly as true as they think.
Note that many people come to XEmacs for the pretty pictures -- 3D
modelines, nicer-looking scrollbars and menus, support for images, the
vague "X" in the name, etc., but they do come.
XEmacs is one of the (if not *the*) hottest editors out there, much of
it thanks to the work you and Chuck did in creating it, and thanks to
the perseverance of Steve & others in maintaining it afterwards.
> rms will never put rebuttals of his arguments on his site,
This is true. However, I believe we should have a really cooled-down
response argument to make for a *credible* last word. I think your
one is too heated and too personal, and in some things simply wrong
(see the assignments discussion.)
If you want to, I might try to write such a document over the
week-end, and present it for your evaluation.
> what [xemacs] desperately needs is advocacy, not moral
> high-mindedness. no one cares whether you take the moral high road
> or not if you die in the process.
If XEmacs were really in its death throes, I might agree with you. As
it is, I shudder to think exactly what kind of user-base the
Macchiavelian advocacy you propose might buy us.
Instead, we should "fight" with better code and better features.
Specifically, the code *you* are writing and the features you are
introducing are the way to go. Trust me, we have more than enough
name recognition for these features to actually make a difference.
- 1 participants
- 0 comments
Re: RFC: xemacsweb - XEmacs vs. GNU Emacs
24 years, 1 month
Adrian Aichner
Adrian Aichner
>>>>> "Simon" == Simon Josefsson <sj(a)extundo.com> writes:
Simon> Ben Wing <ben(a)666.com> writes:
>> but i completely agree with it. xemacs has ZERO name recognition compared to
>> emacs outside [and inside, for that matter!] of the miniscule and insulated free
>> software community.
Simon> A small note; four out of six core KDE developers mention
Simon> XEmacs as their "favorite tool":
Hey Simon, thanks for the pointer!
Unfortunately the information about XEmacs is too hard to find in the
developer's personal pages.
Simon> http://www.kde.org/people/people.html
General question to all:
How about adding an entry like this to our website?
About XEmacs
+ Why use XEmacs?
History of XEmacs
XEmacs vs. GNU Emacs
Screenshots
Sites Created With XEmacs
Year 2000 Statement
Who Wrote XEmacs?
Website
This new entry, eg. xemacsweb/About/WhyXEmacs.html (generated from
.content file)
could contain pointers highlighting XEmacs's features, testimonials,
and moresuch.
Opinions?
Adrian
Simon> (Emacs and joe for the remaining two.)
--
Adrian Aichner <adrian(a)xemacs.org>, http://www.xemacs.org
- 1 participants
- 0 comments
RFC: xemacsweb - XEmacs vs. GNU Emacs
24 years, 1 month
Stephen J. Turnbull
Stephen J. Turnbull
We've had a bunch of queries about "XEmacs vs. GNU Emacs" in the last
couple of months. It's time someone dusted off that page; here's my
hack at it. A reader's guide:
(0) Appointed myself author. I think that's appropriate since I don't
see how there can be a consensus on writing this page correctly.
I volunteer to be maintainer for it even if you can't stand the
way I write and insist that it be ghosted. :-)
(1) I substituted "Stallman" for "RMS" throughout. I'm more
comfortable with that, but would immediately revert if most people
preferred the initials.
Ditto "GNU Emacs" for "FSF" or "FSF Emacs". This one I feel
stronger about. RMS really gets his back up about it.
(2) Substantial but very tentative reorganization of "The XEmacs Point
of View" according to functional lines. Some updates to recent
versions of XEmacs and FSFmacs. Questions I know I need answers
to marked "####" in HTML comments. I'm sure I slipped on some
other stuff.
(3) Added a "Community Participation" section to "The XEmacs Point
of View". Comments appreciated.
(4) Added a pretty turgid description of the "legal problem" as RMS
perceives it. It's a turgid topic.
(5) Added a bunch of sections describing some philosophical
differences (starting with "What Is the Role of the FSF?").
Seemed good when I wrote it, but the whole topic is flamebait.
Comments requested.
(6) Author's disclaimer. Seems required in context, but what to say?
here it comes, in .content format:
%title%
XEmacs vs. GNU Emacs
%author%
Stephen Turnbull <stephen(a)xemacs.org>
%main%
<h1>XEmacs vs. GNU Emacs</h1>
<p>There are currently irreconcilable differences in the views
about technical, programming, design and organizational
matters between Richard Stallman and the XEmacs development
team which provide little hope for a merge to take place in
the short-term future.
<p>If you have a comment to add regarding the merge, it is a
good idea to avoid posting to the newsgroups, because of the
very heated flamewars that often result. Mail your questions
to
<a href="mailto:xemacs-beta＠xemacs.org">xemacs-beta＠xemacs.org</a>
and
<a href="mailto:bug-gnu-emacs＠prep.ai.mit.edu">bug-gnu-emacs＠prep.ai.mit.edu</a>.
<p>Many people have noticed the great difference in focus
between the two "Viewpoints" presented here, and also have
expressed confusion about the legal issues Stallman focuses
on. The final sections present some explanation and
interpretation regarding these FAQs.
<h2>Difference between XEmacs and GNU Emacs, from the XEmacs Point of View</h2>
<p>This section is now quite dated. Much of it refers to GNU
Emacs 19 and XEmacs 20. However, the differences described
persist in the most recent versions of both Emacsen in some
form.
<h3>User-Visible Editing Features</h3>
<p>In XEmacs, images of arbitrary size can be embedded in a
buffer. (Soon available in GNU Emacs 21.)
<p>In XEmacs, variable width fonts work. (Soon available in
GNU Emacs 21.)
<p>The height of a line is the height of the tallest font on
that line, instead of all lines having the same height. (Soon
available in in GNU Emacs 21.)
<!-- #### Is this obsolete? -->
<p>XEmacs provides support for ToolTalk on systems that have
it.
<!-- #### Probably I should drop mention of DnD and xemacs-gtk? -->
Experimental support for drag-and-drop protocols is
provided from XEmacs 21.
<p>XEmacs can ask questions using popup dialog boxes. Any
command executed from a menu will ask yes/no questions with
dialog boxes, while commands executed via the keyboard will
use the minibuffer.
<p>XEmacs has a built-in toolbar. Four toolbars can actually
be configured: top, bottom, left, and right toolbars.
<p>XEmacs has vertical and horizontal scrollbars. Unlike in
GNU Emacs 19 (which provides a primitive form of vertical
scrollbar), these are true toolkit scrollbars. A look-alike
Motif scrollbar is provided for those who don't have
Motif. (Even for those who do, the look-alike may be
preferable as it is faster.)
<h3>General Platform Support</h3>
<p>If you're running on a machine with audio hardware, you can
specify sound files for XEmacs to play instead of the default
X beep. See the documentation of the function load-sound-file
and the variable sound-alist. XEmacs also supports the
network sound protocols NAS and EsounD.
<p>XEmacs 21 supports database protocols with LISP bindings,
currently including LDAP and PostgreSQL (21.2 only).
<p>XEmacs 20 and 21 support the Canna, Wnn, and SJ3 Japanese
input method servers directly, as well as through the X Input
Method (XIM) protocol. GNU Emacs 20 supports only the XIM
protocol. Both Emacsen support the Quail family of input
methods (implemented in LISP) for many languages.
<h3>LISP Programming</h3>
<p>From XEmacs 20 on, characters are first-class objects.
Characters can be converted to integers, but are not integers.
GNU Emacs 19, XEmacs 19, Mule 2.3 (an extensive patch to GNU
Emacs 18.55 and 19.x), and GNU Emacs 20 (incorporating Mule 3
and later Mule 4) represent them as integers.
<p>From XEmacs 20 on, the buffer is treated as an array of
characters, and the representation of buffer text is not
exposed to LISP. The GNU Emacs 20 functions like
buffer-as-multibyte are not supported.
<p>In XEmacs, events are first-class objects. GNU Emacs 19
represents them as integers, which obscures the differences
between a key gesture and the ancient ASCII code used to
represent a particular overlapping subset of them.
<p>In XEmacs, keymaps are first-class opaque objects. GNU Emacs 19
represents them as complicated combinations of association
lists and vectors. If you use the advertised functional
interface to manipulation of keymaps, the same code will work
in XEmacs, GNU Emacs 18, and GNU Emacs 19; if your code depends on
the underlying implementation of keymaps, it will not.
<p>XEmacs uses "extents" to represent all non-textual aspects
of buffers; GNU Emacs 19 uses two distinct objects, "text
properties" and "overlays", which divide up the functionality
between them. Extents are a superset of the functionality of
the two GNU Emacs data types. The full GNU Emacs 19 interface
to text properties and overlays is supported in XEmacs (with
extents being the underlying representation).
<p>Extents can be made to be copied into strings, and thus
restored by kill and yank. Thus, one can specify this
behavior on either "extents" or "text properties", whereas in
GNU Emacs 19 text properties always have this behavior and
overlays never do.
<h3>Packaged LISP Libraries</h3>
<p>Many more packages are provided standard with XEmacs than
with GNU Emacs 19 or 20.
<p>XEmacs 21 supports an integrated package management system
which uses EFS to download, then automatically install
prebuilt LISP libraries.
<h3>Window System Programming Interface</h3>
<p>XEmacs uses the MIT "Xt" toolkit instead of raw Xlib calls,
which makes it be a more well-behaved X citizen (and also
improves portability). A result of this is that it is
possible to include other Xt "Widgets" in the XEmacs window.
Also, XEmacs understands the standard Xt command-line
arguments.
<p>XEmacs supports Motif applications, generic Xt
(e.g. Athena) applications, and raw Xlib applications. An
XEmacs variant which supports GTK+ is available (but not yet
integrated to the main CVS branch), although code to take
advantage of the support is as yet scarce.
<p>An XEmacs frame can be placed within an "external client
widget" managed by another application. This allows an
application to use an XEmacs frame as its text pane rather
than the standard Text widget that is provided with Motif or
Athena.
<!-- #### This is new! -->
<h3>Community Participation</h3>
<p>Starting with XEmacs 20, joining the XEmacs development
team is simple. Mail to <a
href="mailto:xemacs-beta＠xemacs.org">XEmacs Developers
<xemacs-beta(a)xemacs.org></a>, and you're in! (If you
<em>want</em> to be, of course. You're also welcome to just
post development-related questions and bug reports.) The GNU
Emacs development team and internal mailing lists are still by
invitation only.
<p>The "bleeding edge" of mainline XEmacs development is
available by <a href="http://cvs.xemacs.org">anonymous CVS</a>
as are some subsidiary branches (check out the xemacs-gtk
module for the latest in GUI features!)
<p>CVS commit authority is broadly dispersed. Recognized
maintainers of LISP libraries who are willing to maintain
XEmacs packaged versions automatically qualify for CVS
accounts for their packages.
<h2>The FSF Point of View</h2>
<p><a href="mailto:rms＠gnu.org">Richard Stallman</a> writes:</p>
<blockquote>
<p>XEmacs is GNU software because it's a modified version of a
GNU program. And it is GNU software because the FSF is the
copyright holder for most of it, and therefore the legal
responsibility for protecting its free status falls on us
whether we want it or not. This is why the term "GNU XEmacs"
is legitimate.
<p>But in another sense it is not GNU software, because we
can't use XEmacs in the GNU system: using it would mean paying
a price in terms of our ability to enforce the GPL. Some of
the people who have worked on XEmacs have not provided, and
have not asked other contributors to provide, the legal papers
to help us enforce the GPL. I have managed to get legal
papers for some parts myself, but most of the XEmacs
developers have not helped me get them.
<p>XEmacs was possible because free software means that anyone
can change it and distribute a modified version. I have no
regrets about establishing this freedom for Emacs. Everyone
should have the freedom to change any program, and this is not
limited to changes that the original author likes.
<p>Many people have taken advantage of the freedom to change
GNU Emacs, over the last decade. Most of them were willing to
cooperate on integrating their changes into Emacs. XEmacs
arose as a separate forked version because some of the
developers--starting with Zawinski--were unwilling to do that.
<p>People should have the freedom to decide what to work on,
including the freedom to compete with the GNU project, but
it's a shame when they make that choice. The whole community
loses when someone chooses competition rather than
cooperation.
<p>But this is worse than competition--it is unfair
competition. The XEmacs developers can and do copy code they
like from Emacs. If I could copy the code I like from XEmacs
in the same way, at least the rivalry would be fair. But I
can't do that't, because substantial parts of XEmacs don't
have legal papers, or don't have known authors.
<p>As long as we cannot use XEmacs in the GNU system, the GNU
project has to make sure that Emacs is not left behind. In
other words, we have to behave like rivals too, even though we
wish there were no rivalry. When XEmacs developers try to
persuade people to use, test, fix and enhance XEmacs instead
of Emacs, the GNU project can't sit still; we need them to
use, test, fix and enhance Emacs instead.
<p>There is good code in XEmacs, which I'd be happy to have in
a merged Emacs any day. But I cannot copy it out of XEmacs
myself because of the uncertain authorship and/or lack of
legal papers.
<p>This problem could probably be resolved, at least for large
parts of XEmacs, with substantial help from the authors of
that code. Otherwise, the GNU project has to write or find
replacements for it.
<p>I invite people who like Emacs, and want the best possible
version of Emacs to be available for use in the GNU system, to
help in one way or the other.
</blockquote>
<!-- #### This really isn't source for the RMS quote. Obsolete?
Does anyone know where that came from? If not, this can go.
<p><strong>Sources:</strong> <a href="http://www.xemacs.org/FAQ/">FAQ</a>
item 1.0.5, and XEmacs 21.0 NEWS file
-->
<h2>What Is the Legal Issue?</h2>
<p>There is no difference in the nature of the copyrights or
licenses of the two projects. Copyright is defined by law and
international treaty, and is automatically awarded to the
author as soon as a work is published. Both projects use the
GNU General Public License to protect their work while
providing it freely to the community.
<p>XEmacs has no choice, because much of its code is
copyrighted by the Free Software Foundation, and is only
available to XEmacs under the GPL. Under that license,
redistribution is only possible under the GPL. The GNU
Project uses the GPL as a matter of principle. (XEmacs
developers generally subscribe to a similar principle, of
course.) It is the same GPL, so sharing code is 100% legal.
<p>However, copyright is governed by the <em>civil</em> code,
not the criminal code. This means that the government takes
no interest in violations of copyright as such. It only
undertakes to provide law courts where the copyright can be
enforced. It is the responsibility of the copyright holder to
sue to prevent violations and receive damages for past
violations. The government <em>cannot</em> act on the
complaints of third parties.
<p>The FSF has received legal advice that a copyright holder
in a jointly-authored work is in a weak position to enforce
its copyright unless all coauthors participate in the legal
action. Evidently the FSF would be considered a third party
with respect to non-assigned code, weakening its ability to
defend the whole work. (Author's note: You'd have to ask a
lawyer why that might be so. I am not an expert, so I will
just assure you that some lawyers I have asked informally
agree that this theory is plausible, although it has not been
tested in court. It may also be more or less applicable in
jurisdictions other than the U.S.)
<p>Based on this advice, Stallman has concluded that
incorporating <em>some</em> code copyrighted by another entity
into a work such as Emacs puts the copyright of <em>all</em>
of the work at risk of being unenforceable in court in the
case of a violation. He has judged that this risk is
unacceptably large, and therefore insists that the whole
copyright of any software the FSF undertakes to defend be
assigned to the FSF, with few exceptions.
<h3>What Is the Role of the FSF?</h3>
<p>Stallman believes that copyright in software itself is
immoral; Copyleft is a device to undermine the whole idea. He
has little empathy for people who wish to retain
copyright---after all, he has given up his own. This is the
fundamental idea behind the FSF (as opposed to the GNU
Project, which actually develops software): a holding company
for all the software copyrights that shouldn't even exist in
the first place. According to the legal argument above, such
a trust is necessary to defend the GPL, which is what prevents
proprietary firms from misappropriating the software at the
same time as it prevents the holding company (the FSF) from
being a monopoly.
<h2>Well, Isn't That Paranoid?</h2>
<p>Many developers think so, but it seems that noone who holds
a different theory has retained a lawyer to check the
precedents. The FSF has done so, so its position must be
considered most credible.
<p>Also, it is important to remember that Stallman and the FSF
are not (in this context) acting as software developers. Rather,
they perceive themselves as guardians of a social movement.
Their responsibility is not to any one application or project,
but to the whole GNU system. For that reason as well, a
conservative approach can be justified.
<h2>Don't the XEmacs Developers Care?</h2>
<p>Of course we do. But even if we haven't consulted a
lawyer, we have the right to judge the risks to our own
product. Most of us consider it low. Furthermore, many
XEmacs developers take a different approach to the free
software movement itself, and so will differ from GNU/FSF
policy. The code <em>we</em> write will remain free. What we
are possibly losing is the ability to <em>force others</em> to
make their modifications free. This is central to the GNU
Project because it is a social movement. To many developers
as individuals, it is not so crucial.
<p>This also shows why the "Viewpoints" are so different in
style. XEmacs developers consider their project from a
technical point of view, and prefer it for technical reasons.
They see their contributions to the free software movement as
stemming from their development and publication of code.
Stallman, and the FSF, consider their primary role to be more
politically and socially oriented. Thus social and legal
issues come to the fore.
<h2>Fear of Forking Considered Harmful</h2>
<p>Many XEmacs developers do not consider having multiple
implementations of some features a bad thing. The original
Lucid fork arose, as Stallman writes, because the Lucid
developers (primarily Jamie Zawinski) would not "cooperate" in
merging the Lucid code into the GNU mainline. What Stallman
does not mention is that in his vision of "cooperation" the
Lucid developers would be working under <em>his</em> direction
to merge those features that <em>he</em> wanted, making
changes to <em>their</em> code as <em>he</em> directed. This
is obvious, when you think about it; of course Stallman was
the head of the GNU Emacs project, and would reserve the right
to make final decisions. Nor is it surprising that the Lucid
developers refused. They had egos, of course.
<p>But there were also those "irreconcilable technical
differences." Both Lucid Emacs and GNU Emacs 19 were excellent
editors, but in their different ways. The Lucid developers
honestly considered GNU Emacs 19, and the merge as outlined by
Stallman, to be broken in some important ways. He, just as
honestly, considered many of the changes the Lucid developers
demanded to be broken, or at best to be fixing what wasn't
broken. A fork was inevitable. That's what free software is
for, among other things: the right to fix what's broken, and
redistribute the improvements.
<p>And a little competition may be good for you! Without the
fork, GNU Emacs 20 <em>might</em> not have added Mule, and GNU
Emacs 21 might <em>not</em> have the GUI redisplay. Who knows
when GNU Emacs will get a library packaging system? All of
these features were successfully pioneered by Lucid Emacs or
XEmacs, at times when Stallman considered them broken,
irrelevant, or low priority. Conversely, not only is XEmacs
based on GNU Emacs; part of the development effort includes
regular synchronization of features and implementations with
the mainline versions.
<p>Of course, we all think it is best when all the good code
that results can be shared:
<blockquote>
All Emacs developers are free software developers.
</blockquote>
<p>But whether or not it <em>can</em> be shared is a matter of
point of view. On a question quite extraneous to the
development process itself: how much the legal system hinders
you from effectively protecting your copyright when you
cooperate with someone unwilling to give up their copyright.
<!-- #### This next probably should go or be cut way down.
Just taking out my frustrations! -->
<h2>Author's Disclaimer</h2>
<p>I disagree strongly with the Stallman/FSF position in many
respects. However, I have tried to present the facts of the
legal issue as objectively as possible, and have some hope I
succeeded. The interpretation of why XEmacs developers as a
group do not worry about this legal issue is my own; the most
I can say is nobody on the developer's mailing list has
complained about it.
<p>Statements about what Richard Stallman believes, judges,
concludes, and so on should be taken with a grain of salt.
Nobody in their right mind, except Stallman, would pretend to
speak for him. I have found certain conjectures useful for
establishing a coherent interpretation of his actions and
statements, and have taken the liberty of making them
available to you. (Go read the NO WARRANTY section of the
GPL!)
<!-- #### This definitely will go. But isn't "pusillanious"
a wonderful word? -->
<p>Ben Wing probably thinks this is pusillanimous. I don't
care. There are plenty of venues where you can read endless
flames on these issues; with a little effort, you can probably
find some of mine. (I wouldn't bother.)
<address>
Stephen J. Turnbull <stephen(a)xemacs.org>
</address>
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
- 4 participants
- 6 comments
Re: auto-save-list-file-name
24 years, 1 month
Steve Youngs
Steve Youngs
* Troy Noble <troy.noble(a)channelpoint.com> writes:
> Steve,
> I think you're still OK... at least on NT when I set
> auto-save-list-file-prefix
> to nil, I stop getting .saves-* files in my home directory. I would assume
> the same
> is true on *nix (it's elisp). Even though there is a bogus value in
> auto-save-list-file-name, I don't think it will ever get used. It is only
> ever
> used in recover-session if igrep-find *.el lieth not.
I just did a little test...
In the scratch buffer:
(setq auto-save-list-file-prefix nil)
M-x eval-current-buffer
C-x C-f ~/temp/fred RET
C-x C-s
<bang on the keyboard repeatedly until 'auto-save-interval' expires>
The result:
,----[ ~/nil5896-slackware.mynet.pc ]
| /home/steve/temp/#fred#
| /home/steve/temp/fred
`----
Looks like it's not behaving the way it should. :-(
Interestingly,
,----[ M-x recover-session RET ]
| You set `auto-save-list-file-prefix' to disable making session files
`----
So, at one level it is working, but on another it isn't.
--
|---<Regards, Steve Youngs>-----------[GnuPG KeyID: 59E4C4B2]---|
| XEmacs - It's not just an editor... |
| It's a way of life. |
|----------------------------------<mailto:youngs＠xemacs.org>---|
- 2 participants
- 1 comments
Your Message to nathan@stc.com Re: Package Release
24 years, 1 month
postmaster＠seebeyond.com
postmaster＠seebeyond.com
A Visionary Name for a Visionary Company
On October 24, 2000 at 1:00 p.m., STC announced that we have changed our
name to SeeBeyond. The new name reflects the company's strategic role in
helping customers see beyond corporate and geographic boundaries - an
essential element of leadership in the New Economy.
To ensure no disruption in your communications with us, we encourage you to
change your contact information to reflect the following.
Your email has been forwarded to the recipeint.
In the future to contact individuals at SeeBeyond via email, please use:
currentemailname(a)seebeyond.com
We can be found on the web at:
http://www.seebeyond.com
And, effective November 1, 2000, our new stock symbol is:
SBYN
We're excited about our new name and encourage you to look for our major
national advertising campaign, which begins November 6, 2000.
Thanks for you continued support,
SeeBeyond
- 1 participants
- 0 comments