Migrating .emacs Configuration File to Newer Emacsen

Migrating .emacs Configuration File to Newer Emacsen

[Norbert Grün]

Dear Madam or Sir!

This mail is CC-ed to the FSF which is the real home of Emacs.

But you should be notified of the problem.

This may take off load from your support.

Please avoid pointing at each other blaming for the fault, Emacs
maintenance should be in cathedral mode instead of bazaar mode because 
it
is an important infrastructure and deregulation and privatising
infrastructures hasn't yielded the benefits promised, but worsened 
service
and quality below former public maintenance which will make shareholder
value go down rapidly in the not too far future. Deregulation also 
already
ruins private industry in the same way. A turbocharger needs a 
wastegate!
And of course, one should keep his hands at the steering wheel!

The version of Emacs of your Cygwin distribution is:

GNU Emacs 21.2.1 (i686-pc-cygwin, X toolkit) of 2004-03-22 on cm-test

copied via the menu of the Windows console window.

The version of NTEmacs I tried to borrow the .emacs file from is:

GNU Emacs 20.7.1 (i386-*-nt5.1.2600) of Tue Jun 13 2000 on buffy

tediously typed because that kill ring doesn't interface to the Windows
Clipboard and the message buffer refuses to be written to a file.

Cygcheck reports DLL version 1.5.12 Build date: Wed Nov 10 08:34:47 EST
2004 Shared id: cygwin1S4.

Package information reveals:

cygwin 1.5.12-1

emacs 21.2-13

NTEmacs 20.7.1 also reveals my OS version, but misses to detect SP2 of 
XP
Pro.

It happily ran on NT4 and W2k before. Only some "dirty" Win-16 programs
stopped working after NT4, most notably dBase V, dBase IV runs fine, 
they
have "cleaned" up the Win-16 API in W2k and XP.

Also almost all key bindings work, you can turn off the reservation of 
some
Windows key combinations in the properties of a *.PIF file, but nowhere
else.

Emacs 21.2.1 surprisingly ignores some traditional key bindings that 
are not
affected by pc-bindings-mode or related modes on older Emacsen, most
notably "C-x C-c", but also "C-@" and "C-SPC" which self-insert 
the "@" and
"SPC" instead of setting the mark. Happens both in the Cygwin console
window and in emacs-nox.

Copying the .emacs file over to Cygwin's place resulted in a spate of 
error
messages during Emacs 21.2.1 startup, I'd rather expected a few from 
file
system references which are only three in two commands.

Aye, I can fire up both and tediously browse both customisation trees 
one
by one, but I'd prefer a tool that takes the old .emacs file and 
converts
it to the new format. Perhaps in a "migrate.el(c)?" thus using Emacs'
power?

Note I am myself a former serviceman for mission-critical embedded
computers. I got my money by helping my customers to get back into 
business
as fast as possible.

Thus tools like that suggested are not only helpful for the uninitiated
beginner, especially under Windows, which hath made all nightmares of 
old
CLI hackers like me (30 years practical experience) back in old Apple 
LISA
days come true.

But also professionals that have to achieve their results quickly. 
Wasting
too much time will fall back on the serviceman instead of his boss
depriving him of decent tools. Maintaining price lists is a nightmare
through masks instead of using an equivalent of dBase' BROWSE command
albeit such a table doesn't need transactional integrity otherwise 
demanded
by the tax office. This is called "principles of proper accounting".

Software is an infrastructure and file formats are alphabets, the Latin
alphabet you read here has been invented as "ABC" over 2,000 years ago,
"abc" about 1,200 years ago in nearby Aix-la-Chapelle, and "123" 
imported
via Adam Riese's book about 500 years ago. Efforts are taken to rescue
documents on chlorinate-bleached paper which starts to rot away after 
200
years of storage, let alone the bookworms.

Exactly this should be the mission of OpenSource, Billy might get away
locking all the world's documents into his formats, it might backfire 
only
after he got full Alzheimer. After me the flood!

Kind Regards

Norbert Grün (gnor-spam@x-mail.net) not overflooded with spam from
newsgroup posts :-)






