* bug#14943: 24.3.50; Now just making text invisible locks the file for editing
@ 2013-07-24 5:50 Drew Adams
2013-07-24 6:04 ` Drew Adams
2014-02-08 5:23 ` Lars Ingebrigtsen
0 siblings, 2 replies; 6+ messages in thread
From: Drew Adams @ 2013-07-24 5:50 UTC (permalink / raw)
To: 14943
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''
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#14943: 24.3.50; Now just making text invisible locks the file for editing
2013-07-24 5:50 bug#14943: 24.3.50; Now just making text invisible locks the file for editing Drew Adams
@ 2013-07-24 6:04 ` Drew Adams
2013-07-24 6:11 ` Drew Adams
2014-02-08 5:23 ` Lars Ingebrigtsen
1 sibling, 1 reply; 6+ messages in thread
From: Drew Adams @ 2013-07-24 6:04 UTC (permalink / raw)
To: 14943
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#14943: 24.3.50; Now just making text invisible locks the file for editing
2013-07-24 6:04 ` Drew Adams
@ 2013-07-24 6:11 ` Drew Adams
0 siblings, 0 replies; 6+ messages in thread
From: Drew Adams @ 2013-07-24 6:11 UTC (permalink / raw)
To: 14943
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#14943: 24.3.50; Now just making text invisible locks the file for editing
2013-07-24 5:50 bug#14943: 24.3.50; Now just making text invisible locks the file for editing Drew Adams
2013-07-24 6:04 ` Drew Adams
@ 2014-02-08 5:23 ` Lars Ingebrigtsen
2014-02-08 9:21 ` Eli Zaretskii
1 sibling, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2014-02-08 5:23 UTC (permalink / raw)
To: Drew Adams; +Cc: 14943
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#14943: 24.3.50; Now just making text invisible locks the file for editing
2014-02-08 5:23 ` Lars Ingebrigtsen
@ 2014-02-08 9:21 ` Eli Zaretskii
2014-02-11 11:48 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2014-02-08 9:21 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 14943
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#14943: 24.3.50; Now just making text invisible locks the file for editing
2014-02-08 9:21 ` Eli Zaretskii
@ 2014-02-11 11:48 ` Lars Ingebrigtsen
0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2014-02-11 11:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14943
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/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-02-11 11:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-24 5:50 bug#14943: 24.3.50; Now just making text invisible locks the file for editing Drew Adams
2013-07-24 6:04 ` Drew Adams
2013-07-24 6:11 ` Drew Adams
2014-02-08 5:23 ` Lars Ingebrigtsen
2014-02-08 9:21 ` Eli Zaretskii
2014-02-11 11:48 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).