September 1999 - XEmacs-Beta - XEmacs Mailing List Archives

A few thoughts of emacs in a new era 25 years, 3 months

Emanuel Pirker

[Argh! I sent it first to the wrong address. But this msg also goes to bug-gnu-emacs]. (This mail goes to xemacs-bugs and bug-gnu-emacs as suggested in the Xemacs FAQ. I don't want to cause a flamewar, I just have a few thoughts to offer). I think Emacs (either as "the" GNU Emacs or XEmacs) is some kind of dinosaur of the early Unix days. In the last 2 years the world around free software has changed SO dramatically, that a repositionig of this really, really useful tool seems desirable. Well, I've just listed a few thoughts in no particular order (besides the last one, which seems to be controversial) -- Principal goal of development Most of Emacs' functionality is taken over by the new desktop environments such as Gnome or KDE. IMHO Emacs has always been a desktop environment. You could have no window manager, just emacs, and you'll survive. Well, that's not the point. Nobody is forced to have dired or W3 installed. Anyway, I think emacs is finished in terms of functionality. It already does too much. So I think extending it by still more extra features should not be a primary goal, but rather internationalisation, user-friendly-ness, ... (OK, this seems to be done anyway) -- Is it suitable for tomorrow's programming? Emacs is clearly a programmer's tool. It's not a word processor, it's not a rapid application development tool. It's a very sophisticated editor for hackers. While the Unix editor's world is mostly split apart vi and emacs (and some smaller things like jed, pico, or joe) I expect new tools like KDevelop or similar RADs to grab a significant market share. So the younger people who grow up with their "cool" GNOME desktop and the new tools probably won't need Emacs any more. Actually I don't know what to do about that... But we could end up with emacs disappearing at some point. -- Support for new Desktop environments A useful tool like Emacs should support both GNOME and KDE. Support for at least the session managment, drag and drop, and even look-and-feel (menubars, etc.) (I already thought about this with a friend some time ago (regarding Xemacs and KDE) but didn't start because we weren't sure of licencing issues.) -- There should be only one Emacs Come on FSF and Xemacs developers!! See how the world around us has changed. A new millenium approaches, why keep the old differences?? Settle down, merge!!! Even if there are "irreconcilable differences" - we are all engineers or computer scientist; reasonable people. Regarding Richard's statement on code without legal papers: I read in Xemacs, that it is GPLed. So what is it now? Is it really GPL (the whole thing) or are there some open issues? Anyway, forget about old differences! Let's give it a new beginning. As I stated before, the market share for Emacs as an editor will fall significantly as soon as real free RADs are out of the alpha stage. Having to emacses in rivalry is neither good for emacs itself, nor good for it's users. So again, please overcome the differences! If it helps meet somewhere! Go over all details and solve the problems! I'm not an emacs developer. I do programming, but in case of emacs, I'm just a user. However, if I could be of help, let me know. Cheers, Emanuel --------------------------------------------------------------------------- Emanuel Pirker epirker(a)edu.uni-klu.ac.at

1 participants
0 comments

Re: crash 25 years, 3 months

Michael Harnois

On 28 Sep 1999 10:25:18 +0200, Jan Vroonhof <vroonhof(a)math.ethz.ch> said: > Michael Harnois <mharnois(a)willinet.net> writes: >> This is the latest CVS. I was pulling on a scrollbar. > Did you do something that could have changed the window > structure, just before? I believe my Gnus group buffer was updating at the time. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mharnois(a)willinet.net aa0bt(a)aa0bt.ampr.org No excellent soul is exempt from a mixture of madness. -- Aristotle

1 participants
0 comments

Re: And now, for an exploding XEmacs 25 years, 3 months

Jan Vroonhof

Olivier Galibert <galibert(a)pobox.com> writes: > Now the portable dumper dumps the data, and when restarting loads the > data, relocate/relink everything, and nicely bombs in > init_console_stream. Even with both my changes to get it to the actual dump case it crashes in the dump Dumping under the name xemacs Fatal error: assertion failed, file alloc.c, line 4206, !pdump_get_entry(obj) Abort - core dumped This is the backtrace #1 0xef03a5e8 in abort () #2 0x6b1c4 in pdump_register_sub () #3 0x6be1c in pdump_register_object () #4 0x6b464 in pdump_register_sub () #5 0x6ba60 in pdump_register_sub () #6 0x6ba60 in pdump_register_sub () #7 0x6d83c in pdump () #8 0xe4cf4 in Fdump_emacs () Note that this is Solaris CC with the default CC flags, i.e. inlining and not debug symbols. This explains why pdump_add_entry does not appear in the backtrace although the insert is there. I have no time left. In an attempt to be usefull I changed the code around that assert to read static void pdump_backtrace(void); static void pdump_add_entry(pdump_entry_list *list, const void *obj, size_t size, int is_lrecord) { pdump_entry_list_elmt *e; int align; if (pdump_get_entry(obj)) { pdump_backtrace(); assert (!pdump_get_entry(obj)); } This then gives Dumping under the name xemacs pdump backtrace : - ind. (0, 0) - ind. (1, 4) - ind. (0, 4) - subr (0, 12) Fatal error: assertion failed, file alloc.c, line 4211, !pdump_get_entry(obj) Abort I hope this output is meaningfull to you Jan uname -a: SunOS bolzano 5.5.1 Generic_103640-08 sun4u sparc SUNW,Ultra-1 /configure '--prefix=/scratch/vroonhof/xe205' '--with-site-lisp' '-with-gcc=no' '--with-mule=yes' '--with-workshop=no' '--site-libraries=/usr/local/lib:/u/scratch/jvsoft/lib:/u/scratch/jvsoft/canna/lib' '--site-runtime-libraries=/usr/local/lib:/u/scratch/jvsoft/lib:/u/scratch/jvsoft/canna/lib' '--site-includes=/usr/local/app/libpng/1.0.3/include/:/usr/local/include:/u/scratch/jvsoft/include:/u/scratch/jvsoft/canna/include' XEmacs 21.1.6 "Big Bend" configured for `sparc-sun-solaris2.5.1'. Where should the build process find the source code? /scratch/vroonhof/cvs/xemacs-20 What installation prefix should install use? /scratch/vroonhof/xe205 What operating system and machine description files should XEmacs use? `s/sol2.h' and `m/sparc.h' What compiler should XEmacs be built with? cc -v -xO4 Should XEmacs use the GNU version of malloc? yes 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/dt/include /usr/local/X11/include Where do we find X Windows libraries? /usr/dt/lib /usr/local/X11/lib Additional header files: /usr/local/app/libpng/1.0.3/include/ /usr/local/include /u/scratch/jvsoft/include /u/scratch/jvsoft/canna/include Additional libraries: /usr/local/lib /u/scratch/jvsoft/lib /u/scratch/jvsoft/canna/lib Runtime library search path: /usr/local/lib:/u/scratch/jvsoft/lib:/u/scratch/jvsoft/canna/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 X-Face message headers. Compiling in support for Berkeley DB. Compiling in support for DBM. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using Motif to provide XIM support. Compiling in support for Canna on Mule. Compiling in support for ToolTalk. 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.

2 participants
1 comments

Re: And now, for an exploding XEmacs 25 years, 3 months

Jan Vroonhof

Olivier Galibert <galibert(a)pobox.com> writes: > Destroy-your-own-xemacs-HOWTO: > - compile with --pdump > - see the "xemacs not found" error message > - see that there is a new src/xemacs.dmp file BWAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHA It is even easier than that. temacs will crash on you with a nice triple fault trying "run-temacs" to bytecompile the lisp. I needed #ifdef PDUMP { extern int pdump_load(void); initialized = restart || pdump_load(); } #endif and #endif #ifdef PDUMP } else if (!restart) { reinit_alloc_once_early (); reinit_opaque_once_early (); in order to get it to byte-compile the initial lisp (which is where it is now). Jan

1 participants
0 comments

Re: And now, for an exploding XEmacs 25 years, 3 months

Jan Vroonhof

Olivier Galibert <galibert(a)pobox.com> writes: > Index: src/lisp.h > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/src/lisp.h,v > retrieving revision 1.38.2.24 > diff -u -r1.38.2.24 lisp.h > --- lisp.h 1999/09/28 00:42:57 1.38.2.24 > +++ lisp.h 1999/09/28 14:08:03 > ＠＠ -52,7 +52,8 ＠＠ > int elsize; \ > int cur; \ > int largest; \ > - int max > + int max; \ > + int dumped; I am compiling it now. However I had to removed that last semi-colon for Solaris CC to not barf. Jan

2 participants
1 comments

And now, for an exploding XEmacs 25 years, 3 months

Olivier Galibert

Now the portable dumper dumps the data, and when restarting loads the data, relocate/relink everything, and nicely bombs in init_console_stream. Destroy-your-own-xemacs-HOWTO: - compile with --pdump - see the "xemacs not found" error message - see that there is a new src/xemacs.dmp file - do cd src; temacs - look at the nice core If you compile without --pdump, everything works as usual. It would be nice if a windows developer would try to compile with --pdump. I _tried_ to do it right, but I don't know what the level of support of open/read/write/close is. The next step is having it go through init_console_stream. The problem is, I don't understand yet what should and shouldn't be done. The situation is a bit weird, with initialize=1, all dumped variables available, but with Vterminal_{console,device,frame} not dumped. For now it breaks on Fset('device, device *) with 'device unbounded. Any help or hints about how it should work welcome. OG. PS: This includes my two prevoius patches too. 1999-09-28 Olivier Galibert <galibert(a)pobox.com> * symsinit.h: Added lots of prototypes. * symeval.h: Added defsymbol_nodump declaration. * symbols.c (find_symbol_value): Lame attempt at making the startup go further. (defsymbol_nodump): Added. * mule-charset.c: Collapsed global lisp objects arrays in one dumpable structure. * lrecord.h: Added some flags. * lisp.h: Added dumped flag to dynarrs. Added dumpstruct declaration. * glyphs.h (INITIALIZE_IMAGE_INSTANTIATOR_FORMAT_NO_SYM): Don't staticpro dynamic variables. * glyphs.c (reinit_specifier_type_create_image): Added. (image_instantiator_format_create): Dump image instantiator format dynarr. (reinit_image_instantiator_format_create): Added. * emacs.c (main_1): Added reinits calls. * dynarr.c: Protect dumped dynarrays from going berzek in free or realloc. * specifier.h (INITIALIZE_SPECIFIER_TYPE): Don't staticpro dynamic variables. * specifier.c (specifier_type_create): Dump the specifier type dynarr. (reinit_specifier_type_create): Added. * console.h (INITIALIZE_CONSOLE_TYPE): Don't staticpro dynamic variables. * console.c (console_type_create): Dump the console type dynarr. (reinit_vars_of_console): Extracted from vars_of_console. (reinit_complex_vars_of_console): Extracted from complex_vars_of_console * window.c (reinit_vars_of_window): Extracted from vars_of_window. * toolbar.c (reinit_specifier_type_create_toolbar): Added. * search.c (reinit_vars_of_search): Extracted from vars_of_search. * objects.c (reinit_specifier_type_create_objects): Added. (reinit_vars_of_objects): Extracted from vars_of_objects. * lstream.c (reinit_vars_of_lstream): Extracted from vars_of_lstream. * lread.c (reinit_vars_of_lread): Extracted from vars_of_lread. * gutter.c (reinit_specifier_type_create_gutter): Added. * glyphs-x.c (reinit_image_instantiator_format_create_glyphs_x): Added. * glyphs-widget.c (reinit_image_instantiator_format_create_glyphs_widget): Added * glyphs-msw.c (reinit_image_instantiator_format_create_glyphs_mswindows): Added. * glyphs-eimage.c (reinit_image_instantiator_format_create_glyphs_eimage): Added. * event-stream.c (reinit_vars_of_event_stream): Extracted from vars_of_event_stream * eval.c (reinit_vars_of_eval): Extracted from vars_of_eval. * device.c (reinit_vars_of_device): Extracted from vars_of_device. * console-x.c (reinit_console_type_create_x): Added. * console-tty.c (reinit_console_type_create_tty): Added * console-stream.c (reinit_console_type_create_stream): Added. (init_console_stream): If PDUMP, always reinitialise basic devices. * console-msw.c (reinit_console_type_create_mswindows): Added. * buffer.c (reinit_vars_of_buffer): Extracted from init_vars_of_buffer. (reinit_complex_vars_of_buffer): Extracted from complex_vars_of_buffer * alloc.c: Further with the portable dumping, the revenge. (dumpstruct): Added. (reinit_alloc_once_early): Extracted from init_alloc_once_early. * specifier.c (sizeof_specifier): Correct size computation. (make_specifier_internal): Ditto. 1999-09-27 Olivier Galibert <galibert(a)pobox.com> * alloc.c: Further with the portable dumping.

