From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?=C3=93scar?= Fuentes Newsgroups: gmane.emacs.bugs Subject: bug#24074: bug#24094: 25.1.50; revert-buffer error in CC mode Date: Fri, 29 Jul 2016 20:43:03 +0200 Message-ID: <87mvl02slk.fsf@wanadoo.es> References: <20160729175924.11811.qmail@mail.muc.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1469817950 8861 80.91.229.3 (29 Jul 2016 18:45:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Jul 2016 18:45:50 +0000 (UTC) Cc: Alan Mackenzie , 24094@debbugs.gnu.org, 24074@debbugs.gnu.org To: Richard Copley Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jul 29 20:45:38 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 1bTCmv-0003B4-FD for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Jul 2016 20:45:37 +0200 Original-Received: from localhost ([::1]:32861 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTCmp-0008FW-GW for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 Jul 2016 14:45:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTCmf-0008Dy-1w for bug-gnu-emacs@gnu.org; Fri, 29 Jul 2016 14:45:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTCmZ-0006U3-Tm for bug-gnu-emacs@gnu.org; Fri, 29 Jul 2016 14:45:20 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53657) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTCmM-0006Ox-2M; Fri, 29 Jul 2016 14:45:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bTCmL-0001no-TQ; Fri, 29 Jul 2016 14:45:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?=C3=93scar?= Fuentes Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Fri, 29 Jul 2016 18:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24074 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Original-Received: via spool by 24074-submit@debbugs.gnu.org id=B24074.14698178726869 (code B ref 24074); Fri, 29 Jul 2016 18:45:01 +0000 Original-Received: (at 24074) by debbugs.gnu.org; 29 Jul 2016 18:44:32 +0000 Original-Received: from localhost ([127.0.0.1]:50952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bTCll-0001mY-9m for submit@debbugs.gnu.org; Fri, 29 Jul 2016 14:44:32 -0400 Original-Received: from relaycp01.dominioabsoluto.net ([217.116.26.68]:41668) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bTCla-0001jw-KW; Fri, 29 Jul 2016 14:44:24 -0400 Original-Received: from smtp.movistar.es (smtp09.acens.net [86.109.99.133]) by relaycp01.dominioabsoluto.net (Postfix) with ESMTP id 7D9A642E3; Fri, 29 Jul 2016 20:43:04 +0200 (CEST) X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2016.7.29.130618:17:8.317, ip=, rules=__HAS_FROM, __FRAUD_WEBMAIL_FROM, __TO_MALFORMED_2, __TO_NAME, __TO_NAME_DIFF_FROM_ACC, __HAS_CC_HDR, __MULTIPLE_RCPTS_CC_X2, __CC_NAME, __CC_NAME_DIFF_FROM_ACC, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __REFERENCES, __IN_REP_TO, __HAS_MSGID, __SANE_MSGID, __USER_AGENT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __UNUSABLE_MSGID, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_WWW, __SUBJ_ALPHA_NEGATE, __FORWARDED_MSG, BODY_SIZE_1500_1599, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, __URI_NS, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, __FRAUD_WEBMAIL, MULTIPLE_RCPTS, __PHISH_SPEAR_STRUCTURE_1, BODY_SIZE_2000_LESS, IN_REP_TO, REFERENCES, BODY_SIZE_7000_LESS, NO_URI_HTTPS, MSG_THREAD, __TO_REAL_NAMES, __CC_REAL_NAMES, LEGITIMATE_SIGNS, LEGITIMATE_NEGATE Original-Received: from qcore (83.58.75.30) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 579A2B0C0012FB8B; Fri, 29 Jul 2016 18:43:04 +0000 In-Reply-To: (Richard Copley's message of "Fri, 29 Jul 2016 19:16:50 +0100") 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" Xref: news.gmane.org gmane.emacs.bugs:121695 Archived-At: Richard Copley writes: > It's hard to describe precisely (especially as I don't have a > corrupted buffer here and now), but being guided by your question, > we're talking about one or two larger chunks and not at the end of the > buffer but in the "middle". Yes, sometimes the missing chunk(s) are in the middle of the file. AFAIR they are always quite large. I can't confirm the case of more than one chunk, though. Appreciating the damage is complicated by the fact that it not evident what's missing at first sight: in the case I describe on my previous email, when the error happened and swtiched to the affected buffer it only displayed one line (the first one); then, pressed cursor-down and the other eight lines appeared from nowhere. > My impression FWIW is that it is *as if* Emacs has done > "diff-buffer-with-file" and is attempting to apply the resulting patch > to the buffer (perhaps with the laudable intention of saving space in > the undo buffer), and has failed after a deletion and before an > insertion. But that is uninformed speculation. I suspected some undo-related problem when I experienced the problem some weeks ago. Then, disabled undo before the revert on my Magit code: - (revert-buffer t t) + (progn + (setq buffer-undo-list t) + (revert-buffer t t) to no avail. It looks more like a cache issue to me now: c-mode is using some stale info computed before the revert.