January 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Simon Josefsson

What happened to the suggestion that XEmacs should look for foo.elx before foo.elc when executing elisp files?

1 participants
0 comments

temporary-file-directory 25 years, 3 months

Lars Magne Ingebrigtsen

Emacs has temporary-file-directory, which defaults to "/tmp/". It's a nice variable to have, since all other temp dir variables can use that variable as the default value, so I think XEmacs should have it as well. -- (domestic pets only, the antidote for overdose, milk.) larsi(a)ifi.uio.no * Lars Magne Ingebrigtsen

5 participants
4 comments

Re: 21.0 vs 21.2 25 years, 3 months

Tor Arntsen

On Jan 2, 16:15, "John A. Martin" wrote: >Perhaps I need a little remedial CVS tutorial. > > Martin> ftp://ftp.xemacs.org/pub/xemacs/beta/xemacs-21.2 > >1. Before doing that I can look see how big the tarball is and choose >accordingly where to put it. That's a point. There is no (easy) way to check how big the CVS checkout will be in advance. >2. When it arrives I can check the signature to tell me the file is >uncorrupted since someone I might know signed it. Right again. Although if the repository itself hasn't been compromised then it's quite tricky to intercept and modify what you download, even with the 'pserver' mechanism (which doesn't use encryption or anything). >3. Before unpacking it I can see what is there and where it will go. With CVS the checked-out module will end up in a subdirectory relative to where you are when you run the command, the name of the subdirectory will be the name of the module (e.g. 'cvs checkout xemacs' creates a directory ./xemacs). >4. I can choose to put it where it won't clobber something that I >already have and that works (or least that I know something about). It will always be relative to your current pwd, see above. >5. If I run out of space unpacking it I can without too much trouble >try again someplace else. You can, in fact, do this with CVS too. Just move whatever you got so far to somewhere else and redo the operation. It will continue from where you left off the first time. >At minimum, how can I tell what I'm getting in for. How can I tell >how big it is and where will it land. How can I specify where it will >land? I got around 34 MB when I checked out the 21.2 release. You can modify the directory name it ends up with. Suppose you would prefer it to end up in /tmp/myXeMacs: cd /tmp cvs -z3 -d :pserver:xemacs＠cvs.xemacs.org:/usr/CVSroot \ checkout -r r21-2-8 -d myXeMacs xemacs (the 'checkout' should be on the same line as the cvs command) Note that from then on you can skip the '-d :pserver:xemacs＠cvs.xemacs.org:/usr/CVSroot' part, as long as you are in a directory where there is a CVS/ directory. That will usually be from inside the xemacs/ directory and downwards, except for a few versions of cvs where the CVS directory is created also above the xemacs directory. You can do e.g. 'cd xemacs; cvs -q -n update -l' just to check what's been modified in the repository, without actually doing anything. The '-l' means 'local in the current directory', i.e. 'not recursive'. Remove the '-n' and the '-l' and you will get your whole copy up-to-date with respect to the repository. If you have any local hacks they will automatically be merged in with what's downloaded, if there are conflicts you will be told about it so you can fix your hack afterwards. One more thing though, that version 'r21-2-8' in the example above will get you a 'frozen' version, so cvs update will do nothing. If you instead use '-r release-21-2' then you check out a 'branch tag', not a 'revision tag', and 'cvs -q -z3 update' will keep you updated in the future. You can always switch between revisions and branches afterwards though, CVS is smart and will only send you the diffs. '-z3' will compress the diffs as well. 'cvs status -v filename' is the way to find out what tags (revisions/branches) exist. >Where should I go to learn how to do these things? CVS FAQ: http://www.loria.fr/~molli/cvs/cvs-FAQ/cvsfaq0.html CVS DOCU: http://www.loria.fr/~molli/cvs/doc/cvs_toc.html I think some of this *may* be a little bit out of date, but for normal operations it should do just fine. There is also good up-to-date docu coming with CVS, among them a 60+-page postscript file. Most experienced CVS'ers recommend to read it from end to end twice, and then experiment a bit with your own little dummy project. Good advice I would say, although you really don't need to know much just to stay on the bleeding edge with XEmacs. Happy CVS'ing! - Tor

1 participants
0 comments

MLM IS DEAD !! 25 years, 3 months

owner-xemacs-beta＠xemacs.org

A growing number of disillusioned distributors are turning away from traditional MLM companies. The sign-up games, the front loading, outrageous product prices, companies going bankrupt everyday and all the Hype !! What if you could attract 70% of the population, instead of 2-3% ? Can you imagine having all your customers sending you more customers so they could get your products for FREE ? This is the hottest business trend for the next century. Make sure you are among the first to utilize this incredible system. This is an extremely limited opportunity, so call today... 1-800-771-1019 24 hours per day ----------------- To be Removed Reply to <newrem(a)usa.net> with REMOVE in the subject line. -----------------

1 participants
0 comments

mailing list for commit messages 25 years, 3 months

Richard Coleman

Does XEmacs have a mailing list so we can see the CVS commit messages? If not, is there any chance of creating this? -- Richard Coleman coleman(a)math.gatech.edu

1 participants
0 comments

Re: 21.0 vs 21.2 25 years, 3 months

SL Baur

