From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Richard M. Stallman" Newsgroups: gmane.emacs.bugs,gmane.emacs.pretest.bugs Subject: bug#861: Strange interaction of cursor movement and post-command-hook? Date: Mon, 01 Sep 2008 21:09:02 -0400 Message-ID: References: Reply-To: rms@gnu.org, 861@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1220318868 20678 80.91.229.12 (2 Sep 2008 01:27:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 2 Sep 2008 01:27:48 +0000 (UTC) Cc: emacs-pretest-bug@gnu.org To: David Kastrup Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 02 03:28:43 2008 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KaKhG-0003om-2u for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Sep 2008 03:28:42 +0200 Original-Received: from localhost ([127.0.0.1]:46984 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KaKgG-00050A-VQ for geb-bug-gnu-emacs@m.gmane.org; Mon, 01 Sep 2008 21:27:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KaKgB-0004zP-ML for bug-gnu-emacs@gnu.org; Mon, 01 Sep 2008 21:27:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KaKgA-0004z5-Mz for bug-gnu-emacs@gnu.org; Mon, 01 Sep 2008 21:27:34 -0400 Original-Received: from [199.232.76.173] (port=47211 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KaKgA-0004z0-Dw for bug-gnu-emacs@gnu.org; Mon, 01 Sep 2008 21:27:34 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:53579) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KaKgA-0004Io-4K for bug-gnu-emacs@gnu.org; Mon, 01 Sep 2008 21:27:34 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KaKg9-00021O-5k for bug-gnu-emacs@gnu.org; Mon, 01 Sep 2008 21:27:33 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m821RUQq007095; Mon, 1 Sep 2008 18:27:31 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m821K4Ga004178; Mon, 1 Sep 2008 18:20:04 -0700 X-Loop: don@donarmstrong.com Resent-From: "Richard M. Stallman" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Tue, 02 Sep 2008 01:20:04 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 861 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by submit@emacsbugs.donarmstrong.com id=B.12203178421903 (code B ref -1); Tue, 02 Sep 2008 01:20:04 +0000 Original-Received: (at submit) by emacsbugs.donarmstrong.com; 2 Sep 2008 01:10:42 +0000 Original-Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m821Ac0p001896 for ; Mon, 1 Sep 2008 18:10:40 -0700 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1KaKOE-0004YV-2B; Mon, 01 Sep 2008 21:09:02 -0400 In-reply-to: (message from David Kastrup on 04 Jan 2003 22:02:56 +0100) X-detected-kernel: by mx20.gnu.org: Linux 2.6 (newer, 3) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) Resent-Date: Mon, 01 Sep 2008 21:27:34 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:20001 gmane.emacs.pretest.bugs:22930 Archived-At: Internally, the two strings share most of their state. The total amount of memory used is (roughly speaking) the memory for saved_undo_point plus the memory for just the string "foobar". That is what I figured. What I am worried about is the "roughly". There can be a lot of undo data, which is why there are special features to control how much is saved. So the efficiency of storing it is very important. Note also that undo data covers more than just buffer contents. (In reality, it's a little bit fancier than what is described above in order to put an upper bound on the amount of fragmentation of strings in memory.) Those measures, which are clearly necessary, could impact the efficiency of storing hundreds of past snapshots. This might cause the amount of duplicated buffer text to increase, even drastically. Or it might not. Making this change to the buffer representation would not _require_ changing the undo data structure and mechanism. That one area of the C code is fairly modular and independent of buffer internals. It might hardly need any change. Other areas could take more work.