October 1998 - XEmacs-Beta - XEmacs Mailing List Archives

21.0 showstopper bytecompile-time -vs- run-time dependencies 26 years, 1 month

SL Baur

Before I forget ... The current REQUIRES field is only a bytecompile-time dependency not a run-time dependency and should *never* be enforced at run-time, including package fetching. Since not all run-time dependencies should be enforced either (eg. Gnus run-time dependency on rmail), the solution isn't a straightforward download everything. Suggestions? New XEmacsen -- 21.2-beta3 and 21.0-pre15-pre6 and package updates will be available shortly.

2 participants
1 comments

XEmacs sumo 26 years, 1 month

Lars Magne Ingebrigtsen

I've been trolling around on www.xemacs.org a bit, but I can't find a link anywhere to the sumo packages. Er, like... Where are they? -- (domestic pets only, the antidote for overdose, milk.) larsi(a)ifi.uio.no * Lars Ingebrigtsen

1 participants
0 comments

Fwd: Re: "Dr. Soffer or How I Learned to Hate SCSI" 26 years, 1 month

Olivier Galibert

I want one ! I want one ! I want one ! Hmmm, sorry ^^;;; OG. From: Lars Hecking <lhecking+usenet(a)nmrc.ucc.ie> Newsgroups: alt.sysadmin.recovery Subject: Re: "Dr. Soffer or How I Learned to Hate SCSI" Leif Nixon <nixon(a)softlab.se> writes: [...] > T-shirt design idea of the week; black T-shirt with > "C-u 1000 M-x all-hail-emacs" in green Courier on the > front. On the back, in white Courier: "Obsolete function. Use `all-hail-xemacs'." Duck and cover, duck and cover ...

1 participants
0 comments

Re: Why do all the XEmacs defaults suck? (was Re: Why using (push-mark) ?) 26 years, 1 month

