Re: CLASH_DETECTION option in configure

Re: CLASH_DETECTION option in configure

[Glenn Morris]

rh wrote:

> Will CLASH_DETECTION become a configure option?

No, but `create-lockfiles' will exist as a user option from 24.3
onwards.

Re: CLASH_DETECTION option in configure

[Bob Proulx]

rh wrote:
> It seems like an antiquated feature and it doesn't make sense to
> have it enabled by default. Since version control systems are every
> where now I can't see why anyone would want or use this feature.
> What's the use case?

If you as a single user try to edit a file from two different
terminals then it will be detected and a collision avoided.  I often
run into cases where emacs notifies me that I am already editing a
file in another terminal.  The use case is far from antiquated and has
nothing to do with version control.  Because unintended data loss can
result if it were disabled the feature is enabld by default.

I will turn the same question around on you.  Why would you ever want
to disable this feature?  Why is it causing you difficulty?  If as you
say you would never hit this issue then you should also by that same
reasoning never know it is there either.

Bob

Re: CLASH_DETECTION option in configure

[Stefan Monnier]

> It seems like an antiquated feature and it doesn't make sense to
> have it enabled by default.

AFAICT LibreOffice has the same "antiquated" feature, and I expect many
other "editors" would have it as well.


        Stefan

Re: CLASH_DETECTION option in configure

[Bob Proulx]

rh wrote:
> Bob Proulx wrote:
> > rh wrote:
> > > It seems like an antiquated feature and it doesn't make sense to
> > > have it enabled by default. Since version control systems are every
> > > where now I can't see why anyone would want or use this feature.
> > > What's the use case?
> > 
> > If you as a single user try to edit a file from two different
> > terminals then it will be detected and a collision avoided.  I often
> > run into cases where emacs notifies me that I am already editing a
> > file in another terminal.  The use case is far from antiquated and has
> > nothing to do with version control.  Because unintended data loss can
> > result if it were disabled the feature is enabld by default.
> 
> We may or may not be talking about the same feature. It's possible
> that we are not.

Possibly! :-)

> With this feature disabled emacs stills tells asks me if I really
> want to edit this buffer. So did I think I disabled but didn't? But
> I no longer find those .#filename->hostname files laying around
> either.

There are two or three similar but related features.  One of them
looks at the timestamps of the files.  One of them looks at the lock
information stored in a symlink.  A third notifies if a buffer save is
newer than the current file.

1.
  /tmp/foo locked by rwp@example.... (pid 14294): (s, q, p, ?)?

  This uses uses a symlink in the typical way to store information.

  lrwxrwxrwx 1 40 Feb 12 13:16 .#foo -> rwp@example.14294:1358485837

2.
  foo changed on disk; really edit the buffer? (y, n, r or C-h)
  foo has changed since visited or saved.  Save anyway? (yes or no) 

3.
  foo has auto save data; consider M-x recover-this-file

  This uses a buffer save file #foo# to hold the buffer save.

> > I will turn the same question around on you.  Why would you ever want
> > to disable this feature?  Why is it causing you difficulty?  If as you
> > say you would never hit this issue then you should also by that same
> > reasoning never know it is there either.
> 
> Those .#filename->hostname files were the clue.

My takeaway from this is that the meta-data files created by emacs in
the local directory annoy you and you would like emacs to not make
those files there.  It isn't about the behavior but about the lint
that is placed in the directory to support the feature.

Since there are customizations available to turn off backups (setq
make-backup-files nil) and to move the buffer save file out of the
current directory (see backup-directory-alist variable) it would make
sense if there were also a control to change the directory for lock
symlinks too.

And actually backup-directory-alist seems like it should affect both.
But when I tried backup-directory-alist just now I couldn't get it to
function for me.  Don't know why.

Bob