May 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: .emacs vs .xemacs vs .xemacs.el vs...? 25 years, 12 months

Jan Vroonhof

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > If you guys put random stuff in there, I promise something will break > eventually. It does not belong there. Ever. Period. The only way > to use ~/.xemacs for random init goop would be to put the default > early package hierarchy somewhere else. Maybe ~/.xemacs-packages. Why? If site-start can be in lib/xemacs/packages/lisp why can init.el not be in .xemacs/lisp? Jan

1 participants
0 comments

Re: .emacs vs .xemacs vs .xemacs.el vs...? 25 years, 12 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > > > This is turning into an xemacs-beta FAQ. No specific decision was > > > ever made. `.xemacs/' was never used in a released XEmacs version. > > > > Nor was ".xemacs-custom" BTW. > > Your point being? I was refering to the fact that it had been decided it would be better if you put customizations elsewhere and there is discussion of preserving that change for 21.0. If you want that and you therefore need yet another file, it might well be ~/.xemacs/lisp/options.el. Jan

1 participants
0 comments

Re: .emacs vs .xemacs vs .xemacs.el vs...? 25 years, 12 months

Didier Verna

Olivier Galibert <galibert(a)pobox.com> writes: > > The only way > > to use ~/.xemacs for random init goop would be to put the default > > early package hierarchy somewhere else. Maybe ~/.xemacs-packages. > > Or ~/.xemacs/packages/ Oh, joy ! There's a pure soul among us ! Je suis avec toi, mon fils ! :-)

1 participants
0 comments

Re: custom-file 25 years, 12 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)srce.hr> writes: > It's not. My point is that I want to have a *choice* whether I want > `.xemacs/' or not, and for that choice to be respected. Which is OK. It just that I want the default to be WITH .xemacs. Jan

1 participants
0 comments

Re: custom-file 25 years, 12 months

Michael Sperber

>>>>> "Didier" == Didier Verna <verna(a)inf.enst.fr> writes: Didier> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: Jan> Hrvoje Niksic <hniksic(a)srce.hr> writes: Jan> 3. We have .xemacs anyway for the package system. >> >> 3. is a reason *not* to use it for startup files. ~/.xemacs is a >> package hierarchy. There's no lasting guarantee that its layout will >> support putting random .el files in its root. Didier> I don't understand what you mean. Could you clarify ? Package hierarchies have a predefined layout. That layout may (and probably will) change at some point in the future. That layout says nothing about "user init files", so there's no guarantee a future package layout hierarchy will not trip over random goop that's hanging around random places in it. I sure don't want to lose sleep trying to coordinate package hierarchy layout with files *someone else* is putting in it. If you think a conflict is unlikely, go back to the flamewars over the stat count on path searching. Those were almost entirely due to the code being written with assumptions in mind that weren't in synch with reality. Given that, I'd rather keep reality simple. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: custom-file 25 years, 12 months

Oscar Figueiredo

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: >> Hrvoje Niksic <hniksic(a)srce.hr> writes: >> >> > I couldn't care less which one you choose, as long as the default >> > behaviour is to NOT create a .xemacs/ directory and ram it down my >> > throat. >> >> Why is creating yet another file in ~/ (i.e. ~/.emacs-customs) to be >> prefered over creating a directory? Hrvoje> It's not. My point is that I want to have a *choice* whether I want Hrvoje> `.xemacs/' or not, and for that choice to be respected. Well, having read the arguments for and against the creation of an .xemacs/ directory, I must say I am much more convinced by the arguments in favour. I believe that since we need several user files at startup (and even much more as soon as we have user installed packages) we should not clutter the home directory with a plethora of .xemacs-xxx files. Grouping things together under a single .xemacs/ directory is much cleaner and I am yet to see any good and objective reason for not doing so since until now I've only seen vain religious arguments. Of course, as usual, we should leave the option to the user to not use this scheme and have all his init/options/preferences/whatever files in the root directory... Sigh... Makes me think of a quite old professor here who never got used to using directories to put a little order in his files, instead he uses prefixes like a-xxx, a-yyy... Except for the unbelievable mess he now has in his home directory I could never see the difference with using a/xxx a/yyy... I currently have 98 hundred .* files (after deleting ~ files) in my home directory, I think it's enough of a mess not to have XEmacs add more... I believe that .xemacs/ should clearly be the default and multiple files in ~/ the option, not the opposite. Oscar

2 participants
1 comments

Re: custom-file 25 years, 12 months

Didier Verna

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > Jan> Hrvoje Niksic <hniksic(a)srce.hr> writes: > Jan> 3. We have .xemacs anyway for the package system. > > 3. is a reason *not* to use it for startup files. ~/.xemacs is a > package hierarchy. There's no lasting guarantee that its layout will > support putting random .el files in its root. I don't understand what you mean. Could you clarify ? In a long term, we could consider startup stuff as a virtual package, belonging to .xemacs/lisp (say .xemacs/lisp/startup or init), in which we would have at least a user file and a custom file. If one day we want another file (like early.el), well it's easy to do. Many softwares have a .foobarrc/ startup and configuration directory. For us, it seems coherent to make it behave as a package. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C214 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 80 72 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: custom file .xemacs and all that jazz. 25 years, 12 months

Michael Sperber

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: >> ;; This depends on init-file-user through early-package-path >> (setq custom-file (or (locate-library "options" nil >> early-package-load-path ) custom-file)) Hrvoje> I don't like this. early-package-load-path has a well-defined meaning Hrvoje> and is orthogonal to custom-file location. Linking them like this Hrvoje> looks like inviting trouble. Exactly. I'll veto anything that fucks with ~/.xemacs as a package hierarchy pure and simple. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: custom-file 25 years, 12 months

Didier Verna

Oscar Figueiredo <Oscar.Figueiredo(a)di.epfl.ch> writes: > Well, having read the arguments for and against the creation of an .xemacs/ > directory, I must say I am much more convinced by the arguments in favour. OK. I don't want to make this duscussion last forever. The directory issue can indeed be postponed to 21.1. However, there's still this problem of writing custom stuff into .emacs. I'm sorry[1] but to me this issue is important enough to postpone the 21.0 release. Imagine the poor guy that uses XEmacs to try it, Customize and save some variables. Now next time he starts stallmacs, his .emacs full of custom stuff will blow in his face ?! I *know* it's the way it is in 20.[3,4]. I just can't beleive it :-/ Really, can't we afford one or two more weeks of `feature unfreeze' to solve this[2] ? Footnotes: [1] Steve, don't shoot :-) [2] Steve, don't shoot either :-)

1 participants
0 comments

Re: custom-file 25 years, 12 months

Michael Sperber

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> Hrvoje Niksic <hniksic(a)srce.hr> writes: >> Just for the record, I agree with this. Even without `.xemacs/', >> custom-file should default to something other than `.emacs'. To do >> so, we must make sure that: >> >> 1) Old `.emacs' files with custom options are handled gracefully; >> >> 2) The new `.xemacs-custom' file is loaded automatically, after >> `.emacs'. Jan> I suggest not using an .xemacs-custom file but use .xemacs/options.el Jan> even if we do not use .xemacs/init.el, because Jan> 1. We already have been doing it (unintentionnaly) and it seems to Jan> work. Jan> 2. Having an .xemacs-custom file is making the (eventual) migration to Jan> .xemacs/ based system even more difficult as it is yet another file Jan> to care for. Jan> 3. We have .xemacs anyway for the package system. 3. is a reason *not* to use it for startup files. ~/.xemacs is a package hierarchy. There's no lasting guarantee that its layout will support putting random .el files in its root. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

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