Didier Verna

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > >>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: > > sb> The basic question as Martin has raised it to me in > sb> conversation over the phone, is why do all the defaults suck? I'd say simply because XEmacs is *big*, we are numerous to hack on it, and it's an open development process. This means in particular that: - XEmacs is so big that nobody on the list can pretend [s]he knows everything about XEmacs. There are more than 150.000 lines of C and more than that in lisp. - In that, we're all ignorants, but we're all experimented as well. All technicians of some sort. People rarely throw general ideas or remarks. People usually send patches to implement or modify the concerned feature, and this is because the most important feedback we get on XEmacs usability is from ourseleves, the people who develop it. Hence the "defaults" are intrinsicly biased. - Moreover, as Stephen says, for us it sucks to try the defaults because we know more, so we want more. > But that's the wrong question, I think. Because all the defaults are > preferred by somebody! I don't think so. The fact is that all the *behaviors* are preferred by somebody. Whether such or such behavior should be the default is the real question. And the real problem begins when people are so used to the behavior they like that they begin to confuse it with the default thus breaking simpler things. > So the first question is "do we need a definition of 'suck'?" I think > we do; Yes, but we need to answer another question: "do we need a definition of 'default'?", and I think we do too. > the more consistent the XEmacs interface is, the more appealing > it will be (other things being equal). Exactly. Consistency /is/ the point, and it has a-priori nothing to do with complexity or obviousness. To me this leads not to one definition of 'suck', but two: something can suck as a matter _taste_, or as a matter of _consistency_. As a matter of taste, there's nothing much we can do. Some people like dark backgrounds and some others prefer light. This is a matter of taste and this is not arguable. There can be flame-wars between the dark-background-camp-by-default and the light-background-camp-by-default, but this will be sterile anyway. For this kind of debate, we should probably vote or something. As a matter of consistency, there's much that we can do. Like what's happening for the `push-mark' debate, it's always harder to fix a-posteriori an inconsistent behavior when it's the result of a graduate increase of complexity in a feature. But unfortunately, this is how it will happen most of the time because since we're all rather experimented users, it's even more difficult to keep a genuine and high-level view on what we're doing.[1] Now about the other question: "which definition for 'default'?" - The first thing is that at a first glance, any default should be okay, as long as it is consistent. And consistency this is part of our job, as developers. - The second thing is to ask "who the defaults are for?". The answer is easy: for people that don't know (yet) how to modify them. I'll probably make people shoot in my direction there: when Steve says that "xemacs -vanilla stinks", I don't consider it a valid argument. At least, not apart from consistency matters. Of course it stinks; we're so much used to an in-depth usage of it on this list! How could it be any other way? Now take a random guy out there, give him a vanilla xemacs, ask him to edit something and listen to what he says. What *he* will find stinking will probably be stinking. Before yelling at me, let me just precise this: xemacs for novices doesn't have to be dramatically simple and powerless, on the contrary to what Kyle thought I was saying. This is not a matter of /complexity/, but a matter of /obviousness/. I mean we can have something very complex by default. However, if the behavior the user is facing is not obvious, in other words "why the fuck did xemacs do this?!" then, it's the wrong default. Defaults doesn't have to be stupid, but for sure, they are not for us. Now if we'd all like a complex behavior by default, but this makes other things non-obvious, then, we should stick to a stupid default, and add a few documented lines in sample.emacs. I think that's the way I see the answer to this question of Stephen: | If there are only two, then we can have a massive flamewar over which | is going to be hard-coded as defaults and which is going to be | enshrined as sample.emacs. > The second question is, "who is the generic 'Jane User' who decides > what 'suck' means?" I dunno. Jane User who decides the background color, I dunno, and it doesn't really matter. Jane User who decides that something is inconsistent or obscure, or even _not powerful enough_ in a vanilla xemacs, I'd say as many non computer scientists as possible. > How about an xemacs-dotemacs write-only mailing list? :-) You're joking, but actually I think you're getting closer to the source of the problem. Add an xemacs-custom-default-value write-only mailing list and you're done. :-) > Not many customizations of XEmacs itself, although some packages (eg, > supercite) are extensively customized. I have very few things either, and I think that's what makes me very sensitive to the defaults' consistency. Footnotes: [1] This is the reason why I keep talking about beginners. Because I'm convinced that we need them as consistency-checkers. -- / / _ _ 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

2 participants
1 comments

Re: Richard Stallman: Emacs 19 26 years, 1 month

Hrvoje Niksic

Richard Stallman <rms(a)gnu.org> writes: > but said that *he* would never do so. > > And I did not do so now. Not in the quoted message, true. But you've done so numerous other times. Your attitude towards XEmacs is well-known in the hacker community, and I know you've tried to convince *me* not to cooperate with the XEmacs team. Since then, I got used to you not liking XEmacs. I even sort of understand your feelings, since I found myself in a similar (but much less distressing) situation. However, please PLEASE do NOT try to deny your actions against XEmacs. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- You're never alone with schizophrenia.

3 participants
2 comments

Re: [patch] automatic loading of package-get-base 26 years, 1 month

SL Baur

