From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) Newsgroups: gmane.emacs.bugs Subject: bug#23785: Emacs 25: 'Undo' overdoes things. Date: Mon, 20 Jun 2016 13:47:59 +0100 Message-ID: <874m8oc9hc.fsf@russet.org.uk> References: <20160617150245.GB3316@acm.fritz.box> <83r3bvbuu1.fsf@gnu.org> <20160617174535.GD3316@acm.fritz.box> <83oa6zbmvd.fsf@gnu.org> <87ziqjwkrb.fsf@russet.org.uk> <83eg7vaq3z.fsf@gnu.org> <83bn2y9v80.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1466427738 23896 80.91.229.3 (20 Jun 2016 13:02:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2016 13:02:18 +0000 (UTC) Cc: acm@muc.de, 23785@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 20 15:02:03 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 1bEypG-0005bY-BR for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Jun 2016 15:01:14 +0200 Original-Received: from localhost ([::1]:43441 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEydf-0002mN-6M for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Jun 2016 08:49:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51032) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEydW-0002kg-PX for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 08:49:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bEydS-0005tj-QB for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 08:49:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:34850) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEydS-0005tf-MH for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 08:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bEydS-0003bQ-Ga for bug-gnu-emacs@gnu.org; Mon, 20 Jun 2016 08:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: phillip.lord@russet.org.uk (Phillip Lord) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Jun 2016 12:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23785 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23785-submit@debbugs.gnu.org id=B23785.146642688713783 (code B ref 23785); Mon, 20 Jun 2016 12:49:02 +0000 Original-Received: (at 23785) by debbugs.gnu.org; 20 Jun 2016 12:48:07 +0000 Original-Received: from localhost ([127.0.0.1]:47187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEycZ-0003aF-KK for submit@debbugs.gnu.org; Mon, 20 Jun 2016 08:48:07 -0400 Original-Received: from cloud103.planethippo.com ([31.216.48.48]:33797) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bEycY-0003Zl-13 for 23785@debbugs.gnu.org; Mon, 20 Jun 2016 08:48:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=russet.org.uk; s=default; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From; bh=2lpJY7BkuhMRZOAzPC1bULjuUZEgo1R24fX0pBd/7ng=; b=bi4du3ZciAwlAM1F/kclh83caY qy+3VYpE9Ataww1tY/zpX3mPqTvUdoYEaSGeCo+3rxBVvKy04RM0QATmOYIbrsJyqZt63G/+VGhom gDuMu3j+jZD5C166EwDcM1C7O2m4AxmOz1aHMHPEp0E6QkB5ETWTYK7cpZwBxwUvSJ1/W1JtC4Lnb iAxXVFgssoRCkKgmtU9xNpBoPRdINWbPW/+2IH0dvyn09W6SW8PeQyBPt2U9QOHTp9vCAtH5dFDnE 8b+BEqElF/6Xa21S3IVUbltTtcNOUvgM4FCFRgoFbAkvcMEo2EDAagzBOl6/7/G5eJ7PgcWLfMHQf eoNrTHvA==; Original-Received: from janus-nat-128-240-225-83.ncl.ac.uk ([128.240.225.83]:32800 helo=russet.org.uk) by cloud103.planethippo.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1bEycS-002w0d-5k; Mon, 20 Jun 2016 13:48:00 +0100 In-Reply-To: (Stefan Monnier's message of "Sun, 19 Jun 2016 20:59:33 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.94 (gnu/linux) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cloud103.planethippo.com X-AntiAbuse: Original Domain - debbugs.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - russet.org.uk X-Get-Message-Sender-Via: cloud103.planethippo.com: authenticated_id: phillip.lord@russet.org.uk X-Authenticated-Sender: cloud103.planethippo.com: phillip.lord@russet.org.uk 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:119824 Archived-At: Stefan Monnier writes: >> The other fiddles with insert-file-contents and adds an undo. It is this >> function that has specialized handling for the undo list that is causing >> the problem. My patch in this case is questionable in that I have randomly >> pushed a call to undo-boundary near the end. It should probably be >> somewere better. > > Indeed, the problem is not that insert-file-contents fails to add > a boundary, but rather that it removes an existing one, so we should > figure out where/why it removes it and change the code to push one back > after removing it. I don't understand why you say this. AFAICT, the problem is that the buffer-undo-list doesn't have a nil after the command has happened. >> Another possibility would be to have insert-file-contents call >> "undo-auto--undoable-change" -- this is the root cause of the problem. > > Figuring out why undo-auto--undoable-change isn't called for it would be > good as well, indeed. After all, it runs after-change-functions, so > it should call undo-auto--undoable-change. I think that it does -- it calls "insert_from_buffer" which then calls "prepare_to_modify_buffer". I *think* what is happening is that prepare_to_modify_buffer is being called when buffer-undo-list is specbound to t -- hence the change does not register as undoable change. I am somewhat guessing here. Phil