--

Stop wasting everybody else's ressources!
-------------------------------------------------------------------------------------------
Voice Messages, Voice Calls (VoIP), Video Conferencing, http://www.x-mail.net
Anonymous SSL Web Surfing, http://www.snoopblocker.com
Search http://www.teradex.com

Re: Migrating .emacs Configuration File to Newer Emacsen

[Richard M. Stallman]

    Please avoid pointing at each other blaming for the fault, Emacs
    maintenance should be in cathedral mode instead of bazaar mode because 
    it
    is an important infrastructure and deregulation and privatising
    infrastructures hasn't yielded the benefits promised, but worsened 
    service
    and quality below former public maintenance which will make shareholder
    value go down rapidly in the not too far future.

I am not sure whether I agree, but I think the main problem with
Emacs maintenance is that I don't have enough time to spend on it.
Other people do some of the jobs that I used to do, but some jobs
don't have someone to do them.

Re: Migrating .emacs Configuration File to Newer Emacsen

[Juanma Barranquero]

On 8/6/05, Richard M. Stallman <rms@gnu.org> wrote:

> but some jobs
> don't have someone to do them.

Perhaps no one feels qualified to do them properly.

-- 
                    /L/e/k/t/u

Re: Migrating .emacs Configuration File to Newer Emacsen

[Richard M. Stallman]

    > but some jobs
    > don't have someone to do them.

    Perhaps no one feels qualified to do them properly.

I wish someone who doesn't feel qualified would tackle the job and do
the best he can.

Re: Migrating .emacs Configuration File to Newer Emacsen

[Juanma Barranquero]

On 8/8/05, Richard M. Stallman <rms@gnu.org> wrote:

> I wish someone who doesn't feel qualified would tackle the job and do
> the best he can.

Well, what are those jobs? Perhaps simply people is not fully aware.
Are you talking about the admin/FOR-RELEASE stuff?

-- 
                    /L/e/k/t/u

Re: Migrating .emacs Configuration File to Newer Emacsen

[Kevin Rodgers]

Norbert Grün wrote:
 > Copying the .emacs file over to Cygwin's place resulted in a spate of
 > error messages during Emacs 21.2.1 startup, I'd rather expected a few
 > from file system references which are only three in two commands.
 >
 > Aye, I can fire up both and tediously browse both customisation trees
 > one by one, but I'd prefer a tool that takes the old .emacs file and
 > converts it to the new format. Perhaps in a "migrate.el(c)?" thus
 > using Emacs' power?

The problem is that .emacs can contain any Emacs Lisp form, so it's not
amenable to conversion -- except for the forms inserted by custom.

Is it possible to dump the entire customization tree, perhaps by writing
out every customizable variable (whether it was actually customized or
not)?  Doing so in an uncustomized emacs would give you a file for a
simple diff-based comparison between 2 different Emacs versions -- it
could even be included in the distribution.  Of course, someone would
have to go back and generate that file for previously released versions
of Emacs, but it might be a worthwhile exercise.  If the differences
between 2 Emacs versions can be resolved by mapping old variable names
to new ones etc. then it should be possible to write a useful version of
migrate.el

-- 
Kevin Rodgers

Re: Migrating .emacs Configuration File to Newer Emacsen

[Richard M. Stallman]

    Well, what are those jobs? Perhaps simply people is not fully aware.
    Are you talking about the admin/FOR-RELEASE stuff?

Yes--and the messages I occasionally send to emacs-devel asking
for someone to try to debug a problem.

Re: Migrating .emacs Configuration File to Newer Emacsen

[Juanma Barranquero]

On 8/9/05, Richard M. Stallman <rms@gnu.org> wrote:

> Yes--and the messages I occasionally send to emacs-devel asking
> for someone to try to debug a problem.

With respect to the second point: almost all of these problems are on
Unix or Unix-like systems.

Regarding the first one: most items on FOR-RELEASE are doc-related. I
think you should ban all commits on the trunk until the documentation
has been thoroughly checked :)  [only half-joking]

-- 
                    /L/e/k/t/u