Close .emacs file after customization?

Close .emacs file after customization?

[Kevin A. Burton (burtonator)]

If the user is running with a fresh Emacs instance (no open buffers), then
customizes a variable, the .emacs file is left as an open buffer.

Why is this?  Is there a reason?

It would seem that we should pollute the buffer list if the .emacs file hasn't
already been opened manually.

This isn't a theoretical problem.  I am trying to run multiple .emacs versions
and I want to maintain the same customization options across Emacs instances.

If I open the .emacs file in one instance, customize it, then do the same in
another instance, they both have an open copy of the buffer and there are race
conditions as to which emacs version should be modifying the file.

Can we just fix customization to close the .emacs file after it modifies it?

Kevin

-- 
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burton@peerfear.org )
             Location - San Francisco, CA, Cell - 415.595.9965
           AIM - sfburtonator,  Web - http://www.peerfear.org/
        GPG fingerprint: 4D20 40A0 C734 307E C7B4  DCAA 0303 3AC5 BD9D 7C4D
         IRC - openprojects.net #infoanarchy | #p2p-hackers | #reptile

Who wants to be responsible?  Every time something goes wrong they say 'who's
responsible for this?'
  -- Jerry Seinfeld

Re: Close .emacs file after customization?

[Kevin Rodgers]

Kevin A. Burton (burtonator) wrote:

> This isn't a theoretical problem.  I am trying to run multiple .emacs versions
> and I want to maintain the same customization options across Emacs instances.
> 
> If I open the .emacs file in one instance, customize it, then do the same in
> another instance, they both have an open copy of the buffer and there are race
> conditions as to which emacs version should be modifying the file.

Shouldn't the locking mechanism at least ask you what to do before editing or
saving the buffer?

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: Close .emacs file after customization?

[Kevin A. Burton (burtonator)]

Kevin Rodgers <kevin.rodgers@ihs.com> writes:

> Kevin A. Burton (burtonator) wrote:
> 
> > This isn't a theoretical problem.  I am trying to run multiple .emacs versions
> > and I want to maintain the same customization options across Emacs instances.
> > If I open the .emacs file in one instance, customize it, then do the same in
> > another instance, they both have an open copy of the buffer and there are race
> > conditions as to which emacs version should be modifying the file.
> 
> Shouldn't the locking mechanism at least ask you what to do before editing or
> saving the buffer?
<snip/>

It does in some situations but it isn't as persistent as I would like.

It is also just VERY annoying.

Kevin

-- 
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burton@peerfear.org )
             Location - San Francisco, CA, Cell - 415.595.9965
           AIM - sfburtonator,  Web - http://www.peerfear.org/
        GPG fingerprint: 4D20 40A0 C734 307E C7B4  DCAA 0303 3AC5 BD9D 7C4D
         IRC - openprojects.net #infoanarchy | #p2p-hackers | #reptile

Heil Bush!

Re: Close .emacs file after customization?

[Richard Stallman]

    Can we just fix customization to close the .emacs file after it modifies it?

It would be reasonable to delete the buffer afterwards if the buffer
was newly created for the purpose.  Would you like to implement it?

Re: Close .emacs file after customization?

[Kevin A. Burton (burtonator)]

Richard Stallman <rms@gnu.org> writes:

>     Can we just fix customization to close the .emacs file after it modifies it?
> 
> It would be reasonable to delete the buffer afterwards if the buffer
> was newly created for the purpose.  Would you like to implement it?

Now that I have signed papers I might take care of this...

Kevin

-- 
Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burton@peerfear.org )
             Location - San Francisco, CA, Cell - 415.595.9965
           AIM - sfburtonator,  Web - http://www.peerfear.org/
        GPG fingerprint: 4D20 40A0 C734 307E C7B4  DCAA 0303 3AC5 BD9D 7C4D
         IRC - openprojects.net #infoanarchy | #p2p-hackers | #reptile

This email has been secured with rot26 encryption; any attempt at circumvention
is illegal within the US under the DMCA and will be prosecuted to the fullest
extent of the law.

Re: Close .emacs file after customization?

[Richard Stallman]

    > It would be reasonable to delete the buffer afterwards if the buffer
    > was newly created for the purpose.  Would you like to implement it?

    Now that I have signed papers I might take care of this...

Please do.

Re: Close .emacs file after customization?

[Per Abrahamsen]

burton@openprivacy.org (Kevin A. Burton (burtonator)) writes:

> If I open the .emacs file in one instance, customize it, then do the
> same in another instance, they both have an open copy of the buffer
> and there are race conditions as to which emacs version should be
> modifying the file.
>
> Can we just fix customization to close the .emacs file after it modifies it?

It is possible, but it will not solve the problem.

When saving customizations, customize does not actually read the
customizations in the .emacs. Instead, it deletes *all* of them, and
then saves all those customizations it knows about.  If the user has
added or changed customizations meanwhile from another Emacs instance,
those customizations will be lost.

Re: Close .emacs file after customization?

[Robert J. Chassell]