Greg Klanderman <greg(a)alphatech.com> writes in xemacs-beta(a)xemacs.org: >>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: APA> APA> Greg, Jan, Steven, APA> APA> I have not been able to apply Greg's nor Jan's patches. I had to APA> manually merge them in. > Steve's in the process of applying them so you should be able to cvs > update in a little bit. They've been CVSable for the last two hours. I'm going to make a 21.2 beta release as soon as I've finished going through the rest of the patch queue. ... APA> After installing those guys: APA> APA> - locale 1.10 ----- Localized menubars and localized splash screens. APA> - sounds-wav 1.05 ----- XEmacs Microsoft sound files. APA> APA> they still show up never to have been installed. This is a known APA> problem, right? > yup for sounds, not sure about locale. Neither perform `package-provide' calls due to the lack of installed lisp directories. The method for checking what has been installed should probably be done by perusing the pkginfo directory.

1 participants
0 comments

Re: [patch] automatic loading of package-get-base 26 years, 1 month

Greg Klanderman

>>>>> "APA" == Adrian Aichner <aichner(a)ecf.teradyne.com> writes: APA> APA> Greg, Jan, Steven, APA> APA> I have not been able to apply Greg's nor Jan's patches. I had to APA> manually merge them in. Steve's in the process of applying them so you should be able to cvs update in a little bit. APA> Next thing was that the symlink APA> APA> /ftp＠ftp.xemacs.org:/pub/xemacs/packages: APA> total 93966 APA> <lines deleted by Adrian> APA> lrwxrwxrwx 1 6101 6199 26 Oct 15 00:02 package-index.LATEST -> package-index-1998-10-12-2 APA> APA> sends my emacs-version "21.0 \"Pyrenean-pre4\" XEmacs Lucid" with APA> efs-version "1.17/1.57" into infinite recursion: Yikes, I didn't have that problem... :-( APA> So I customized ... APA> and now I can install packages from pui-list-packages. cool. APA> Another this I noticed: Selected packages are installed in reverse APA> order[1]. This is somewhat counter-intuitive. One could throw in a call to reverse. Not sure it's worth it. APA> After installing those guys: APA> APA> - locale 1.10 ----- Localized menubars and localized splash screens. APA> - sounds-wav 1.05 ----- XEmacs Microsoft sound files. APA> APA> they still show up never to have been installed. This is a known APA> problem, right? yup for sounds, not sure about locale. APA> Footnotes: APA> [1] from bottom to top in the *Packages* buffer. Actually it is the reverse of the order you select them in.

1 participants
0 comments

Re: [patch] automatic loading of package-get-base 26 years, 1 month

Adrian Aichner

>>>>> "Greg" == Greg Klanderman <greg(a)alphatech.com> writes: Greg> Will you commit my package-get-base patches too? The Greg> package UI stuff is broken otherwise. Also Jan's "big Greg> screwup in package-ui" one. If so I am close to another Greg> patch that should go in, depending on your choice above. Greg, Jan, Steven, I have not been able to apply Greg's nor Jan's patches. I had to manually merge them in. Next thing was that the symlink /ftp＠ftp.xemacs.org:/pub/xemacs/packages: total 93966 <lines deleted by Adrian> lrwxrwxrwx 1 6101 6199 26 Oct 15 00:02 package-index.LATEST -> package-index-1998-10-12-2 sends my emacs-version "21.0 \"Pyrenean-pre4\" XEmacs Lucid" with efs-version "1.17/1.57" into infinite recursion: Signaling: (error "Lisp nesting exceeds `max-lisp-eval-depth'") <lines deleted by Adrian> #<compiled-function (path) "...(45)" [efs-ftp-path path parsed 2 "/" efs-get-file-entry efs-internal-file-name-as-directory efs-host-type file-ent efs-internal-file-directory-p nil efs-chase-symlinks efs-internal-directory-file-name] 6>("/ftp＠ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST") apply(#<compiled-function (path) "...(45)" [efs-ftp-path path parsed 2 "/" efs-get-file-entry efs-internal-file-name-as-directory efs-host-type file-ent efs-internal-file-directory-p nil efs-chase-symlinks efs-internal-directory-file-name] 6> "/ftp＠ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST") efs-internal-file-directory-p(nil "/ftp＠ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST") #<compiled-function (path) "...(45)" [efs-ftp-path path parsed 2 "/" efs-get-file-entry efs-internal-file-name-as-directory efs-host-type file-ent efs-internal-file-directory-p nil efs-chase-symlinks efs-internal-directory-file-name] 6>("/ftp＠ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST") apply(#<compiled-function (path) "...(45)" [efs-ftp-path path parsed 2 "/" efs-get-file-entry efs-internal-file-name-as-directory efs-host-type file-ent efs-internal-file-directory-p nil efs-chase-symlinks efs-internal-directory-file-name] 6> "/ftp＠ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST") efs-internal-file-directory-p(unix "/ftp＠ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST") efs-file-directory-p("/ftp＠ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST") apply(efs-file-directory-p "/ftp＠ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST") efs-file-handler-function(file-directory-p "/ftp＠ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST") file-directory-p("/ftp＠ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST") apply(file-directory-p "/ftp＠ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST") dired-handler-fn(file-directory-p "/ftp＠ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST") file-directory-p("/ftp＠ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST") find-file-noselect("/ftp＠ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST") find-file("/ftp＠ftp.xemacs.org:/pub/xemacs/packages/package-index.LATEST") #<compiled-function nil "...(18)" [find-file efs-dired-host-type efs-version-host-types efs-internal-file-name-sans-versions dired-get-filename t] 5 "In dired, visit the file or directory named on this line.\nNote: This function has been modified to work with efs." nil>() call-interactively(dired-find-file) So I customized Type RET or click button2 on an active field to invoke its action. Invoke [Help] for more information. Operate on everything in this buffer: * * * * Package Get Base Filename: * /ftp.xemacs.org:/pub/xemacs/packages/package-index-1998-10-12-2 [State]: this option has been set and saved. Name of the default package database file, usually on ftp.xemacs.org. Parent groups: [Package Get] and now I can install packages from pui-list-packages. Another this I noticed: Selected packages are installed in reverse order[1]. This is somewhat counter-intuitive. After installing those guys: - locale 1.10 ----- Localized menubars and localized splash screens. - sounds-wav 1.05 ----- XEmacs Microsoft sound files. they still show up never to have been installed. This is a known problem, right? Best, Adrian sb> Why don't you fix up the latest package-index on sb> ftp.xemacs.org, drop the modified copy in: sb> ftp://altair.xemacs.org/incoming/ Greg> But it wouldn't contain the updates you're about to make, or Greg> is that just so you don't have to rebuild all packages? If Greg> you want I can run a keyboard macro across the new one you Greg> create later, I've done it here. But I'd prefer it get Greg> created automatically with the build process so that part Greg> also gets tested. Footnotes: [1] from bottom to top in the *Packages* buffer. -- Adrian Aichner Applications Engineer Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

