April 1998 - XEmacs-Beta - XEmacs Mailing List Archives

SL Baur

Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: >>>>>> "Jens" == Jens Lautenbacher <jens(a)tellux.de> writes: Jens> Sorry if this is a faq or plain stupid, but I simply seem to Jens> be unable to get an xemacs-21 beta working... > I'm not all that surprised; the install process is in flux, big-time > right now, especially with respect to packages. Hopefully things will be slowing down now. The mechanics of it all are working quite well based on the testing I've been doing of it. Jens> After a long time I want to again work a bit with xemacs, Jens> and so I decided to get a new package enabled xemacs-21. I Jens> downloadded the cvs xemacs-20 and xemacs-packages. CVS'ing packages is the hard way. Download the `binary' tarballs from the FTP site for a first installation. Figure out where your packages should be ($prefix/lib/xemacs/packages, $prefix/lib/xemacs/mule-packages) and untar the packages you want there. If you're running in place, put the installed package directories anywhere (`packages' and `mule-packages' if you do Mule), and make symbolic links to them in the top level source directory. > OK. You don't need to get the source if you would rather just install > the binaries. In fact, it is not possible to build a Mule XEmacs at > present without an installed mule-base package AFAIK. That is correct. There's information about the bootstrap process in etc/BETA and etc/PACKAGES. I suspect that nearly all of the downloads of released 21.0 will use the prepackaged SUMO versions[1] of Lisp packages xemacs-packages-21.0.tar.gz and mule-packages-21.0.tar.gz. Footnotes: [1] No, they don't exist now, but they will for 'net release.

1 participants
0 comments

Re: [PATCH] Frame crash and extra minibuffers fixes 27 years

Greg Klanderman

>>>>> "kkm" == Kirill M Katsnelson <kkm(a)kis.ru> writes: kkm> kkm> This fixes [very probable cause for] crashes seen by Karl and Greg, kkm> and solves extra minibuffers problem in ediff, reported by Greg. Thanks Kirill! That does it. BTW, this appears to be the ChangeLog entry you were looking for: >1998-03-17 SL Baur <steve(a)altair.xemacs.org> > > * frame.c (delete_frame_internal): Correct check. Steve, was this to fix a bug or did it just look wrong? I see nowhere that function is called with other than 0 or 1, so maybe this code should just be ifdef'd out or removed? greg

1 participants
0 comments

Re: [OK] 21.0 "Pygmy" XEmacs Lucid (beta37) on i586-pc-linux 27 years

SL Baur

John W Jones <jj(a)asu.edu> writes: > This looks like four (copied out of beta.err): Nope. It's three. > Purespace usage: 97000 of 652296 (15% -- 542k wasted). This is the signature of loading .el's only prior to bytecompiling out- of-date dumped Lisp. This is a separate phase run just prior to starting dumping. > Purespace usage: 774536 of 652296 Dump try #1 -- too small. > Purespace usage: 766148 of 774536 (99% -- 8k wasted). Dump try #2 -- too big. > Purespace usage: 766148 of 766148 (100%). Dump try #3 -- just right. :-)

1 participants
0 comments

Re: [OK] 21.0 "Pygmy" XEmacs Lucid (beta37) on i586-pc-linux 27 years

John Jones

>>>>> SL Baur writes: > John W Jones <jj(a)asu.edu> writes: >> Is it typical for it to take so many tries to get the purespace >> right? > How many times did it take, 3? The maximum number of times it > should resize is 3. This will occur when the purespace starts out > too small. > If the purespace starts out much larger than the size needed we can > guarantee two passes. The first time through computes the exact > size, the second time through gets it right on the nose. > There should never be a need for four (or more) passes. This looks like four (copied out of beta.err): Purespace usage: 97000 of 652296 (15% -- 542k wasted). Purespace usage: 774536 of 652296 Purespace usage: 766148 of 774536 (99% -- 8k wasted). Purespace usage: 766148 of 766148 (100%). John Jones jj(a)asu.edu

1 participants
0 comments

Re: [PATCH] menubar selection in mswindows 27 years

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Lstreams rule. Look at my latest and greatest md5.c implementation to > see how simple it is to set up a decoding lstream for that purpose. Does that mean that md5.c mow works under MULE? Jan

1 participants
0 comments

Re: [Success] 21.0 "Pygmy" XEmacs Lucid (beta37) on i586-pc-linux 27 years

Jan Vroonhof

SL Baur <steve(a)xemacs.org> writes: > > BTW I recommend the xfstt true-type font server if you like scalable > > fonts with XEmacs; this server will render fonts on-screen very well > > compared to equivalent Postscript fonts from the same foundry. > > Cool. Could you please post a pointer to the source? I use the xfsft server (Built on FreeType) and I have to say, those damn Windows fonts do look well. (Somebody needs to do the same quality work on the Type1 renderer in X). http://www.dcs.ed.ac.uk/home/jec/programs/xfsft/ I do hope that oneday this gets mergen in to XFree so we can have it in the server instead of using a seperate fonts server. Jan

1 participants
0 comments

Re: [OK] 21.0 "Pygmy" XEmacs Lucid (beta37) on i586-pc-linux 27 years

SL Baur

John W Jones <jj(a)asu.edu> writes: > Is it typical for it to take so many tries to get the purespace right? How many times did it take, 3? The maximum number of times it should resize is 3. This will occur when the purespace starts out too small. If the purespace starts out much larger than the size needed we can guarantee two passes. The first time through computes the exact size, the second time through gets it right on the nose. The problem with a too-small purespace is that the computation of how much space is needed is inexact -- it only counts the number of bytes requested. This number will be too high because compaction is done while filling the purespace. Hence the second time through, the purespace will be too large. The third time through will be an exact fit. There should never be a need for four (or more) passes.

1 participants
0 comments

Re: [PATCH] menubar selection in mswindows 27 years

Hrvoje Niksic

"Kirill M. Katsnelson" <kkm(a)kis.ru> writes: > Some time ago, Hrvoje Niksic wrote... > |+ > | "Kirill M. Katsnelson" <kkm(a)kis.ru> writes: > | > | > I think that selection-owner-p must return the same as > | > (region-active-p) under Windows, > | > | This sounds wrong. When `zmacs-regions' is nil, (region-active-p) > | always returns nil, and yet the selections should still work. It is > | arranged that way under X, and we should preserve that design. > > Thanks for pointing on that fact. What do you suggest? To preserve that design. :-) Seriously, what it means is that the selections are fully operational even without zmacs-regions. The right way to achieve this is to comb through `mouse.el' and replace x-specific selection code with the generic selection code, as coded by Andy. Examples: (defun default-mouse-track-has-selection-p (buffer) (and (or (not (eq 'x (console-type))) (x-selection-owner-p)) and: (defun default-mouse-track-maybe-own-selection (pair type) (let ((start (car pair)) (end (cdr pair))) [...] ((eq 'x (console-type)) (if (= start end) (x-disown-selection type) [...] (x-own-selection (buffer-substring (point-min) (point-max))) (kill-buffer (current-buffer)))) (x-own-selection (cons (set-marker (make-marker) start) (set-marker (make-marker) end)) type))))) and: (defun default-mouse-track-deal-with-down-event (click-count) [...] ((eq 'x (console-type)) (x-disown-selection))))) etc. Functions like `x-store-cutbuffer' are also used. Basically, all the places in mouse.el where (eq (device-type) 'x) is used, or where x-* functions are used, should be fixed. This is why writing a good `select.el' is not as easy as it may seem. However, it is more than worth it. > By the way, I have this im my .emacs: > (set-face-background 'zmacs-region "gray80") > > When I click and drag with the mouse, the region being selected is > light gray. Although, after I release the button, it turns darker. > What's that? You probably see the discrepancy between primary-selection face and zmacs-region face. The best way to learn about this is to start XEmacs on Solaris or Linux, and experiment with selections with and without zmacs-regions. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Ooh, Granny, what a BIG belly-button you have!

1 participants
0 comments

Re: Dump dumped-lisp? 27 years

SL Baur

Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes: >>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> This patch isn't going to work quite right. The DOC strings for all sb> loaded files will be lost. I thought the best solution was what was sb> originally done for EFS with efs-auto.el. > Could you clarify this? I'm afraid my understanding of how doc > strings work is rather incomplete. I'm more than willing to do the > necessary hackery. The hackery has been done. Basically, the same list of lisp files loaded at dump time (I hope you're familiar with this code by now :-) needs to be presented to lib-src/make-docfile which does some magic and spits out a DOC file. make-docfile.el uses the same algorithm (and code) to determine what files are dumped with XEmacs. So long as nothing dirty is done (magical require's which load code, explicit calls to "load", to name two) everything should just work.

1 participants
0 comments

Re: Package request 27 years

SL Baur

Andy Piper <andyp(a)parallax.co.uk> writes: > Can JDE be made a package? (Java Development Environment) Yes. Go for it.

1 participants
0 comments

2025

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