December 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: the splash buffer 25 years, 11 months

Colin Rafferty

Didier Verna writes: > Stephen J Turnbull writes: > :-). I've thought about this a bit more, and look: suppose Joe User > hacks its X11 resources and sets the default frame geometry to 10 lines. When > starting XEmacs, almost all of the splash buffer, including copyrights, will > be hidden. Is XEmacs becoming illegal, then? No. The user has chosen to start up in an "unusual" way, which inherently short-circuits the copyrights. The user could also run it -batch, or even with a file arugment, and we don't get the copyrights. > And is it different from not > being able to display everything in a terminal? Yes. Starting up in a terminal is an expected way to use it. Of course, so is starting with a file. Stephen> A variation on the theme would be to do a Java-ized Web-advert-style Stephen> "rotating text" using timers. > I've had this in mind for a long time too. I like that idea a lot. Way cool. -- Colin

1 participants
0 comments

Re: the splash buffer 25 years, 11 months

Didier Verna

Stephen J Turnbull writes: >>>>>> "dv" == Didier Verna <verna(a)inf.enst.fr> writes: dv> I'm afraid you're right. Now, maybe we can avoid printing them all (there dv> are currently 5). [...] Maybe I'll ask RMS about this. Stephen> Another possibility would be to use the echo area as a marquee the Stephen> way VM does. I doubt it's satisfactory, but you could ask RMS (but Stephen> mentioning VM as the inspiration is probably not a good idea ;-) :-). I've thought about this a bit more, and look: suppose Joe User hacks its X11 resources and sets the default frame geometry to 10 lines. When starting XEmacs, almost all of the splash buffer, including copyrights, will be hidden. Is XEmacs becoming illegal, then? And is it different from not being able to display everything in a terminal? Stallmacs fails to display the copyrights in that case. I'm waiting for an answer from rms on this. Stephen> A variation on the theme would be to do a Java-ized Web-advert-style Stephen> "rotating text" using timers. What I have in mind is that the splash Stephen> buffer comes up with the full set of copyrights and help stuff Stephen> together, then rotates them en bloc every 5 seconds in the buffer. I've had this in mind for a long time too. Stephen> I wish I had time to implement, just to see if it looks good :-( Telepathic skills? ;-) Stephen> Heck, if it were cool enough, people might never deselect the splash Stephen> buffer :-) `(turn-on-permanent-buffer)' ;-) -- / / _ _ 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

1 participants
0 comments

XEmacs 21.2.5 "Aphrodite" is released 25 years, 11 months

SL Baur

Get it from the usual places: http://cvs.xemacs.org/ ftp://ftp.xemacs.org/pub/xemacs/beta/xemacs-21.2/ Builds for distribution are now being done on cvs.xemacs.org. The noticeable changes from this are that that machine does not yet have a complete XEmacs maintainer-friendly environment, but it's close. The .tar.gz's are back. There are no PGP signatures because we don't have a functional PGP or the equivalent yet. This build drops core immediately for me, though it may last longer for others. After building try the following: xemacs-21.2.5 -nw -q M-x find-library packages M-x font-lock-mode M-x fast-lock-mode and report the results to xemacs-beta. It drops core on both machines (Linux 2.1 and BSDI 3.0) I've built it on. If you haven't built 21.0 and are comfortable with XEmacs 21, this is definitely not for you. As of this beta, I'm forking myself off of the XEmacs 21.2 branch to concentrate what little time I have on 21.0. Report all bugs and problems to xemacs-beta. to 21.2 beta5 "Aphrodite" -- bytecode interpreter rewritten -- byte compiler fixes -- hash table implementation rewritten -- basic lisp functions rewritten -- spelling fixes -- garbage collector tuned a little -- various global code changes for consistency -- automated test suite -- major internals manual updates -- lisp reference updates to 21.2 beta4 "Aglaophonos" -- isearch keymap fix from Katsumi Yamaoka -- directory_files cleanup from Hrvoje Niksic -- C implementation of base64 from Hrvoje Niksic -- C implementation of `buffer-substring-no-properties' from Hrvoje Niksic -- Experimental fix for spurious `file has changed on disk' message from Charles Waldman -- Fix for etags.el hook calling from Malcolm Box -- User-name-completion fix for MS Windows NT from Greg Klanderman

2 participants
1 comments

Re: [Q] CVS archive tag 25 years, 11 months

Adrian Aichner

>>>>> "Didier" == Didier Verna <verna(a)inf.enst.fr> writes: Didier> I vaguely remember Steve saying that the tag for Didier> 21.2 had changed, Didier> or Didier> Didier> something. Can somebody tell me what's the status Didier> of the following Didier> information Didier> Didier> (particularily which stuff is obsolete), and what Didier> I should do to update ? Didier> Thanks. Didier> CVS/Repository: /usr/CVSroot/XEmacs/xemacs-20 The module has been renamed from xemacs-20 to plain xemacs. xemacs-20 is still there for backward compatibility, AFAIK. HTH, Adrian Didier> CVS/Root: :pserver:xemacs＠cvs.xemacs.org:/usr/CVSroot Didier> CVS/Tag: Trelease-21-2

1 participants
0 comments

RE: Distribution Build Report for XEmacs-21.0.59 25 years, 11 months

Ian MacKinnon

