February 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Nifty icons for XEmacs? 25 years, 9 months

Jan Vroonhof

SL Baur <steve(a)xemacs.org> writes: > Has the copyright situation on the Nextstep icons been cleared up so > this can become an official XEmacs package? I think jonathan gave his OK for us to distribute the icons (under the GPL) of course. I cannot find his e-mail at the moment though, so let's ask him again to be sure. Jonathan? Jan

1 participants
0 comments

Re: XEmacs 21.2.10 on AIX 4.3.1 ??? 25 years, 9 months

Michael Sperber

>>>>> "Derek" == Derek Scherger <derek(a)echologic.com> writes: Derek> The linker was complaining... when I tried to reproduce it with the Derek> following configuration it doesn't happen anymore. :( *How* was it complaining? A loadmap would help. Derek> gdb doesn't like the core file and it seems small to me but I have Derek> ulimit -c unlimited set... so I can't get a stack trace. Start temacs inside gdb or dbx then. What about runnable-temacs, anyway? Without more information, there's very little we can do. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: Moving part of mule-base back into the XEmacs core (was Re: Building packages from source not quite possible) 25 years, 9 months

SL Baur

Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes in xemacs-beta(a)xemacs.org: ... > That list of extra files is awf'l long; why do we need ethiopian.el > (among others)? We don't need some of them. Anything that is currently commented out in dumped-lisp.el is hopelessly (for the moment) broken. This includes ethiopic.el and thai.el to name two. I'm probably not going to copy those files into 21.0. On general principles, they probably _should_ get copied into 21.2. > (I know, I know, interfile dependencies.) Is it worth trying to > clean that up? For 21.0/1, no. Once 21.0 is out of the way and I start looking at Mule 3.0 API issues, it's on the table.

1 participants
0 comments

Re: Moving part of mule-base back into the XEmacs core (was Re: Building packages from source not quite possible) 25 years, 9 months

Didier Verna

SL Baur writes: SL> O.K. The dump-time Mule stuffs[1] get moved back into the core. This means SL> the grundgy code in core autoloads generation has got to be restored so SL> that autoloads generation doesn't blow chunks when run with a non-Mule SL> XEmacs binary. I can move the restored mule files into their own SL> subdirectory (lisp/mule), or ensure that they all have a mule- prefix. Any SL> preferences as to which? Yes. lisp/mule is nice. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

2 participants
1 comments

Re: --no-split and XEmacs mode 25 years, 9 months

Didier Verna

Richard, in general, when we work on code that's incorporated in both flavors of Emacs, we (the XEmacs development team) always make a big deal keeping things synchronized. You know this because there's often been discussion (even recently) between you and us about code that we have in common. As far as this particular case is concerned, there are two things I'd like you to know: 1/ As suggests the line ";;; Synched up with: Not synched with FSF." at the top of our info.el (though I couldn't tell whether it's simply outdated, or just different), our code probably differs from yours a lot so I don't consider it /that/ important to inform you that the XEmacs' info.el has a bug. Maybe it would be interesting to try to re-synchronized the stuff, but I'm not the most competent person to decide on this in the XDT. 2/ In XEmacs, it happens that different people are responsible for different packages or files. I'm not the last person to have touched to info.el in XEmacs and other people know about this file better than I. When I patch a file on which my knowledge isn't complete, my policy is to submit it (as I did), wait for an approvement, and /then/ deal with the secondary problems, like figure out whether you could need the same patch or not. You wrote this to me: Richard> This illustrates a general point: if you test things in XEmacs, and Richard> you debug bugs in XEmacs, you'll help the XEmacs developers, but most Richard> of the time you won't help the GNU Project develop Emacs. and just before, you wrote: Richard> The code you're working on doesn't seem to be the same as what's in Richard> Emacs at that point. Maybe we fixed this bug already. If you fixed the bug in GNU Emacs, then you didn't signal it to us since we still have it. In other words you're reproaching me to help XEmacs and not GNU Emacs, but you're appearently not willing to behave this way towards us. I always help the GNU project when I can (there are several other GNU software which I contribute to), but I'd like to notice that the converse is true. Richard> If you'd like to help both versions' developers, you'd need to look Richard> at the code of both versions, and try both. That's what I do in general, yes. Thanks for the idea :-) -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

2 participants
1 comments

beta schedules, 21.0 showstoppers 25 years, 9 months

SL Baur