Matthew O Persico <mpersico(a)erols.com> writes in xemacs-beta(a)xemacs.org: > But then, I'd nead a tarball to start from anyway since rematerializing > a whole CVS tree over 56K line is probably too slow, yes? Wrong. Tarballs are for those with bandwidth to burn. Getting and staying up to date via CVS is *much* faster with limited bandwidth.

2 participants
1 comments

Re: XEmacs 21 /vs./ my keyboard: I want my DEL back 25 years, 3 months

Karl Kleinpaste

Martin Buchholz <martin(a)xemacs.org> writes: > The current implementation may not be perfect, but we have to try to > achieve this goal. Perhaps you would like to help? I'd love to help. My suggestion is, as I've said, to return to 20.4's behavior, because It Just Worked, and the goal (from my perspective, where keymaps are currently broken) was already achieved. This would also require that the default setting of delete-key-deletes-forward be made nil again. Barring that, a configurable setting whereby one could choose the internal keysym to be generated when an actual \177 is hit in tty mode would be a godsend. I thought this is what keyboard-translate would be good for (I hadn't had to look at keyboard-translate-table since I did a Dvorak-ish thing for Emacs18), but as I said last time around, I haven't been able to convince keyboard-translate to do anything useful for me; suggestions most welcome. If hackery beyond k-t is needed to accomplish this bit of configurability, I'll tackle it, if someone will just point me to where the relevant code is, as I haven't been inside Emacs in years, and XEmacs never. I find myself wondering how many keymaps would have to be examined, in order to hunt down all the <delete> entries, in order to duplicate them into <backspace> entries. Doesn't this need for duplication, imposed out of a desire for a sense of keymap purity, seem a bit over the top to anyone but me? I have to admit that I am afraid that the intended, stated goal... > deletes backward (never enters help!) when hitting the key labelled > backspace, and deletes forward when hitting the key labelled delete. ...is inherently an impossibility as long as "help" lives on `C-h', because that takes the needed binding out of availability entirely: The fact that some delete-ish, backspace-ish key will generate `C-h' in an xterm makes the "never enters help!" goal flatly unattainable -- one had best give up on that fantasy right away.

2 participants
1 comments

Re: 21.0 vs 21.2 25 years, 3 months

Karl Kleinpaste

"Matthew O. Persico" <mpersico(a)erols.com> writes: > Is 21.2 a CVS-only, or are there tarballs? ftp://ftp.xemacs.org/pub/xemacs/beta/xemacs-21.2/

1 participants
0 comments

Re: XEmacs 21 /vs./ my keyboard: I want my DEL back 25 years, 3 months

Karl Kleinpaste

But the problem with remapping \177 as keysym "BS" is that it means one's keyboard is not bound the same way under X /vs./ inside an xterm. Right now, I've got two XEmacsen running Gnus: One locally, under X, on my main home system for mail which I handle here (charcoal.com), and one remotely, inside a local xterm, at JPRC for most things. Under X, I hit Delete and I get DEL, I hit Backspace and I get BS, I hit `C-h' and I get `C-h'. These bindings seem to be shifted circularly inside an xterm, so that I hit Delete and I get BS, and I hit Backspace and I get `C-h'. This is to say that I can't even expect to get the same result from hitting the exact same keys within an xterm as I get under X. This is extremely peculiar, and a fabulous loss of coherency to me. It's not a matter of being a crusty holdover to DEC; it's a matter of a single keyboard attached to 2 instances of a single program not providing identical keyboard interfaces. In order to get the same keyboard interface, every keymap in every XEmacs mode will have to duplicate every entry containing <delete> so that it also binds the <backspace> case. Until that happens, lots of other folks who, as myself, split a lot of time between "under X" and "in an xterm" will find exactly the same problem, and if 21 were to go out the door the way it is right now, most of those other folks wouldn't be very understanding of the soft underbelly of the Keymap Purity Hit Squad; they'll just complain about why their Delete has stopped being a <delete>...but only in an xterm. Philosophy is great, but it doesn't solve the problem of lost keymap capabilities. 20.4 had no problem with this. In 20.4, at least the limit of X/terminal keymap difficulty was that hitting the Backspace key simply unavoidably duplicated the existing binding on `C-h'. 20.4 didn't willfully *move* one binding to another key, which is what 21 has done. If there's some way provided by which to turn off or alter the "aggressively translate \177 to an arbitrary keysym," I'd love to know it. The documentation seems to have no help on this -- the *Info* files for 21 still refer to DEL in its typical use as executing "delete-backward-char", so it appears that these things haven't been updated since at least v19, considering that even in 20, DEL's usual binding is "backward-or-forward-delete-char". I've tried fiddling with keyboard-translate -- things like (keyboard-translate '(?\177 DEL)) and related variations -- to no good effect, nor any effect at all, in fact. A look at lisp/events.el was not informative, since I see no indication of the base \177->BS translation there.

2 participants
1 comments

enhanced pop3.el 25 years, 3 months

Andy Piper

I finally got around to enhancing pop3.el. This does UIDL support + my regexp partial downloading and is reasonable quick to boot. I will probably put this into mail-lib if no-one has any objections. Merry Christmas Adrian ... 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

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 January 1999