[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

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

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.

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

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...

"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