December 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: the splash buffer 25 years, 4 months

Hrvoje Niksic

Didier Verna <verna(a)inf.enst.fr> writes: > Today, for some reason, I didn't feel like writing my Ph.D., so I > rewrote a new splash buffer. This one will work in all > configurations, doesn't take more space than the old one, but is > much much more readable, I think. > > I've made a screenshot at > http://www.infres.enst.fr/~verna/splash.gif > > What do you think ? I *wuv* it! The only remark is that it won't work at 80x24 displays. Perhaps you should squeeze it somehow in that case? (And `useful' is spelled with one `l'!) -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- Lost in Static 18 / And the storm is closing in now

1 participants
0 comments

the splash buffer 25 years, 4 months

Didier Verna

One day, my artistic pulse that some of you already know took control of my brain and I wrote a new splash buffer, wonderful, with lots of ascii art, everything beautifuly aligned, flowers and .... and this couldn't be used because proportional fonts would have fucked up everything. Today, for some reason, I didn't feel like writing my Ph.D., so I rewrote a new splash buffer. This one will work in all configurations, doesn't take more space than the old one, but is much much more readable, I think. I've made a screenshot at http://www.infres.enst.fr/~verna/splash.gif What do you think ? -- / / _ _ 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: Assertion while pui-list-packages 25 years, 4 months

Norbert Koch

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > Norbert Koch <n.koch(a)delta-ii.de> writes: > > > Lisp-backtrace: > > Signaling: (error "Package-get PGP signature failed to verify") > > signal(error ("Package-get PGP signature failed to verify")) > > This is not really a bug I think. XEmacs is supposed to give this > error in this case. However that does not mean all is well. Yes, I guessed that this error message is ok, although the crash is not. > > I've done a M-x pui-list-packages (after installing pgp-5.0i on my > > machine). > > I think the normal mailcrypt cannot handle pgp 5.0. Do have you have > the mailcryptng package installed? Is that being loaded? > > You need to try verifying the signature on the > package-get-index.LATEST.pgp by and using mailcrypt to try and see > what is the problem. I've now downgraded to 2.6.3i. Everything seems to work now, at least I get into the package and not into thin air ... nice. Sorry for the confusion, although a more subtle approach to the problem of pgp versions might be a good thing to think about :-) Cheers, norbert. -- I'm in ATLANTIC CITY riding in a comfortable ROLLING CHAIR...

1 participants
0 comments

Re: CVSROOT for XEmacs-21.0 25 years, 4 months

SL Baur