1 participants
0 comments

[off topic] question about gap storage and positions in xemacs 25 years, 3 months

Stef Epardaud

hi all, this is not the purpose of the mailing list, i know, but i'd like to know more about the way xemacs stores the buffer's content. i heard that it was keeping a kind of gap buffer, which is like an array with a gap where the editing of text is taking place. so everytime edition takes place, the gap moves to where it occurs and becomes smaller as the text is inserted. this saves a lot of memory allocating and moving as well. now assuming all this is true and i'm not going the wrong route, i know there are position objects, marks, markers or such, that represent an offset in the storage object (gap buffer), and these positions get updated when the gap shifts or resizes, or when the gap buffer is resized itself. that'd be my guess that all these markers are kept at some place within the gap buffer so that it knows when to update them, and how. the reason i'm asking all this is that i'm currently writing an app that uses this kind of storage (in java ... don't laugh...) and i'm having some problems with the way these marks are updated. is there any place in the xemacs documentation where i can find more info on this, or a book about that kind of things or even one of you who knows the subject well enough and would be kind enough to answer some questions ? i'm not going to put my questions here, unless someone would answer them or finds the topic interresting. sorry if i'm polluting this mailinglist :) just don't answer if this is not interresting. thanx. -- # Stef Epardaud, # There is no limit to the power of computing ... # Java Defeater # ... except men maybe ? # Earth # Lunatech Research, # Solar System # soon we will quit researching and start finding...

