From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: using text properties in a buffer that is older than its file Date: Fri, 31 Jul 2015 11:20:40 -0700 (PDT) Message-ID: <7af1a5b0-01c2-4095-9cc0-91da98738118@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1438366876 22944 80.91.229.3 (31 Jul 2015 18:21:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Jul 2015 18:21:16 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 31 20:21:04 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZLEvX-0001pj-IR for ged-emacs-devel@m.gmane.org; Fri, 31 Jul 2015 20:21:03 +0200 Original-Received: from localhost ([::1]:45625 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLEvW-0002NV-Tw for ged-emacs-devel@m.gmane.org; Fri, 31 Jul 2015 14:21:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42904) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLEvJ-0002NL-Al for emacs-devel@gnu.org; Fri, 31 Jul 2015 14:20:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZLEvD-0003Rj-9U for emacs-devel@gnu.org; Fri, 31 Jul 2015 14:20:49 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:28043) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLEvC-0003R6-Sb for emacs-devel@gnu.org; Fri, 31 Jul 2015 14:20:43 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t6VIKfcl001564 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 31 Jul 2015 18:20:42 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t6VIKfGJ013378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 31 Jul 2015 18:20:41 GMT Original-Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t6VIKfIh017146 for ; Fri, 31 Jul 2015 18:20:41 GMT X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:188239 Archived-At: Suppose some code just modifies some text properties. This is considered by Emacs to be a buffer modification, and if the file has been changed externally since it was last visited in the Emacs session, then trying to modify the text properties prompts the user with: ... changed on disk; really edit the buffer? (This is done by `ask-user-about-supersession-threat'.) Saving, resetting, and restoring `buffer-modified-p' is not sufficient to inhibit this user prompting. And if the code is called multiple times then the user gets prompted multiple times (assuming a response that keeps the buffer unsynced). What is a good way to inhibit this prompting? Binding `buffer-file-name' to nil works, but is there a better way? Is there now (shouldn't there be?) a way to tell Emacs that within some scope it should not consider text-property changes to be buffer modifications - at least for purposes of consideration by `ask-user-about-supersession-threat'? That would be much better than binding `buffer-file-name', as it could be done around code that might let a user modify the buffer (text changes, not just property changes), and the user would still get prompted for any real text change. I'm hoping that there is already a feature for handling this kind of use case, which I'm just unaware of.