bug#14943: 24.3.50; Now just making text invisible locks the file for editing

bug#14943: 24.3.50; Now just making text invisible locks the file for editing

[Drew Adams]

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@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@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''

bug#14943: 24.3.50; Now just making text invisible locks the file for editing

[Drew Adams]

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.

bug#14943: 24.3.50; Now just making text invisible locks the file for editing

[Drew Adams]

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.

bug#14943: 24.3.50; Now just making text invisible locks the file for editing

[Lars Ingebrigtsen]

Drew Adams <drew.adams@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@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/

bug#14943: 24.3.50; Now just making text invisible locks the file for editing

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 07 Feb 2014 21:23:55 -0800
> Cc: 14943@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.

bug#14943: 24.3.50; Now just making text invisible locks the file for editing

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Fri, 07 Feb 2014 21:23:55 -0800
>> Cc: 14943@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/