From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Barry OReilly Newsgroups: gmane.emacs.bugs Subject: bug#16411: undo-only bugs Date: Wed, 14 May 2014 23:51:05 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c32246e2f4fe04f9683492 X-Trace: ger.gmane.org 1400125950 19923 80.91.229.3 (15 May 2014 03:52:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 May 2014 03:52:30 +0000 (UTC) Cc: 16411 <16411@debbugs.gnu.org> To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 15 05:52:21 2014 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 1WkmiQ-0003mY-45 for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 May 2014 05:52:18 +0200 Original-Received: from localhost ([::1]:55517 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkmiP-0006BM-PP for geb-bug-gnu-emacs@m.gmane.org; Wed, 14 May 2014 23:52:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49080) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkmiH-0006B0-0n for bug-gnu-emacs@gnu.org; Wed, 14 May 2014 23:52:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WkmiA-0005ID-SL for bug-gnu-emacs@gnu.org; Wed, 14 May 2014 23:52:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42028) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkmiA-0005I1-OQ for bug-gnu-emacs@gnu.org; Wed, 14 May 2014 23:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WkmiA-0001lW-1z for bug-gnu-emacs@gnu.org; Wed, 14 May 2014 23:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Barry OReilly Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 May 2014 03:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16411 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16411-submit@debbugs.gnu.org id=B16411.14001258756701 (code B ref 16411); Thu, 15 May 2014 03:52:02 +0000 Original-Received: (at 16411) by debbugs.gnu.org; 15 May 2014 03:51:15 +0000 Original-Received: from localhost ([127.0.0.1]:35092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WkmhO-0001k1-8C for submit@debbugs.gnu.org; Wed, 14 May 2014 23:51:14 -0400 Original-Received: from mail-ob0-f171.google.com ([209.85.214.171]:33564) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WkmhM-0001ji-0r for 16411@debbugs.gnu.org; Wed, 14 May 2014 23:51:12 -0400 Original-Received: by mail-ob0-f171.google.com with SMTP id wn1so572111obc.16 for <16411@debbugs.gnu.org>; Wed, 14 May 2014 20:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gZ9DmMc59at8puok66dZjZxhVCyC69tX6z0GpiEET4U=; b=vfCvF4j49ST9h2Aj7EPo2Nk9S+IrxKgNp40m74KShegEFMQZDII6otAr24aPPaSsM8 9JdRM0zS9TtB5NJo9Lh4vtBEe+aoD1yYJ/aMRrcQwP122/yA25wti4mQUSZQKUry8/6O Id5kKhepRQT+hl6YwGI8NC5AD8prYfG5tQ/V5+hHwId6wFelg6W8qHtaqgVF1gNFHYnu O7kR/U68MhHmnJuYse87p5tqfTQRT5muHqJVMh37MKglKhdYNmjO4D5kZPVjlH4yHqik ch81PbirQR9PKUMc+LHQQiCGikZVbjEnDxY1gBDOePiG6DJQylTG/JehXRqOa/Gy5PPb lPMA== X-Received: by 10.182.246.40 with SMTP id xt8mr60942obc.76.1400125866045; Wed, 14 May 2014 20:51:06 -0700 (PDT) Original-Received: by 10.76.6.44 with HTTP; Wed, 14 May 2014 20:51:05 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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:89119 Archived-At: --001a11c32246e2f4fe04f9683492 Content-Type: text/plain; charset=UTF-8 > I've never heard anyone bump into this "Y undo-redos of X" problem, > so I don't think optimizing it is worth the trouble. Happens to me all the time. > If anything should be done with it, I think it'd be to *cut* the > extra undo/redo pairs. No complaint from me. That would change the behavior of ordinary undo command, which you just said you don't want to change. > I'm not completely convinced that this generator is worthwhile Ok, I'll lose it then. >> I originally set out to do this, but making the weak references >> work seemed overly tricky to me. The value stored in >> undo-redo-table would need to be non weak with weak references to >> undo elements. I supposed this would mean many one element weak >> hash tables. That seems dodgy. > Hmm... that's a very good point. Worth mentioning in a comment. You actually want me to do that? That is: wrap every referenced element in a size 1 weak hash table. Are you sure that gives the memory savings over the element level mapping of the undo-redo-table in the patch? --001a11c32246e2f4fe04f9683492 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> I've never heard anyone bump into this "Y un= do-redos of X" problem,
> so I don't think optimizing it is = worth the trouble.

Happens to me all the time.

> If anythi= ng should be done with it, I think it'd be to *cut* the
> extra undo/redo pairs.

No complaint from me. That would change = the behavior of ordinary undo
command, which you just said you don't= want to change.

> I'm not completely convinced that this gen= erator is worthwhile

Ok, I'll lose it then.

>> I originally set out to do t= his, but making the weak references
>> work seemed overly tricky t= o me. The value stored in
>> undo-redo-table would need to be non = weak with weak references to
>> undo elements. I supposed this would mean many one element weak>> hash tables. That seems dodgy.

> Hmm... that's a ve= ry good point. Worth mentioning in a comment.

You actually want me t= o do that? That is: wrap every referenced
element in a size 1 weak hash table. Are you sure that gives the
memory = savings over the element level mapping of the undo-redo-table
in the pat= ch?

--001a11c32246e2f4fe04f9683492--