1 participants
0 comments

Re: Is there still lost traffic on xemacs-patches? 25 years, 3 months

Jan Vroonhof

"Horning, Jim" <jim.horning(a)lmco.com> writes: > For sometime I have noticed that I do not get all the traffic on the > xemacs-patches list. There were some messages a while back with regards to > problems on xemacs-patches listserv and I had attributed it to that. Is > this still the case? No that is supposed to be fixed. Jan

1 participants
0 comments

Re: crash 25 years, 3 months

Jan Vroonhof

Michael Harnois <mharnois(a)willinet.net> writes: > This is the latest CVS. I was pulling on a scrollbar. Did you do something that could have changed the window structure, just before? Jan

1 participants
0 comments

Re: 64-bit cleanliness 25 years, 3 months

Olivier Galibert

On Mon, Sep 27, 1999 at 10:12:25PM -0400, Olivier Galibert wrote: > Let's see... hmmm... yes, I still have access. Ok, gonna try. Huh hoh. I'm knee-deep in the dumping code right now, so I'm not going to try to fix that. I'll try patches if you want though. I'm keeping the core around, too. cc-3187 cc: WARNING File = /global/tempo/galibert/xemacs/src/glyphs.c, Line = 4076 A pointer is converted to a smaller integer. return make_int ((int) XIMAGE_INSTANCE_SUBWINDOW_ID (subwindow)); ^ cc-3187 cc: WARNING File = /global/tempo/galibert/xemacs/src/redisplay-output.c, Line = 1402 A pointer is converted to a smaller integer. (int)IMAGE_INSTANCE_PIXMAP_MASK (p)); ^ Fatal error (10). 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 the information in the command M-x describe-installation. 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 the editor, or maybe in your home directory), and type gdb /global/tempo/galibert/x/src/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: # (unwind-protect ...) # (catch #<INTERNAL OBJECT (XEmacs bug?) (opaque_ptr, adr=0x1037ddf0) 0x104866e0> ...) # (unwind-protect ...) # (unwind-protect ...) # (condition-case ... . error) # (catch top-level ...) Bus error (core dumped) dbx version 7.3 57895_Aug10 patchSG0003707 Aug 10 1999 02:39:58 Core from signal SIGBUS: Bus error (dbx) where > 0 _kill(0x6dcc0, 0xa, 0x10373a00, 0x0, 0x10425e48, 0x0, 0x10425e4c, 0x10433808) ["/xlv51/6.5.5f/work/irix/lib/libc/libc_64_M4/signal/kill.s":15, 0xda5cc98] 1 fatal_error_signal(sig = 10) ["/global/tempo/galibert/xemacs/src/emacs.c":276, 0x100b4d50] 2 _sigtramp(0xa, 0xa, 0xffffff8d90, 0x0, 0x10425e48, 0x0, 0x10425e4c, 0x10433808) ["/xlv51/6.5.5f/work/irix/lib/libc/libc_64_M4/signal/sigtramp.s":71, 0xda5d13c] 3 SetImagePixels32(0x4, 0x10957004, 0x30, 0x10954008, 0x108aa600, 0x109570c0, 0x10957000, 0x0) ["/xlv47/6.5.5m/work/vk/Xpm/src-64/create.c":1169, 0xc369118] 4 XpmCreateImageFromXpmImage(0x10844000, 0xffffff9258, 0xffffff92e0, 0xffffff92e8, 0xffffff93b8, 0x109570c0, 0x10957000, 0x0) ["/xlv47/6.5.5m/work/vk/Xpm/src-64/create.c":737, 0xc3685f4] 5 XpmCreateImageFromBuffer(0x10844000, 0x10573020, 0xffffff92e0, 0xffffff92e8, 0xffffff93b8, 0x109570c0, 0x10957000, 0x0) ["/xlv47/6.5.5m/work/vk/Xpm/src-64/CrIFrBuf.c":64, 0xc364f58] 6 XpmCreatePixmapFromBuffer(0x10844000, 0x6400006, 0x30, 0xffffff9470, 0xffffff9378, 0x109570c0, 0x10957000, 0x0) ["/xlv47/6.5.5m/work/vk/Xpm/src-64/CrPFrBuf.c":57, 0xc36538c] 7 x_xpm_instantiate(image_instance = 278050560, instantiator = 274144384, pointer_fg = 272840712, pointer_bg = 272840712, dest_mask = 13, domain = 277241856) ["/global/tempo/galibert/xemacs/src/glyphs-x.c":1307, 0x102b2f8c] 8 instantiate_image_instantiator(device = 277024256, domain = 277241856, instantiator = 274144384, pointer_fg = 272840712, pointer_bg = 272840712, dest_mask = 13) ["/global/tempo/galibert/xemacs/src/glyphs.c":603, 0x1019ce44] 9 image_instantiate(specifier = 273356800, matchspec = 271988912, domain = 277241856, instantiator = 274144384, depth = 3) ["/global/tempo/galibert/xemacs/src/glyphs.c":2553, 0x101a407c] 10 call_with_suspended_errors_1(opaque_arg = 273180192) ["/global/tempo/galibert/xemacs/src/eval.c":2062, 0x100c0754] 11 internal_catch(tag = 273180384, func = 0x100c0590, arg = 273180192, threw = 0xffffff9d50) ["/global/tempo/galibert/xemacs/src/eval.c":1321, 0x100be8ac] 12 call_with_suspended_errors(fun = 0x101a3860, retval = 271988912, class = 273091912, errb = struct _error_behavior_struct_ { really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 42 }, nargs = 5, ... = <void>) ["/global/tempo/galibert/xemacs/src/eval.c":2174, 0x100c0f0c] 13 specifier_instance_from_inst_list(specifier = 273356800, matchspec = 271988912, domain = 277241856, inst_list = 274322208, errb = struct _error_behavior_struct_ { really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 3333632 }, no_quit = 0, depth = 3) ["/global/tempo/galibert/xemacs/src/specifier.c":2422, 0x102747e4] 14 specifier_instance(specifier = 273356800, matchspec = 271988912, domain = 277241856, errb = struct _error_behavior_struct_ { really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 3333632 }, no_quit = 0, no_fallback = 0, depth = 3) ["/global/tempo/galibert/xemacs/src/specifier.c":2537, 0x10274ecc] 15 glyph_image_instance(glyph = 273382528, domain = 277241856, errb = struct _error_behavior_struct_ { really_unlikely_name_to_have_accidentally_in_a_non_errb_structure = 3333632 }, no_quit = 0) ["/global/tempo/galibert/xemacs/src/glyphs.c":3304, 0x101a64b8] 16 update_frame_icon(f = 0x10866000) ["/global/tempo/galibert/xemacs/src/frame.c":3045, 0x10198488] 17 redisplay_device(d = 0x10830e00) ["/global/tempo/galibert/xemacs/src/redisplay.c":6420, 0x102309fc] 18 redisplay_without_hooks() ["/global/tempo/galibert/xemacs/src/redisplay.c":6549, 0x10231558] 19 redisplay() ["/global/tempo/galibert/xemacs/src/redisplay.c":6619, 0x10231810] 20 Fnext_event(event = 278128648, prompt = 272840712) ["/global/tempo/galibert/xemacs/src/event-stream.c":2236, 0x1013d190] 21 Fcommand_loop_1() ["/global/tempo/galibert/xemacs/src/cmdloop.c":566, 0x100866f0] 22 command_loop_1(dummy = 272840712) ["/global/tempo/galibert/xemacs/src/cmdloop.c":490, 0x100862f8] 23 condition_case_1(handlers = 272840904, bfun = 0x100862b0, barg = 272840712, hfun = 0x10085590, harg = 272840712) ["/global/tempo/galibert/xemacs/src/eval.c":1646, 0x100bef64] 24 command_loop_3() ["/global/tempo/galibert/xemacs/src/cmdloop.c":252, 0x10085794] 25 command_loop_2(dummy = 272840712) ["/global/tempo/galibert/xemacs/src/cmdloop.c":263, 0x100857f4] 26 internal_catch(tag = 272999176, func = 0x100857d0, arg = 272840712, threw = (nil)) ["/global/tempo/galibert/xemacs/src/eval.c":1321, 0x100be8ac] 27 initial_command_loop(load_me = 272840712) ["/global/tempo/galibert/xemacs/src/cmdloop.c":301, 0x10085bb4] 28 xemacs_21_2_b19_mips_sgi_irix6_5(argc = 1, argv = 0xffffffad98, envp = 0xffffffada8, restart = 0) ["/global/tempo/galibert/xemacs/src/emacs.c":1762, 0x100b6fc8] 29 main(argc = 1, argv = 0xffffffad98, envp = 0xffffffada8) ["/global/tempo/galibert/xemacs/src/emacs.c":2187, 0x100b8020] 30 __start() ["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_64_M4/csu/crt1text.s":177, 0x1004dcd8] uname -a: IRIX64 vic 6.5 07151439 IP27 ../xemacs/configure '--with-mule' '--with-gcc=no' '--cflags=-64 -g' XEmacs 21.2-b19 "Shinjuku" configured for `mips-sgi-irix6.5'. Where should the build process find the source code? /global/tempo/galibert/xemacs What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/irix6-0.h' and `m/iris4d.h' What compiler should XEmacs be built with? cc -64 -g Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? Where do we find X Windows libraries? Compiling in support for XAUTH. Compiling in support for XPM images. -------------------------------------------------------------------- WARNING: Compiling without PNG image support. WARNING: You should strongly consider installing the PNG libraries. WARNING: Otherwise certain images and glyphs may not display. WARNING: (a copy may be found in ftp://ftp.xemacs.org/pub/xemacs/aux) -------------------------------------------------------------------- Compiling in support for (builtin) GIF image handling. Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for DBM. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using Motif to provide XIM support. Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Using Motif native widgets. Using Motif dialog boxes. Compiling in DSO module support. movemail will use "dot-locking" for locking mail spool files. Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: ---------------------------------------------------------

2 participants
1 comments

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 September 1999