From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.devel Subject: Re: Concern about new binding. Date: Thu, 04 Feb 2021 09:49:15 +0000 Message-ID: References: <20210202134950.vybbpf3iewbymfjo.ref@Ergus> <20210202134950.vybbpf3iewbymfjo@Ergus> <87h7mt3qjo.fsf@melete.silentflame.com> <87im78usd9.fsf@gnus.org> <878s84url8.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5505"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Stallman , emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Feb 04 10:52:40 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l7bJW-0001F8-TN for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Feb 2021 10:52:38 +0100 Original-Received: from localhost ([::1]:60134 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l7bJV-0007CU-Su for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Feb 2021 04:52:37 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48074) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7bGK-0004cm-P4 for emacs-devel@gnu.org; Thu, 04 Feb 2021 04:49:20 -0500 Original-Received: from heytings.org ([95.142.160.155]:36138) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7bGI-0003o1-Up; Thu, 04 Feb 2021 04:49:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1612432156; bh=fvlkQRT8zzzJiQS4rIYzz1k3oKnm8swHJ6XvMyMNC7Y=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=gHWjSZTxDXzohJxXLqjfvXAGopfunbArf51l3P2+5hrd+s42pJOlDlgn7TzA6/nGp nlpbw2dtE8SncPSgeZfIp1E5NNAwrKeiyb20eQ5ADUT032V3bsywsVQL4pwCyRoyVK Gxp0IaPUeCzTae/0WtIaXWUghxyKTJEIFyuG9t72hNJXiyO3T9co9iV41z10gnyIJX qE/ZBWnfAMlfJMdjeHLfQj7dxKlq9B50YkkTWjrvpNPYqURrHmA0321DUaY/WHNQaL 7AT/LGLzBC3zJV3W8KvFcIPcbOen+ydcrD85qF//Up7Hi6LZnVf/tXHMvUvklNJASq 1biNm4Uy2PBNg== In-Reply-To: <878s84url8.fsf@gnus.org> Received-SPF: pass client-ip=95.142.160.155; envelope-from=gregory@heytings.org; helo=heytings.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:263862 Archived-At: >>> It would perhaps make sense to ask for confirmation _before_ executing >>> the command ("The command '...' will discard undo info, really do it? >>> (yes or no)"). >> >> Makes sense to me. > > Or... if it could offer to to keep the undo info, even if it's over the > current general limit, that would be even nicer, perhaps? > I don't have strong feelings about this. Perhaps offering to keep the undo info after the command has been executed would be nicer indeed. But not executing the command before a confirmation is perhaps less risky. It seems to me that if you see such a question before the command is executed, the question will have all your attention, because what you wanted did not happen yet. If you see it after the command is executed, the risk of answering "no" without really thinking about it is higher. On a side note, I don't understand the "At garbage collection time" in the doc string of "undo-outer-limit": Outer limit on size of undo information for one command. At garbage collection time, if the current command has produced more than this much undo information, it discards the info and displays a warning. This is a last-ditch limit to prevent memory overflow. It seems to me that this happens when the command is executed, not "at garbage collection time".