From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: dgutov@yandex.ru, 13743@debbugs.gnu.org
Subject: bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere
Date: Mon, 25 Feb 2013 13:29:57 -0500 [thread overview]
Message-ID: <jwvehg4s1bu.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83y5ecic2p.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 25 Feb 2013 18:37:50 +0200")
>> >> The manifestation of the problem will be that modify_region will be
>> >> called in this case, although we don't actually modify anything. You
>> >> will probably see the "modified" indicator on the mode line, something
>> >> that shouldn't have happened.
>> > That is indeed what happens.
>> > OTOH, the existing behavior in this area is rather messy anyway:
>> Not only that, but it's not clear why "that shouldn't have happened".
> Because we announce that the buffer was changed when in fact it
> wasn't. That's a lie. (It also causes redisplay to work harder as a
> side effect.)
That's a widespread "lie". E.g. turn on overwrite-mode and replace the
char at point with itself: sure enough the buffer is marked as modified.
Along the same lines, try (setq t t) and watch how it complains that
we're trying to modify a read-only object, ...
> You can repeat the last 2 steps forever, the buffer always becomes
> modified. I don't see how this could be anything but a bug. Not a
> catastrophe, I agree, but a bug nonetheless.
add-text-property is a mutation operation, like setq. Whether or not it
returns data about the "old state" doesn't make it less of
a side-effecting operation, in my eyes. So, no I do not consider it to
be a bug at all.
Try (add-text-properties 2 10 '(foo nil)) for another corner case: the
`foo' property was already nil (by default), and yet add-text-properties
claims that setting it to nil is a modification.
>> And I don't think it's an important one here, since (as Dmitry points
>> out) the likely most common case (of having `start' be right at the
>> beginning of an interval object) didn't work anyway
> It does work now. More importantly, it fixed the original crash.
I suspect it only works around the crash by optimizing away the call
to modify_region in the particular case you're testing.
>> and furthermore most calls to add-text-properties are likely to be
>> protected by inhibit-modification-hooks.
> I don't think inhibit-modification-hooks stops the file-locking prompt
> from being shown, does it?
Well, I meant not just inhibit-modification-hooks but
with-silent-modifications (or a comparable set of let-bindings and
unwind-protect), which does prevent the prompt.
Stefan
next prev parent reply other threads:[~2013-02-25 18:29 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-18 6:41 bug#13743: 24.2.93; Segmentation fault when trying to [s]teal a file opened elsewhere Dmitry Gutov
2013-02-18 16:11 ` Eli Zaretskii
2013-02-19 0:52 ` Dmitry Gutov
2013-02-20 19:31 ` Eli Zaretskii
2013-02-21 8:30 ` Dmitry Gutov
2013-02-18 19:35 ` Glenn Morris
2013-02-19 0:55 ` Dmitry Gutov
2013-02-21 5:16 ` Paul Eggert
2013-02-21 7:03 ` Dmitry Gutov
2013-02-23 3:37 ` Dmitry Gutov
2013-02-23 15:10 ` Eli Zaretskii
2013-02-23 16:59 ` Stefan Monnier
2013-02-23 18:44 ` Eli Zaretskii
2013-02-24 15:28 ` Dmitry Gutov
2013-02-24 15:50 ` Eli Zaretskii
2013-02-25 5:52 ` Dmitry Gutov
2013-02-25 15:25 ` Stefan Monnier
2013-02-25 16:37 ` Eli Zaretskii
2013-02-25 18:29 ` Stefan Monnier [this message]
2013-02-25 18:56 ` Eli Zaretskii
2013-02-25 20:28 ` Stefan Monnier
2013-02-26 3:39 ` Eli Zaretskii
2013-02-26 4:35 ` Stefan Monnier
2013-03-02 9:30 ` Eli Zaretskii
2013-02-25 16:25 ` Eli Zaretskii
2013-02-25 18:27 ` Dmitry Gutov
2013-02-25 16:27 ` Eli Zaretskii
2013-02-25 19:08 ` Dmitry Gutov
2013-02-25 19:31 ` Eli Zaretskii
2013-02-25 23:23 ` Dmitry Gutov
2013-02-26 3:51 ` Eli Zaretskii
2013-02-26 3:59 ` Dmitry Gutov
2013-02-26 18:42 ` Eli Zaretskii
2013-02-27 17:46 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvehg4s1bu.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=13743@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.