Per Abrahamsen <abraham@dina.kvl.dk> wrote:

   When saving customizations, customize does not actually read the
   customizations in the .emacs. Instead, it deletes *all* of them,
   and then saves all those customizations it knows about.  If the
   user has added or changed customizations meanwhile from another
   Emacs instance, those customizations will be lost.

Thank you!  This explains some occasional problems I have run into
that I previously attributed to carelessness.

I normally run several instances of GNU Emacs and do not expect this
behavior.  I expect the same behavior as with other conflicting
modifications, a message like this:

    foo changed on disk; really edit the buffer? (y, n, r or C-h) 

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Close .emacs file after customization?

[Richard Stallman]

    > If I open the .emacs file in one instance, customize it, then do the
    > same in another instance, they both have an open copy of the buffer
    > and there are race conditions as to which emacs version should be
    > modifying the file.
    >
    > Can we just fix customization to close the .emacs file after it modifies it?

    It is possible, but it will not solve the problem.

Emacs interlocking should detect automatically when you lose with one
Emacs edits that were made with another Emacs.  If custom visits the
file in the normal way and does not do anything to disable or override
this mechanism, it will operate.

Re: Close .emacs file after customization?

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

>     > If I open the .emacs file in one instance, customize it, then do the
>     > same in another instance, they both have an open copy of the buffer
>     > and there are race conditions as to which emacs version should be
>     > modifying the file.
>     >
>     > Can we just fix customization to close the .emacs file after it modifies it?
>
>     It is possible, but it will not solve the problem.
>
> Emacs interlocking should detect automatically when you lose with one
> Emacs edits that were made with another Emacs.  If custom visits the
> file in the normal way and does not do anything to disable or override
> this mechanism, it will operate.

It will operate, but changes to all but the last Emacs instance to
save the customizations will be lost.

You will get a warning if customize *does not* kill the .emacs buffer
after saving customization, which is currently the case, but that is
precisely what the original poster wanted to change.

Also, you will not get a warning if the user manually kills the .emacs
buffer.

Re: Close .emacs file after customization?

[Richard Stallman]

    You will get a warning if customize *does not* kill the .emacs buffer
    after saving customization, which is currently the case, but that is
    precisely what the original poster wanted to change.

If Emacs already has a buffer visiting .emacs, and that file has
changed on disk, visiting it again will ask whether to reread the
file.  The only advantage of killing the buffer is that you won't have
to answer that question.  Is that a major advantage?

We could make Custom kill the buffer if it didn't exist before
Custom created it.

Re: Close .emacs file after customization?

[David Masterson]

>>>>> Richard Stallman writes:

>     You will get a warning if customize *does not* kill the .emacs buffer
>     after saving customization, which is currently the case, but that is
>     precisely what the original poster wanted to change.

> If Emacs already has a buffer visiting .emacs, and that file has
> changed on disk, visiting it again will ask whether to reread the
> file.  The only advantage of killing the buffer is that you won't
> have to answer that question.  Is that a major advantage?

The other advantage is that it no longer is in memory, but that may
not be major.  I think the real question, though, should be is there a
major advantage to *not* killing the buffer.  This becomes more
important when you remember that it's not about killing the .emacs
buffer, but rather the custom-file buffer.

> We could make Custom kill the buffer if it didn't exist before
> Custom created it.

That's probably preferable to prevent confusion.

-- 
David Masterson                David DOT Masterson AT synopsys DOT com
Sr. R&D Engineer               Synopsys, Inc.
Software Engineering           Sunnyvale, CA

Re: Close .emacs file after customization?

[Richard Stallman]

    > We could make Custom kill the buffer if it didn't exist before
    > Custom created it.

    That's probably preferable to prevent confusion.

Would someone like to implement this?

Re: Close .emacs file after customization?

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

>     You will get a warning if customize *does not* kill the .emacs buffer
>     after saving customization, which is currently the case, but that is
>     precisely what the original poster wanted to change.
>
> If Emacs already has a buffer visiting .emacs, and that file has
> changed on disk, visiting it again will ask whether to reread the
> file.  The only advantage of killing the buffer is that you won't have
> to answer that question.  Is that a major advantage?

Is it an advantage at all?  

Emacs will warn in a situation where there is a very real danger that
it will overwrite some customization saved from another Emacs
instance, i.e. the user will lose some work.  

I'd expect we want a warning in that case.

RE: Close .emacs file after customization?

[Zaretskii Eli]

This message was scanned for viruses and other malicious code by PrivaWall.


This mail was sent from ELTA SYS LTD.


> From: Per Abrahamsen [mailto:abraham@dina.kvl.dk] 
> Sent: Saturday, February 15, 2003 4:10 PM
> 
> When saving customizations, customize does not actually read the
> customizations in the .emacs. Instead, it deletes *all* of them, and
> then saves all those customizations it knows about.  If the user has
> added or changed customizations meanwhile from another Emacs instance,
> those customizations will be lost.

IMHO, this is worth mentioning in the user's manual.

P.S.  Sorry for the possibly messed-up messages you will see from me in
the
near future, as well as for a nasty mailer.  Our sysadmins here changed
the
email setup, and it will take some time for me to recover.  In the
meantime,
I have an alternative of not responding at all, which I decided to
reject.


This message is processed by the PrivaWall Email Security Server.