[comp.emacs] .emacs blues on firing up Xemacs 21.4.4 - XEmacs-Beta - XEmacs Mailing List Archives

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

[comp.emacs] .emacs blues on firing up Xemacs 21.4.4

Bug report/fix - 'dired' failing...

XEmacs 21.5.8 Segmentation fault

Adrian Aichner

Monday, 19 August 2002 Mon, 19 Aug '02

8:12 p.m.

(permalink)

Hi Michael, do you want to answer this :-) Adrian -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

Attachments:

attachment.mht (message/rfc822 — 52 bytes)

Reply

Show replies by date

Stephen J. Turnbull

Tuesday, 20 August Tue, 20 Aug

6:25 a.m.

(permalink)

>>>> "APA" == Adrian Aichner <adrian(a)xemacs.org> writes:

APA> Hi Michael, do you want to answer this :-) It's a bug, it's fixed. AM> I built and fired up Xemacs 21.4.4 for the first time AM> yesterday. I'm somewhat unhappy about what's happened to my AM> ~/.emacs (GNU Emacs 21.1 vintage). Yes. We're very sorry about that. The only hope you have is that if you have an running GNU Emacs with the customizations in it, saving customizations will probably do the right thing. AM> Mind if I ask a couple of questions? 1/ Did Xemacs 21.4.4 AM> leave a backup of my .emacs anywhere, and if so, where? No, it did not. It should, but doesn't. Note that this kind of thing can happen anyway, because of the way Customize works. The migration policy just makes it an accident waiting to happen. I think "migration" is actually a pretty accurate description of what happens. Nothing (assuming .emacs loads successfully) is changed; the contents of .emacs are simply moved into two new files, .xemacs/init.el and .xemacs/custom.el (which once done is a lot safer than having a single .emacs which Emacs edits behind your back). AM> 2/ Did the program actually remove my existing customisation AM> settings from my .emacs, or was that my own fumbling? XEmacs did. What happens is that Custom _never_ backs up your customizations, it just overwrites them. If there is an error in .emacs _before_ your customizations, then your customizations do not get loaded into (X)Emacs. If you then save your (nonexistent) in-core customizations, Custom happily wipes out the existing saved customizations. The migration policy makes this far more likely for two reasons. (1) The new version of (X)Emacs may introduce changes that cause errors in .emacs. (2) It automatically saves customizations (something a user is unlikely to do if .emacs is broken). -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

Reply

Michael Sperber

Tuesday, 20 August Tue, 20 Aug

7:48 a.m.

(permalink)

AM> From: Alan Mackenzie<none(a)example.invalid> AM> Subject: .emacs blues on firing up Xemacs 21.4.4 AM> Newsgroups: comp.emacs AM> Date: Mon, 19 Aug 2002 18:42:34 +0000 AM> Organization: muc.de e.V. -- private internet access AM> Hi, guys. AM> I built and fired up Xemacs 21.4.4 for the first time yesterday. I'm AM> somewhat unhappy about what's happened to my ~/.emacs (GNU Emacs 21.1 AM> vintage). AM> The first thing that happened was that I was yes-or-no-p'd (or was it AM> y-or-n-p'd?) with something like: "_migrate_ your .emacs file?". AM> 'What the fine does "migrate" mean?', I asked myself. Second time round, AM> I was brave enough to say yes. Big mistake. My .emacs file was moved AM> away, renamed, and possibly broken. Shortly afterwards, I copied it back AM> to ~/.emacs so that GNU Emacs would still work properly. AM> Between yesterday and today, I have lost all the GNU Emacs customisations AM> I previously had. Now I'm not saying for sure that Xemacs did this (it AM> could well have happened when I copied the file back to ./~emacs, then AM> starting editing something (either .init or .emacs, I can't remember) AM> when various GNU specific things stopped the initial evaluation of AM> .init). AM> But all the same, using such a woolly meaningless word like "migrate" AM> (the sort of language that Microsoft might use before shafting your AM> Windows system with "new improved" DLL versions) doesn't seem like a AM> generous policy. Surely the least I could've expected would be a prompt AM> along the lines of: "We're going to edit your .emacs, shifting it to AM> ~/.xemacs/.init, but we'll leave a backup of your original file in AM> <wherever>. Is that OK?". Or was there some such message that I missed? Yes, there should have been. The text displayed is:

XEmacs recommends that the initialization code in [...] be migrated to the [...] directory. XEmacs can perform the migration automatically. After the migration, init.el/init.elc holds user-written initialization code. Moreover the customize settings will be in custom.el. You can undo the migration at any time with M-x maybe-unmigrate-user-init-file. If you choose not to do this now, XEmacs will not ask you this question in the future. However, you can still make XEmacs perform the migration at any time with M-x migrate-user-init-file.

(The [...] will typically be replaced by ".emacs" and ".xemacs".) It should also have asked you whether you want to keep a compatibility .emacs file. Note the possibility of undoing the migration. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

Reply

8124

days inactive

8125

days old

xemacs-beta@xemacs.org

Manage subscription

2 comments

3 participants

tags (0)

participants (3)

Adrian Aichner
Michael Sperber
Stephen J. Turnbull