From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ishikawa Newsgroups: gmane.emacs.devel Subject: Re: A new(?) warning of erase-buffer, which was not seen before. Date: Thu, 22 Mar 2007 20:08:10 +0900 Message-ID: <4602639A.8030606@ubin.jp> References: <45FDF35F.6030605@ubin.jp> <45FF5975.1070602@ubin.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1174561712 3015 80.91.229.12 (22 Mar 2007 11:08:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 22 Mar 2007 11:08:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Kim F. Storm" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 22 12:08:24 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HUL9b-0000Dm-I8 for ged-emacs-devel@m.gmane.org; Thu, 22 Mar 2007 12:08:23 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HULBM-0008PT-6V for ged-emacs-devel@m.gmane.org; Thu, 22 Mar 2007 06:10:12 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HULBI-0008Fq-PJ for emacs-devel@gnu.org; Thu, 22 Mar 2007 07:10:08 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HULBH-0008C0-K0 for emacs-devel@gnu.org; Thu, 22 Mar 2007 07:10:08 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HULBH-0008Bl-EK for emacs-devel@gnu.org; Thu, 22 Mar 2007 06:10:07 -0500 Original-Received: from post.ubin.jp ([202.32.0.84]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HUL9U-0002u1-4t for emacs-devel@gnu.org; Thu, 22 Mar 2007 07:08:16 -0400 Original-Received: from post.ubin.jp (post [127.0.0.1]) by localhost.ubin.jp (Postfix) with ESMTP id 5A65729AC39; Thu, 22 Mar 2007 20:08:11 +0900 (JST) Original-Received: from [10.254.248.233] (dell-w2k-note.ddns.member.ubin.jp [10.254.248.233]) by post.ubin.jp (Postfix) with ESMTP id 06D7829AC38; Thu, 22 Mar 2007 20:08:11 +0900 (JST) User-Agent: Thunderbird 1.5.0.10 (X11/20070221) In-Reply-To: X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:68286 Archived-At: Kim F. Storm wrote: > ishikawa writes: > >> It is only that I am a little puzzled that I didn't get this warning >> in the previous versions 21.x (and prior), and I am wondering >> if there is a better memory allocation/checking introduced in 22.0 >> which causes this warning to appear. In the older versions, say 21.x >> (and prior), I have not seen this message. > > Those warnings are new in Emacs 22. > > In Emacs 21 and before, there is a risk of running out of memory and > Emacs crashing. > > In Emacs 22, more checks and automatic measures like undo-outer-limit > have been added to prevent running out of memory, and to give feedback > to the user when those measures kick in. > > Here's what C-h C-n (aka NEWS) says about it: > > ** When the undo information of the current command gets really large > (beyond the value of `undo-outer-limit'), Emacs discards it and warns > you about it. > Thank you again. After tinkering with new emacs, here is my suggestion for a slight improvement for the particular warning message. AT the end (that is, after "You can disable the popping up of this buffer by adding the entry (undo discard-info) to the user option `warning-suppress-types'."), we might want to add something like the following (as rms suggested): " If you know what you are doing, and you don't want the buffer to collect undo information which uses memory internally, do M-x buffer-disable-undo, or (setq buffer-undo-list t)."