Starting today, weekly betas will be resuming. There should be both 21.0 and 21.2 releases made, though I may hold off the next 21.0 until Monday pending (re)receipt of a Michael Sperber AIX build fix. 21.0 is going to be formally released just as soon as we can do it. Bug fixing will continue on that tree as 21.1.X until the 21.2 tree is releasable. Currently, 21.2 fails to build for me on the box I'm doing development on. There are currently four identified showstoppers: Build problems on BSD 4/SGI Irix. Martin has identified these problems and is working on fixes. Multilingual menubars are overly sensitive to the exact text name of the locale. For example, LANG=ja yields Japanese menubars, LANG=ja_JP does not. XEmacs can be trivially crashed by cutting and pasting from a DECterm. This problem has been identified as corruption of sorts of the X selection -- XEmacs thinks it is being passed a composed character, but the character composition code isn't fully implemented yet. If noone else can reproduce this, it may be downgraded since compose characters are now on the list of things to get implemented by 21.2.

4 participants
4 comments

Moving part of mule-base back into the XEmacs core (was Re: Building packages from source not quite possible) 25 years, 9 months

SL Baur

David Starks-Browning <starksb(a)ebi.ac.uk> writes in xemacs-beta(a)xemacs.org: > On 12 Feb 99, Carsten Leonhardt writes: >> The files that are loaded from mule-base during dumping are only a >> subset of the contents of the mule-base package. They are 193kb >> uncompressed, 43603 bytes tared & gzipped. Does that size warrant >> these complications? (And the non-Mulers get the *.c files, anyway) > Speaking as a new xemacs user struggling with these issues... > If these size statistics are correct, I would be very happy as a > non-mule user to get this amount of extra baggage, if it meant > avoiding the complications for mule-users. O.K. The dump-time Mule stuffs[1] get moved back into the core. This means the grundgy code in core autoloads generation has got to be restored so that autoloads generation doesn't blow chunks when run with a non-Mule XEmacs binary. I can move the restored mule files into their own subdirectory (lisp/mule), or ensure that they all have a mule- prefix. Any preferences as to which? Footnotes: [1] Specifically mule-charset.el, mule-coding.el, mule-files.el, mule-help.el, mule-category.el, mule-ccl.el, mule-misc.el, kinsoku.el, mule-x-init.el, mule-tty-init.el, mule-cmds.el, arabic.el, chinese.el, cyrillic.el, english.el, ethiopic.el, european.el, greek.el, hebrew.el, japanese.el, korean.el, misc-lang.el, thai.el, viet-chars.el, vietnamese.el, canna-leim.el, and mule-init.el.

1 participants
0 comments

Re: Building packages from source not quite possible 25 years, 9 months

SL Baur

Carsten Leonhardt <leo(a)arioch.oche.de> writes in xemacs-beta(a)xemacs.org: ... > I just found out it fails for me (with Stephen Turnbull's hints > leading the way). I build the packages (from a clean source) with > make STAGING=/home/xemacs/package-staging bindist > The bindist rule doesn't build the autoloads beforehand (like "make > all" does), and therefore fails like that. O.K. That's a bug and a fix will be put in CVS shortly. > Maybe one should have a target "autoloads", and have bindist depend on > that. Doing a "make all; make bindist" sucks, because then some > packages get bytecompiled twice, Nothing should be bytecompiled twice. At least nothing that was successfully built should be bytecompiled twice. > and it takes long enough already. This is always going to suck and it is only going to get worse over time as more things get added. The solution is to either use the prebuilt stuff, resign yourself to the long build time or get a faster machine. On a 450MHz Pentium II it takes about 15 minutes to rebuild all the packages from scratch.

1 participants
0 comments

Re: Building packages from source not quite possible 25 years, 9 months

SL Baur

Carsten Leonhardt <leo(a)arioch.oche.de> writes in xemacs-beta(a)xemacs.org: > I think it's rather annoying not to be able to build all of the > packages from a clean source, with no other help than XEmacs itself. This is mostly possible. If it's not true it's a bug to be fixed. The sole exception[1] is that building with Mule requires the mule-base package to be available. I am considering splitting mule-base apart and remerging the required Mule files to the core. > The problem is that building tm depends on being able to load the > auto-autoloads from rmail, and vice-versa. As a result, bbdb can't be > built, as this depends on the auto-autoloads from tm. This should be fixed already. The autoloads files are now generated in a separate pass to eliminate the circular dependencies. > IIRC, you also need the texinfo package already available beforehand, > so that the info-files that makeinfo can't handle can be built. Maybe > the texinfo package should be taken from where the packages are being > built at the time. Right. > And (I probably repeat myself here) I think that no lisp from any > packages should be necessary to build the XEmacs binary. I.e. all lisp > needed to build should be included in the XEmacs-core sources. I agree. Footnotes: [1] After adding `LANG=C' to XEmacs.rules to fix the problem with building from non-English locales.

1 participants
0 comments

Re: Error in text-modes package [was [comp.emacs.xemacs] exporting ...] 25 years, 9 months

SL Baur

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes in xemacs-beta(a)xemacs.org: > I think there is an error in the package makefile for the text-modes > package. It forgets to copy htmlize.el which is clearly supposed to be > in there. Yup. Fixed in the next revision.

1 participants
0 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 February 1999