From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Date: Thu, 20 Sep 2012 13:59:06 -0700 Message-ID: <9858A6718B624C2798943F59CEDFB74E@us.oracle.com> References: <87haz0po82.fsf@web.de> <4F3BE4CB.3030909@gmx.at> <4F3CB843.6030401@gmx.at> <4F3D41DD.6080603@gmx.at> <877gzmqwcf.fsf@web.de> <504B4940.9000809@gmx.at> <86wqzznwzv.fsf@web.de> <9BABA419184241F5A7246DC5D9A9EF81@us.oracle.com> <5057A4A3.4010100@gmx.at> <4617F483F2CC446D980DF7194E06BB3A@us.oracle.com> <50581E7F.3040108@gmx.at> <1C1E224E1D674670BEE043B4A35A271F@us.oracle.com> <5059FC9C.8020702@gmx.at> <2D8C133406A54B26AD253EC7EE52C666@us.oracle.com> <505B1F26.20209@gmx.at> <87ehlwzklr.fsf@web.de> <505B51AD.2080908@gmx.at> <91FFA03F2A7341A09E280DD2BCC4A428@us.oracle.com> <83392czgvc.fsf@gnu.org> <8123443E3625415F89A2118ECE393E72@us.oracle.com> <83zk4kxw9o.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1348174777 19672 80.91.229.3 (20 Sep 2012 20:59:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Sep 2012 20:59:37 +0000 (UTC) Cc: michael_heerdegen@web.de, 8789@debbugs.gnu.org To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 20 22:59:41 2012 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 1TEnqV-00058G-Cc for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Sep 2012 22:59:39 +0200 Original-Received: from localhost ([::1]:37347 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEnqQ-0003l6-Qi for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Sep 2012 16:59:34 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43495) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEnqN-0003kJ-37 for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 16:59:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEnqL-0004gW-UZ for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 16:59:31 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36135) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEnqL-0004gS-Qr for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 16:59:29 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TEnrq-0003pe-Bb for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 17:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 21:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8789 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8789-submit@debbugs.gnu.org id=B8789.134817484714706 (code B ref 8789); Thu, 20 Sep 2012 21:01:02 +0000 Original-Received: (at 8789) by debbugs.gnu.org; 20 Sep 2012 21:00:47 +0000 Original-Received: from localhost ([127.0.0.1]:45681 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEnra-0003p8-Hl for submit@debbugs.gnu.org; Thu, 20 Sep 2012 17:00:47 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:43013) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEnrY-0003p1-1M for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 17:00:45 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q8KKx8Li001669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Sep 2012 20:59:09 GMT Original-Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q8KKx7n2021658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Sep 2012 20:59:08 GMT Original-Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q8KKx7Ct032461; Thu, 20 Sep 2012 15:59:07 -0500 Original-Received: from dradamslap1 (/130.35.178.248) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Sep 2012 13:59:07 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83zk4kxw9o.fsf@gnu.org> Thread-Index: Ac2XcD4+2KkQ4gnvTSazDMS7vYFPaAAAICWg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:64659 Archived-At: > One such solution already exists: set inhibit-eval-during-redisplay to > a non-nil value (it will inhibit _all_ calls to Lisp by all display > features, though). I'm not sure how visible is that feature. Perhaps > we need to advertise it more. More than what? ;-) I never heard of it. And it does not appear to be documented in the Elisp manual. But how about an option that does that only for eval when the debugger is active? IOW, that sounds like something that is a broader brush than what is needed here. > This is a potential problem with any code, C or Lisp, that runs during > each redisplay cycle. On the C level, the only sane way of dealing > with this is to use conditional breakpoints with cleverly designed > conditions that cause the breakpoints break only when the function > being debugged is called in the right context, bypassing the myriads > of irrelevant calls. > > > I would say that it is indeed unfortunate if we are now > > calling `file-remote-p' as part of displaying the mode line. > > Surely, there's nothing special in 'file-remote-p', except the fact > that you needed to debug it in this case. No, of course there is nothing special about it. The point is that it is a commonly called function, and now it is also called to display the mode line. That is a powder-keg combination. That is the problem. It is asking for trouble to call such a function as part of the mode-line display. > Any code that is eval'ed as > part of displaying the mode line, or redisplay in general, will be > susceptible to similar problems. Precisely. > A solution specific to a single function won't do, would it? It would do for this particular bug. ;-) But yes, the same principle and potential problem applies to all functions called during display of the mode line (or other redisplay stuff). > > > > This is a regression, and should just be fixed. > > > > > > How do you "fix" situation where a function you want to debug is > > > called at a very high frequency? > > > > It should not be called for mode-line display. IMHO. That > > was a misguided enhancement. > > I disagree. That indication is important when you work with remote > files a lot. No one said it was not useful. In fact, I explicitly said it was. > And again, this particular function is not the issue; > the issue is more general. Yes and no. Agreed that there is a general problem. But let's not let the perfect become the enemy of the good. This particular regression was introduced because `file-remote-p' is now called to update the mode line. Take care of that bug and you take care of that bug ;-), which is already a good thing. > > Perhaps the debugger could do that automatically. > > Not unconditionally, because it is perfectly valid to debug code that > runs off redisplay. Agreed. That's why I mentioned doing so optionally (and probably by default, to lessen surprise). > > Whether it should or not, and whether that should be a user option, > > I also don't know. But we should not expect users to dig in and > > discover this stuff and work around it on an individual basis. > > Even if we have an option (please see if inhibit-eval-during-redisplay > suits your needs), using it already requires to know or suspect that > calls from redisplay are the reason for "strange" behavior during > debugging. So I'm not sure I see how any such option will solve the > problem of discoverability; again, ideas welcome. Make it not only optional, but the default behavior for the debugger. No, I do not mean `inhibit-eval-during-redisplay', which paints with a broader brush. I mean an option to have the debugger skip over/through calls involving redisplay. But you ignored the simple solution I proposed: just make the mode-line code call a separate function from `file-remote-p'. That function can do the same thing, and it could even have exactly the same definition. But it would be called out as being something that is intended to be called only by the mode-line code. IOW, try to keep this separate and make that intention explicit. It seems to me that that would go a long way - maybe all the way - to preventing typical debugging from falling down the hole that this discussion is about.