GNU bug report logs - #14943
24.3.50; Now just making text invisible locks the file for editing

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14943 in the body.
You can then email your comments to 14943 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Now just making text invisible locks the file for editing
Date: Tue, 23 Jul 2013 22:50:22 -0700 (PDT)

emacs -Q

Visit a file and make some text invisible, e.g., using C-S-mouse-2 > 
Special Properties > Invisible.  That's all.

emacs -Q ; another session.

Visit the same file and try to make some other text invisible.

You get this (nearly incomprehensible) prompt:

"...part-of-name.el locked by dradams <at> DRADA... (pid 6928): (s, q, p, ?)? "

When is Emacs going to stop treating operations like changing text
properties the same way it treats normal edits that would affect the
file if saved?  This is silly.  There is buffer modification and buffer
modification.  This kind of modification - changing text properties - is
not something we should be locking a file for and warning users about.

And then if you can actually figure out that to be able to figure out
the message/prompt you can hit `?' for help, and if you do that, you get
this lovely explanation:

  It has been detected that you want to modify a file that someone else
  has already started modifying in Emacs.

  You can <s>teal the file; the other user becomes the
    intruder if (s)he erver unmodifies the file and then changes it again.
  You can <p>roceed; you edit at your own (and the other user's) risk.
  You can <q>uit; don't modify this file.

I don't even know what to say about how bad that is.

And FWIW I typed it all in - it does not get logged to *Messages* and I
didn't realize it was available in *Help* after I tried to click it to
select it and *Help* disappeared!  This is what happened when I clicked
*Help* (only the second msg appeared in the echo area; both messages are
taken from *Messages*):

ask-user-about-lock: Non-character input-event
mouse-minibuffer-check: Wrong type argument: window-valid-p, #<window 04f6b1b8>

Pretty bad, Emacs.  You can do much better.


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-07-14 on ODIEONE
Bzr revision: 113423 lekktu <at> gmail.com-20130715004922-i67tg2ois14h3fpm
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 CFLAGS='-O0 -g3' CPPFLAGS='-Ic:/Devel/emacs/include'
 LDFLAGS='-Lc:/Devel/emacs/lib''

Message #8 received at 14943 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: 14943 <at> debbugs.gnu.org
Subject: RE: bug#14943: 24.3.50; Now just making text invisible locks the file
 for editing
Date: Tue, 23 Jul 2013 23:04:16 -0700 (PDT)

Also:  When editing in the first session, save the file after making
some text invisible.  Then in the second session there is no conflict.
And you see the invisible text anyway - the invisibilty was not saved.

This shows, if it wasn't already clear, that the buffer modification
made no difference for saving, unlike, say, the addition of enriched-text
properties, which do get saved.

Why on earth are we considering that there is an edit conflict if no
savable change has been made to the buffer?  The is quite misguided, AFAICT.

Message #11 received at 14943 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: 14943 <at> debbugs.gnu.org
Subject: RE: bug#14943: 24.3.50; Now just making text invisible locks the file
 for editing
Date: Tue, 23 Jul 2013 23:11:51 -0700 (PDT)

Using the same menu to add property read-only does NOT show the buffer
as modified, and thus does NOT manifest an edit conflict with another
session.  That is how the other items on the same menu should be handled
too.

Besides the edit conflict, just trying to kill the buffer or exit Emacs
brings up the same problem: Emacs thinks you have really modified the
buffer in a way such that if you kill it your changes will be lost for
the file.  Of course they will!  These are not changes that are ever
saved in the file.

Message #14 received at 14943 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 14943 <at> debbugs.gnu.org
Subject: Re: bug#14943: 24.3.50;
 Now just making text invisible locks the file for editing
Date: Fri, 07 Feb 2014 21:23:55 -0800

Drew Adams <drew.adams <at> oracle.com> writes:

> Visit a file and make some text invisible, e.g., using C-S-mouse-2 > 
> Special Properties > Invisible.  That's all.
>
> emacs -Q ; another session.
>
> Visit the same file and try to make some other text invisible.
>
> You get this (nearly incomprehensible) prompt:
>
> "...part-of-name.el locked by dradams <at> DRADA... (pid 6928): (s, q, p, ?)? "

Yeah, adding text properties to a buffer marks it as changed (which is
correct, I guess).  But is that really useful for buffers that
correspond to files?

On the other hand, it's one of the "why did you do that, then?" issues.
Why would you do that?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #17 received at 14943 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 14943 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#14943: 24.3.50;
 Now just making text invisible locks the file for editing
Date: Sat, 08 Feb 2014 11:21:52 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Fri, 07 Feb 2014 21:23:55 -0800
> Cc: 14943 <at> debbugs.gnu.org
> 
> Yeah, adding text properties to a buffer marks it as changed (which is
> correct, I guess).  But is that really useful for buffers that
> correspond to files?

How can Emacs know whether these text properties will or won't be
saved on disk?  That depends on the major mode: e.g., in enhanced-text
mode, they will be on disk.

Message #20 received at 14943 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14943 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#14943: 24.3.50;
 Now just making text invisible locks the file for editing
Date: Tue, 11 Feb 2014 03:48:10 -0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi <at> gnus.org>
>> Date: Fri, 07 Feb 2014 21:23:55 -0800
>> Cc: 14943 <at> debbugs.gnu.org
>> 
>> Yeah, adding text properties to a buffer marks it as changed (which is
>> correct, I guess).  But is that really useful for buffers that
>> correspond to files?
>
> How can Emacs know whether these text properties will or won't be
> saved on disk?  That depends on the major mode: e.g., in enhanced-text
> mode, they will be on disk.

True.  I think just leaving it as is is the most likely general
solution.  Closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.