From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Change in files.el Date: Sat, 28 Jan 2017 19:11:12 +0200 Message-ID: <83ziibxg7j.fsf@gnu.org> References: <83mvebzh0k.fsf@gnu.org> <83bmurz0y9.fsf@gnu.org> <8360kzyxor.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1485623537 20701 195.159.176.226 (28 Jan 2017 17:12:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 28 Jan 2017 17:12:17 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 28 18:12:12 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cXWXf-00044v-Vl for ged-emacs-devel@m.gmane.org; Sat, 28 Jan 2017 18:12:00 +0100 Original-Received: from localhost ([::1]:52619 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cXWXl-0006f5-8p for ged-emacs-devel@m.gmane.org; Sat, 28 Jan 2017 12:12:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47398) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cXWXC-0006ez-0I for emacs-devel@gnu.org; Sat, 28 Jan 2017 12:11:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cXWX7-0007RA-Er for emacs-devel@gnu.org; Sat, 28 Jan 2017 12:11:29 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38708) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cXWX7-0007R3-BJ; Sat, 28 Jan 2017 12:11:25 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2137 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cXWX6-0003bg-3J; Sat, 28 Jan 2017 12:11:25 -0500 In-reply-to: (message from Stefan Monnier on Sat, 28 Jan 2017 11:51:07 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:211703 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Sat, 28 Jan 2017 11:51:07 -0500 > > >> > These sound minor to me (and the last two are also possible without > >> > the requirement, AFAIU). > >> Hmm... how do you get the last two without that requirement? > > Are we still talking about a predicate, i.e. a function that returns > > either t or nil? If so, I think the last two are so trivial that I > > don't know where to begin answering your question. > > I don't see what the form of the return value changes to the problem. The default behavior is just the value t or nil, so reproducing the default behavior is trivial. E.g., in the case in point the default behavior is to always ask the user about every buffer, i.e. the default implementation simply always returns t. > Regarding "More generally, so that you can slightly change its > behavior without having to re-implement the default behavior by hand": > - what code would you write which preserves the behavior except that it > logs all calls to some global variable? > - what code would you write which preserves the behavior except that it > returns nil for one specific buffer? Here, everything you write in a non-default implementation belongs to the new functionality; the original functionality is a constant value returned unconditionally, and it's trivial to write. > Regarding "Also, so as to make sure that it is *possible* to reimplement > the default behavior by hand": in my experience trying to change > *-function to default to a non-nil value, it often happens that the > preexisting default behavior *cannot* be implemented faithfully (or > without a lot of extra gymnastic) because it relies on some local > variable which is not passed as argument to the predicate. Once again, the default behavior of a predicate is just t or nil, so I don't think I understand what you ware talking about here. > I see what you mean. Yes, the default behavior ends up moved into its > own function. I'm surprised you feel so strongly about it, tho, because > it never caused me such trouble. > > When debugging a specific execution, I'm usually doing it with Edebug, Tye need to use a debugger instead of just reading the code is already a huge annoyance, which tremendously slows down problem-solving, due to the need to arrange for some reproduction recipe, and then step through the code. > And when just reading the code without any specific execution in > mind, I typically don't look at the value of > save-some-buffers-default-predicate at all since the code should > work correctly regardless of that value Debugging a problem does not necessarily need to consider all possible values, it typically considers only one -- the one that causes the problem you are debugging. So it matters a lot whether you can understand what happens with that specific value, and indeed what _is_ that value, when the problem hits. In a vast majority of cases, you only have the final result in the user report: an error message or some incorrect output, and need to work your way back from that to the conditions and the logic which failed. Each indirection is one more obstacle in this analysis, and given enough of them the analysis becomes practically impossible (unless you are already well familiar with the code in question).