December 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Jan Vroonhof

Glynn Clements <glynn(a)sensei.co.uk> writes: > No, but you can use relabel-menu-item Why is that needed? It would be very bad too since it changes the names of the items. Or do you mean "add accelerators". > in conjunction with > menu-accelerator-modifiers and menu-accelerator-prefix to get > Windows-style behaviour. The problem is that under windows you can actually activate the menu by using a single alt press and that > Given that XEmacs binds most of the > Meta-modified codes, it helps if you have an Alt key as well. Would also be nice if the default menu actually HAD accelerators. How do the NT guys cope with this? Secondly I think menubar-accelerator-modifiers should default to '(alt) too. At the very least under X. I also noticed that for traversing the menus with the keyboard the M%_ule and the %_Options menu are very bad because they have submenus as the first item. Jan

2 participants
1 comments

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

Adrian Aichner

>>>>> "SL" == SL Baur <steve(a)xemacs.org> writes: SL> SL Baur <steve(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: SL> [lots of explanation about the foolishness of the `xemacs-20' SL> directory in the CVS tree] >> At any rate, I won't be very disappointed if the next >> maintainer rearranges things in more logical fashion. SL> Newsflash: As of last night, the name is simply`xemacs'. Hello Steven, is xemacs-20 still valid? I checked out r21-2b4 of the xemacs-20 module at 11:45 CET today, before reading this mail. 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: Assertion while pui-list-packages 25 years, 5 months

Jan Vroonhof

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

1 participants
0 comments

Re: Where is this message coming from and why? 25 years, 5 months

Jan Vroonhof

Andy Piper <andyp(a)parallax.co.uk> writes: > My guess would be that there is a package dependency that can't be found > and so xemacs is trying to get it remotely. Seems cheesy ;) No it is not going remotely (luckily, since that was what all our patches were about.)

1 participants
0 comments

Re: CVS update error 25 years, 5 months

SL Baur

Paul Bibilo <peb(a)delcam.com> writes in xemacs-beta(a)xemacs.org: > Trying to do a cvs update on the Pyrenean tree I get the following > error. > cvs [server aborted]: cannot open directory /usr/CVSroot/XEmacs/xemacs-packages/comm/irchat: No such file or directory irchat was removed due to Brain Damage(TM)[1] Did you get around this CVS problem? When I run into problems like this I start editing files underneath CVS/ to remove the offending filenames. Presumably there's a better way to handle deletions. Footnotes: [1] Brain Damage is a registered trademark of the United States Government.

1 participants
0 comments

Re: ?: what tool to use to uncompress *.tar.bz2 files, ?: what tool to use to uncompress *.tar.bz2 files 25 years, 5 months

SL Baur

Ham Nguyen Yeu <Ham> writes in xemacs-beta(a)xemacs.org: ... > In act, I've never ever succeeded in building XEmacs. > Although I've posted following article before, there're no answers. > Any answers, please. You might be the only person testing XEmacs on your architecture. I have never seen a build report from someone using it. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Hello. My name is Shigeki Uno and new to this ML. > I've ever tried to build XEmacs-21.* many times, but never succeeded > it. I got same failure. Details are... > ------------- > My Computer > ------------- > OS: NetBSD/mac68k 1.3.2 > make: OS involved make > gcc: 2.7.2.2+myc1 > X: X11R6 ... > Dumping under the name xemacs > Purespace usage: 743982 of 743982 (100%). > Testing for Lisp shadows ... > Abort trap > *** Error code 134 An error occurring like this is nearly always due to something going wrong during dumping. We're eliminating this horrible crock soon, right Kyle? I don't know what to suggest. You should have a src/xemacs binary. Does it do anything other than abort? Try doing `make run-temacs'. Does it work?

1 participants
0 comments

Minor package nit. 25 years, 5 months

Andy Piper

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. andy --------------------------------------------------------------------------- " .sigs are like your face - rarely seen by you and uglier than you think" Dr Andy Piper, Technical Architect, Parallax Solutions Ltd mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp

1 participants
0 comments

package badness 25 years, 5 months

Andy Piper

Updated my packages, at the end I got the error: "Removing directory: Directory not empty, /usr/gnu/lib/xemacs/packages." This is BAD since this is my top-level packages directory, the package stuff should not be trying to remove it! Also IMHO (and this may not work on all systems). Instead of deleting the package and then untarring the new one. The new one should be untarred to a temp directory and then the old one moved out the way and the new one moved in. Finally the old one deleted. Just more paranoia but the failure of gzip and tar is a higher than neglible probability as shown by the native windows problems. BTW though the package stuff is getting *really* good now. andy --------------------------------------------------------------------------- " .sigs are like your face - rarely seen by you and uglier than you think" Dr Andy Piper, Technical Architect, Parallax Solutions Ltd mail: andyp(a)parallax.co.uk web: www.parallax.co.uk/~andyp

1 participants
0 comments

Re: a few more package get cleanups 25 years, 5 months

Jan Vroonhof

greg(a)alphatech.com (Greg Klanderman) writes: > It just seems the default behavior should favor keeping a less > experienced user from shooting himself in the foot. Usually when you > use pui-list-packages you want to install new packages. You should > get the current list. I have just slept some more on this. I think 1. Signalling an error is bad. Getting possibly outdated data is not a fatal thing. Erroring out just scares people away. 2. Solving it in package get.el is too low level. It is clear that there should be an indication to the user that he is using a _possibly_[1] outdated database. However when the warning should come is more of a user interface issue so we should solve it at that level. What about 1. _Warning_ the user at the start of pui-list-package that the database could be outdated, ussing `message' not `error'. Also stick this warning at the top of the *Packages* buffer. 2. Offer to update the database (and if a there is a pui-list-package buffer update that) after the user uses "Add Download site". > No, pui-list-packages does (package-get-require-base t) so it thinks > it already has gotten an up to date package index, when in fact it > loaded the one from the etc directory, and has set package-get-was-current > to true. Then that is a bug and either a1. Setting package-get-was-current needs to be somewhat deeper in the code. a2. package-get-was-current never should be set when package-get-remote is nil. b. When changing package-get-remote either using the menu or using custom package-get-was-current should be set back to nil. I think a combination of a2 and b would preferable now. Jan Footnotes: [1] Remember, the code will offer to save the database locally after updating it. -- Jan Vroonhof http://www.math.ethz.ch/~vroonhof/ Mathematik, vroonhof ＠ math.ethz.ch HG E16, ETH-Zentrum, Tel: +41-1-6325456/25154 Raemistrasse 101, CH-8092 Zuerich. Fax: +41-1-6321085

1 participants
0 comments

Re: Where is this message coming from and why? 25 years, 5 months

SL Baur

Andy Piper <andyp(a)parallax.co.uk> writes in xemacs-beta(a)xemacs.org: > At 00:04 02/12/98 -0800, SL Baur wrote: >> I'm trying to build XEmacs packages from a bare-ass buck-naked binary >> with no installed packages besides mule-base. What is happening with >> this error message? > My guess would be that there is a package dependency that can't be found > and so xemacs is trying to get it remotely. Of course. It's bare-ass buck-naked. The package-path is essentially /dev/null except for mule-base. I don't expect it to find texinfo stuff because it isn't pointed at any texinfo stuff and it is _good_ that it isn't finding any. :-) > Seems cheesy ;) Only the prompt with `-batch' is bad. Offering to fetch the package seems most reasonable to me. > Shouldn't there be a package-path that shows where the texinfo stuff is? Irrelevant in this case. The prompt needs to be removed when XEmacs is noninteractive and we need to fix the problem where it crosses the assertion when prompting is attempted anyway[1]. Footnotes: [1] I don't consider the latter a show-stopper. It's likely not a new bug and has never been reported before.

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