If you are now a 'bot does that mean you can work 24x7 and run multiple instances of yourself Presumably there is now a steve.el that does all this for Xemacs Obviously :-) --- Ian -----Original Message----- From: Steven Baur [mailto:steveb＠camelot-soft.com] Sent: 08 December 1998 19:52 To: xemacs-beta(a)xemacs.org Subject: Distribution Build Report for XEmacs-21.0.59 Greetings XEmacs beta testers. I am in the process of building the next distribution of XEmacs 21.0. I have tested the attached configuration. Sincerely, The XEmacs Build 'Bot -- uname -a: BSD/OS camelot-soft.camelot-soft.com 3.0 BSDI BSD/OS 3.0 Kernel #0: Thu Jul 17 23:30:01 PDT 1997 root＠camelot-soft.camelot-soft.com:/usr/src/sys/compile/CAMELOT i386 ../configure '--prefix=/usr/home/steveb/staging' '--cflags=-g' '--with-mule' '--without-x11' '--debug=no' '--error-checking=none' XEmacs 21.0-b59 "Poitou59" configured for `i386-pc-bsdi3.0'. Where should the build process find the source code? /usr/home/steveb/staging/xemacs-21.0 What installation prefix should install use? /usr/home/steveb/staging What operating system and machine description files should XEmacs use? `s/bsdos3.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -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? none Compiling in native sound support. Compiling in support for Berkeley DB. Compiling in support for GNU DBM. Compiling in Mule (multi-lingual) support. Compiling in DLL support. movemail will use "flock" for locking mail spool files. # Add a message to the ChangeLog files regarding the release ../UpdateLogs.zsh 21 0 59 t if [ -f xemacs-21.0/Makefile ]; then (cd xemacs-21.0; make distclean) fi # Tag the release ../CVSGraffito.zsh 21 0 59 # Prepare .tar.gzs for upload ../MakeTarballs.zsh r21-0-58 r21-0-59 21 0 59 # PGP sign everything #./PGPSign.zsh 21 0 59 # Rebuild so we have something to build packages with later ../MakeXEmacs.zsh xemacs-21.0 t t

1 participants
0 comments

Re: Distribution Build Report for XEmacs-21.0.59 25 years, 11 months

SL Baur

Steven Baur <steveb(a)camelot-soft.com> writes in xemacs-beta(a)xemacs.org: > Greetings XEmacs beta testers. I am in the process of building the next > distribution of XEmacs 21.0. I have tested the attached > configuration. > Sincerely, > The XEmacs Build 'Bot ... > movemail will use "flock" for locking mail spool files. > # Add a message to the ChangeLog files regarding the release > ./UpdateLogs.zsh 21 0 59 t > if [ -f xemacs-21.0/Makefile ]; then > (cd xemacs-21.0; make distclean) > fi ... Oops. I've just uploaded 21.0.59 to the ftp site. It is basically what has been out there for the last few weeks, but is now there with tarballs and a formal patch. Note that 21.0.58 was never fully uploaded, however if you are patching from previous versions of XEmacs 21.0, you will need the 21.0.57 -> 21.0.58 patch. I expect to make one or two releases later today with some of the accumulated patches and updated packages stuffs including a 'bot generated SUMO package tarball.

1 participants
0 comments

Parsing error for patched files in pcl-cvs 25 years, 11 months

Oscar Figueiredo

pcl-cvs (package version 1.37) still gives me a lot of parser errors on patched files. Excerpt from my last update of the XEmacs sources: Message: Parser Error: 'P ChangeLog' Message: Parser Error: 'P configure.in' CVS 1.10 Halibut on Solaris 2.5.1 Oscar

1 participants
0 comments

Re: the splash buffer 25 years, 11 months

Hrvoje Niksic

Didier Verna <verna(a)inf.enst.fr> writes: > Is it really too big a sacrifice to hide 4 useless lines of > copyright compared to the improvement in readability ? I think Didier's change is acceptable.

2 participants
1 comments

Re: the splash buffer 25 years, 11 months

Didier Verna

Kyle Jones writes: Kyle> The existing splash buffer was crafted to fit on a 24-line tty without Kyle> needing to be scrolled. This is a requirement of any new splash buffer Kyle> (dumb terminal are not dead yet). The new one looks too long. You only Kyle> have twenty-two lines to work with. The only part that is not readable on 24 lines terminals is the copyright part, that nobody reads anyway (actually, I'm not sure anybody reads the current splash buffer at all). Moreover, when using the Sun workshop stuff, the /current/ splash buffer turns out to be more than 24 lines, and hides essential stuff like the HELP key bindings which is worse. Is it really too big a sacrifice to hide 4 useless lines of copyright compared to the improvement in readability ? -- / / _ _ 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

1 participants
0 comments

Re: lstreams (was Re: package badness) 25 years, 11 months

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > Before lstreams, stdio was not used for saving buffers. Prior to > 19.12, XEmacs saved a buffer by doing two write() operations--- the > first from beginning of buffer to the gap and the second from the > gap to end of buffer. Fast. At present, we copy data from an Emacs > buffer to stack buffer. Then from a stack buffer to an lstream > buffer. Then finally we write() it to disk. Slow. The same sort > of gup is done in insert-file-contents-internal. Point taken. :-( insert-file-contents-internal should probably use mmap() on systems that support it. > Why would lstreams be slower than stdio for reading Lisp? Lstreams > do more. Stdio only allows you to unget one character. lstreams > allow unlimited unget, and so an extra index must be checked for > every call to (the macroized) Lstream_getc. Lstream_getc is run for > every char read from a Lisp file. The extra instructions add up. > Lstream_getc also increments a byte counter that stdio almost > certainly would not be maintaining. More instructions. This is > from just eyeballing the code, so I could be wrong. Someone should benchmark lstream against stdio to be sure. You may well be right that these things add up. But then again, you might not be -- it could be the case that 90% of the time is spent in IO whatever else we do.

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 December 1998