Re: [patch] automatic loading of package-get-base 26 years, 1 month

SL Baur

Greg Klanderman <greg(a)alphatech.com> writes in xemacs-beta(a)xemacs.org: >>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> sb> Greg Klanderman <greg(a)alphatech.com> writes in xemacs-beta(a)xemacs.org: >>> I'd like to change the format of the package index file to sb> sb> That's fine with me. Do you wish this to happen immediately? > That would be ideal. Can you see my post about the format to > xemacs-patches - there are 2 options, one which requires changing > package-info.in for all packages but is a little cleaner. Let > me know which you prefer as soon as you can. O.K. I'll check. sb> I'm going to release 21.2-beta3 this afternoon/evening along with a sb> handful of package updates for a full dose of new package UI testing. > Will you commit my package-get-base patches too? Yes, the existence of your patches is the point of the release. > The package UI stuff is broken otherwise. Also Jan's "big screwup > in package-ui" one. If so I am close to another patch that should > go in, depending on your choice above. O.K. sb> Why don't you fix up the latest package-index on ftp.xemacs.org, drop sb> the modified copy in: sb> ftp://altair.xemacs.org/incoming/ > But it wouldn't contain the updates you're about to make, or is that > just so you don't have to rebuild all packages? I very much do not want to rebuild and reupload all packages. The last time it took about 5 hours to upload, so modifications to package-info.in files is out for this iteration. I mean building this release under the old format, hack the old format package-index to the new format and see how it works. > If you want I can run a keyboard macro across the new one you create > later, I've done it here. But I'd prefer it get created automatically > with the build process so that part also gets tested. It will, but I want to see exactly what you want so I'm not generating something bogus.

1 participants
0 comments

Re: help me fix package-get-base breakage 26 years, 1 month

SL Baur

Greg Klanderman <greg(a)alphatech.com> writes in xemacs-beta(a)xemacs.org: >>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> sb> I've uploaded package-index.LATEST.pgp, please give that a shot. > not readable - need to change permissions. Oops. Sorry. It's readable now.

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