From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#13949: 24.4.1; `fill-paragraph' should not always put the buffer as modified Date: Mon, 28 Mar 2016 17:39:18 +0200 Message-ID: References: <56F12360.5030301@ro.ru> <83y49a4hga.fsf@gnu.org> <56F1837D.4060300@ro.ru> <83io0e4b5r.fsf@gnu.org> <56F19203.5040501@ro.ru> <87a8lkd2bc.fsf@wanadoo.es> <83lh54ynol.fsf@gnu.org> <83a8ljzz3h.fsf@gnu.org> <8360w7zyh3.fsf@gnu.org> <83twjqy6p7.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1459179628 18268 80.91.229.3 (28 Mar 2016 15:40:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Mar 2016 15:40:28 +0000 (UTC) Cc: 13949@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 28 17:40:15 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1akZH4-0001Jg-Qn for geb-bug-gnu-emacs@m.gmane.org; Mon, 28 Mar 2016 17:40:14 +0200 Original-Received: from localhost ([::1]:41389 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akZH3-0000on-UM for geb-bug-gnu-emacs@m.gmane.org; Mon, 28 Mar 2016 11:40:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50074) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akZGv-0000jp-IR for bug-gnu-emacs@gnu.org; Mon, 28 Mar 2016 11:40:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akZGs-0004Ix-C0 for bug-gnu-emacs@gnu.org; Mon, 28 Mar 2016 11:40:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45083) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akZGs-0004Ij-9f for bug-gnu-emacs@gnu.org; Mon, 28 Mar 2016 11:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1akZGs-0003bq-2s for bug-gnu-emacs@gnu.org; Mon, 28 Mar 2016 11:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Magne Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Mar 2016 15:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13949 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13949-submit@debbugs.gnu.org id=B13949.145917956813826 (code B ref 13949); Mon, 28 Mar 2016 15:40:02 +0000 Original-Received: (at 13949) by debbugs.gnu.org; 28 Mar 2016 15:39:28 +0000 Original-Received: from localhost ([127.0.0.1]:42210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akZGK-0003aw-5D for submit@debbugs.gnu.org; Mon, 28 Mar 2016 11:39:28 -0400 Original-Received: from hermes.netfonds.no ([80.91.224.195]:51219) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1akZGI-0003al-CK for 13949@debbugs.gnu.org; Mon, 28 Mar 2016 11:39:27 -0400 Original-Received: from cm-84.215.1.64.getinternet.no ([84.215.1.64] helo=stories) by hermes.netfonds.no with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84_2) (envelope-from ) id 1akZGA-0002jB-R8; Mon, 28 Mar 2016 17:39:24 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWmnIgWEhQ2LygLCAf2 9e0FAwNqYVX5YNi4AAACSUlEQVQ4jXWTTW/cIBCGJ1uL84Iln81ky7mEOGc3QrkniDumq/n/P6Ev eL1qEvWVbCwezycD6f+ItJYixc66bGfSohU2je2gVilVtMhUbkBr38FWxU1exM1Gtg7Gw0Ls1Czm yWyn7VMMgqvtXJxUJXfQZazlr1ntstZqg5XtF/CtjiIidSIlTezs1FfWRCut6zWuRO0ZKiuKkdni 3bXioQ1QsXMV0WiId70pXYZYGY6YSfbNxt/Y8bCqiryNaRbDASYiIWsnvrk6HSCc0AXh68mxJy7C dzDxXEgNa6mefHUl7hms+oUgNRDDwqCBVNYdhKGRAa03ZDWP2ogMDeg5xkqq5qDpMdgljHo5A1gv 8ETCeTEUgs9pSfkJYNOTFOSFXzX5EHLKOZsGjChFpdSAOvy45KZmUYsgE2qAyQAEgPfYuguJqA6a q665bytSqo6px9hd5YCvxGiEVBvaXB2gpZCqm5XU8MnVgZeEHW++gdzA8sRw9RmEABB2sAdJHn94 xoRgtM7UQLhlpVGm4KiQ8DUSou3AGwDk61B9nYSCH5E/vBm2SzIOQ4fbgilpObzrZbdI4lCh23hS FNCr1OJ7rfPHZuCqVntZ0d0whiZYJC+zwjRYd11x7k2mv8OLmqgQbWaWfg2aSVuX88m3Fls71wP4 tuYniwoxchWu2kY4wGxTbfMgl7gD3135NP8EKEqVA/QYo3+Jfxxd9/H/9w6ac/x9iuoGjubiAD9+ xdeH4cf1BtL9KN6f4+t2fXjewXLfzx+X+Pp4kR38BRmy4Rg7+HvcAAAAAElFTkSuQmCC In-Reply-To: <83twjqy6p7.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 28 Mar 2016 18:15:32 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:115651 Archived-At: Eli Zaretskii writes: > The intervals do store the property itself, but I actually don't > understand why should you bother discerning between faces and the > other properties. If the buffer text is really unchanged, the face > properties will be identical as well, right? [...] > There are a couple of properties that have special meaning for fill.el > functions, see there. > > However, I thought you are working on infrastructure that isn't > supposed to be limited to what M-q does. Was I mistaken? Well, this is all kinda exploratory. What's feasible to do in general, and if nothing general can be done, can we still do something for `M-q'? In general: It would be really nice if `buffer-modified-p' really said whether the buffer was changed or not. That is, load a file, add an "a", delete the "a", and Emacs says "unchanged". If we had that mechanism, `M-q' would fall out naturally as a result. But as far as I can tell, this isn't really feasible because of the way we handle text properties: We consider some of them to change the buffer, and some of them to not change the buffer. And it doesn't look like we actually store that information in the text properties themselves. (Please correct me if I'm wrong or you have an idea for how to make this work.) So on to the specific problem of `M-q' again: If we think the general solution is a no go, would it still make sense to do the hash-the-buffer solution just for `M-q'? That is, does `M-q' ever change text properties in a way that we want maintained without changing the text itself? I think the answer to the last question is "no", but I'm not sure. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no