SL Baur <steve(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: [lots of explanation about the foolishness of the `xemacs-20' directory in the CVS tree] > At any rate, I won't be very disappointed if the next maintainer > rearranges things in more logical fashion. Newsflash: As of last night, the name is simply`xemacs'.

2 participants
1 comments

Re: "Pyrenean-pre8" problems on WinNT 25 years, 4 months

Jan Vroonhof

Charles G Waldman <cgw(a)pgt.com> writes: > (1) (warning/warning) Error caught in `make-auto-save-file-name': > Creating directory: No such file or directory, c:\home\cgw\home\cgw\/.autosave > > (HOME is /home/cgw; this is apparently getting doubled up somehow) It could be a bug in the NT expand-file-name routines (what does (expand-file-name "test" "~/test/") give under your machines). I do not know the NT port but shouldn't HOME be a directory including driveletter since otherwise it is not uniquely specified? The funny thing is that XEmacs tries to do its best to copy with funny HOME values but on NT it seems to be switched of explicitly: if (IS_DIRECTORY_SEP (nm[1]) || nm[1] == 0) /* ~ by itself */ { if (!(newdir = (Bufbyte *) get_home_directory())) newdir = (Bufbyte *) ""; nm++; #ifdef WINDOWSNT collapse_newdir = 0; #endif } The collapse_newdir explicitly tells XEmacs to not consider the fact your HOME prefix starts with a / and just prepend the current dir which happened to be c:\home\cgw in your case. It seems bogus to me. Could you try removing that code and then test what happends to expand file name in all case. i.e. with 1. HOME includes driveletter 2. HOME does not include drive letter. 3. HOME is a network path Jan

2 participants
1 comments

Re: "Pyrenean-pre8" problems on WinNT 25 years, 4 months

Adrian Aichner

>>>>> "Sean" == Sean MacLennan <Sean.MacLennan(a)pika.ca> writes: Sean> Adrian Aichner writes: >> Yep, the current naming scheme for auto-save file names is not legal >> on WindowsNT's ````file system''''. >> >> You can get it to work by setting auto-save-directory nil. >> This works fine, except for performance when you edit files via NFS or >> EFS since the auto-save files are stored in the directory of the file >> it auto-saves. Sean> The other solution is to turn hashing on. This produces a filename Sean> that NT can handle. I didn't like it since ... Hashing defeats `recover-all-files', you have to recover files individually by doing `recover-file'. Not sure recover-session would work with hashing? Adrian Sean> Sean Sean> -- -- Adrian Aichner European Design Center Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

Re: "Pyrenean-pre8" problems on WinNT 25 years, 4 months

Adrian Aichner

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> It could be a bug in the NT expand-file-name routines (what does Jan> (expand-file-name "test" "~/test/") give under your machines). (expand-file-name "test" "~/test/") "c:\\WinNt\\Profiles\\AichnerA\\test\\test" Jan> I do not know the NT port but shouldn't HOME be a directory including Jan> driveletter since otherwise it is not uniquely specified? Yes. (getenv "HOME") "c:\\WinNt\\Profiles\\AichnerA" Jan> The funny thing is that XEmacs tries to do its best to copy with funny Jan> HOME values but on NT it seems to be switched of explicitly: Jan> if (IS_DIRECTORY_SEP (nm[1]) Jan> || nm[1] == 0) /* ~ by itself */ Jan> { Jan> if (!(newdir = (Bufbyte *) get_home_directory())) Jan> newdir = (Bufbyte *) ""; Jan> nm++; Jan> #ifdef WINDOWSNT Jan> collapse_newdir = 0; Jan> #endif Jan> } Jan> The collapse_newdir explicitly tells XEmacs to not consider the fact your Jan> HOME prefix starts with a / and just prepend the current dir which Jan> happened to be c:\home\cgw in your case. It seems bogus to me. Jan> Could you try removing that code and then test what happends to expand Jan> file name in all case. i.e. with Jan> 1. HOME includes driveletter Jan> 2. HOME does not include drive letter. Jan> 3. HOME is a network path This experiment proved too painful under the MS-DOG shell. Adrian -- Adrian Aichner European Design Center Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

Re: Minor package nit. 25 years, 4 months

Jan Vroonhof

Andy Piper <andyp(a)parallax.co.uk> writes: > That's what I put in the docstring, but it was a slight misnomer in that as > a side effect it updated installed packages to the latest version. As I > remember package-get-update-all didn't do this for some reason. Since the docstring to package-get-update-all says it does exactly that it should be fixed doesn't. > I don't really care which is called but I think you should be able > to update all your installed packages from the menubar (probably the > most common thing you would want to do over time) Jan > Custom probably is a bad way although I think the effect is correct > (packages added / removed from the menubar). Although by that argument you > could argue that custom is bad period - custom is after all the standard > way of configuring emacs. Yes. But one big part of custom is that it allows a way for saving configurations and you do not need that here. The main advantage of using custom that remains is that this allows you use customize-browse and friends for a different text interface than pui-install-packages. However they offer "save" and "reset" options that make no sense whatsoever here, the same for the state buttons etc. Moreover as far as I can see turning a package off using the customize interface does abosolutely nothing. Jan

2 participants
1 comments

Re: Minor package nit. 25 years, 4 months

Jan Vroonhof

Andy Piper <andyp(a)parallax.co.uk> writes: > IMHO "Update Packages" should be on the main package menu as it is not > specific to using packages with custom - its just a convenient way of > getting the latest versions. It is supposed to only update the package that were explicitly selected using custom, see the doc string. However it really doesn't do that now (to be more precise it just adds all the packages it can find to the customize variables and then adds only those "selected"). So either 1. what "Update Packages" does now is correct. However then I do not see the need to manage a whole set of packages using custom if you are never going to use that set. Then using custom is just a bad way of getting the menus and the "Manage Packages" menus should simply use a menufilter and the "Using Custom" menu should be ditched. 2. The Customize Packages system is really intented to manage an orthogonal set of packages and the :initialize functions should be ditched. Jan

2 participants
1 comments

Re: alpha-linux build failure 25 years, 4 months

Falk Hueffner

SL Baur <steve(a)xemacs.org> writes: > nbecker <nbecker(a)fred.net> writes in xemacs-beta(a)xemacs.org: > > > The problem is egcs-1.1. I rebuilt with egcs-1.0.2 (as it comes from > > RH5.1) and it's working fine. > > Wonderful. This isn't the first report of XEmacs getting axe-murdered > by this compiler. > > We probably need to add a warning about egcs-1.1 somewhere in > PROBLEMS. I haven't had any XEmacs-related problems with it, though > I have now encountered a number of other programs that it chokes on. For me, egcs 1.1 didn't work, but 1.0.3a did. I suggest you put a note in PROBLEMS to avoid 1.1 for Alpha Linux and use 1.0.3a instead. Falk

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