From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: Re: frames vs. weak hash tables and garbage collection Date: Sat, 29 Sep 2007 14:28:16 -0400 Message-ID: References: <86wsvdvmkb.fsf@macs.hw.ac.uk> <86y7fru45n.fsf@macs.hw.ac.uk> <868x6u1g8x.fsf@macs.hw.ac.uk> <874phgo5l2.fsf@ambire.localdomain> <86k5qazvm4.fsf@macs.hw.ac.uk> <867im9xx2f.fsf@macs.hw.ac.uk> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1191090518 27996 80.91.229.12 (29 Sep 2007 18:28:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 29 Sep 2007 18:28:38 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org, rms@gnu.org To: Joe Wells Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 29 20:28:33 2007 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 1Ibh3I-0006HA-6b for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Sep 2007 20:28:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ibh3E-00081x-Gh for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Sep 2007 14:28:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ibh3C-0007yU-0l for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2007 14:28:26 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ibh3B-0007x3-AL for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2007 14:28:25 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ibh3B-0007ws-1l for bug-gnu-emacs@gnu.org; Sat, 29 Sep 2007 14:28:25 -0400 Original-Received: from tomts20.bellnexxia.net ([209.226.175.74] helo=tomts20-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ibh36-000106-3x; Sat, 29 Sep 2007 14:28:20 -0400 Original-Received: from ceviche.home ([74.12.205.67]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20070929182817.WXBW8273.tomts20-srv.bellnexxia.net@ceviche.home>; Sat, 29 Sep 2007 14:28:17 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 04D5DB40D6; Sat, 29 Sep 2007 14:28:16 -0400 (EDT) In-Reply-To: <867im9xx2f.fsf@macs.hw.ac.uk> (Joe Wells's message of "Sat\, 29 Sep 2007 17\:20\:40 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (gnu/linux) X-Detected-Kernel: Solaris 8 (1) 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:16662 Archived-At: >> But it seems that `values' is never flushed, so it is a source of leaks. >> We should probably fix it (I'd remove it since almost noone even knows t= hat >> it exists, but I guess Richard uses it once in a blue moon). >>=20 >> I don't use it myself. I put it in because a history of values >> is a useful thing for any read-eval-print loop. We could delete it, >> but it might be better to do more to inform people about it. >> For instance, mention it in the text in the *scratch* buffer. >>=20 >> Then they might indeed find it useful. Or if they don't, >> we could delete it. >>=20 >> I agree with the suggestion to truncate it to a specified maximum >> length. How about 40? > Personally, I can't remember using anything more than (car values). > Maybe once I used something older than the most recent addition to the > list. > So it seems to me a length of 3 would probably be plenty. > By the way, the name =E2=80=9Cvalues=E2=80=9D is not good. I would sugge= st > =E2=80=9Ceval-expression-recent-values=E2=80=9D. ielm implements its own mechanism for it and it calls it "*", "**", and "***", giving access only to the last 3 values. I do use these occasionally (contrary to `values' which I've never used). So I guess 3 is plenty indeed. In many circumstances where I could use this kind of feature I prefer using (setq sm-tmp ) and then refer to that value as `sm-tmp' this way I can reuse this value many times easily (whereas with `values' I'd have to keep track of the position within the list etc...). Stefan