From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#8789: 23.3; debug backtrace buffer changes window on step-through Date: Thu, 20 Sep 2012 23:41:07 +0300 Message-ID: <83zk4kxw9o.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1348173700 10849 80.91.229.3 (20 Sep 2012 20:41:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Sep 2012 20:41:40 +0000 (UTC) Cc: michael_heerdegen@web.de, 8789@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 20 22:41:42 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 1TEnZ5-0008AY-Kh for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Sep 2012 22:41:39 +0200 Original-Received: from localhost ([::1]:53548 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEnZ1-0001xi-9h for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Sep 2012 16:41:35 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:34952) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEnYy-0001ve-A9 for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 16:41:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEnYw-0006xH-CG for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 16:41:32 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36121) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEnYw-0006x3-9H for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 16:41:30 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TEnaQ-0003QT-KB for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 16:43:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 20:43: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.134817375313130 (code B ref 8789); Thu, 20 Sep 2012 20:43:02 +0000 Original-Received: (at 8789) by debbugs.gnu.org; 20 Sep 2012 20:42:33 +0000 Original-Received: from localhost ([127.0.0.1]:45667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEnZw-0003Pj-Dt for submit@debbugs.gnu.org; Thu, 20 Sep 2012 16:42:32 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:41571) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEnZs-0003PY-AR for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 16:42:30 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MAO008001CRF900@a-mtaout22.012.net.il> for 8789@debbugs.gnu.org; Thu, 20 Sep 2012 23:40:53 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MAO008HM1G4AA30@a-mtaout22.012.net.il>; Thu, 20 Sep 2012 23:40:53 +0300 (IDT) In-reply-to: <8123443E3625415F89A2118ECE393E72@us.oracle.com> X-012-Sender: halo1@inter.net.il 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:64657 Archived-At: > From: "Drew Adams" > Cc: , , <8789@debbugs.gnu.org> > Date: Thu, 20 Sep 2012 11:49:43 -0700 > > > > > So the solution is probably to never enable `debug-on-entry' for > > > > functions that run through the mode-line mechanism. > > > > > > That does not sound like the solution to me. > > > > Please suggest another solution, then, for a function that is > > constantly called as part of redisplay (which is what happens here, > > see below). AFAIU, this is why you "cannot exit the debugger": > > anything that you do redisplays the mode line, and re-enters the > > debugger. > > Gee, Eli, I don't know what the solution is. Except maybe to revert the change > that caused the regression. > > Or maybe the debugger should skip over such mode-line refreshing? I really > don't know, sorry. Well, ideas are certainly welcome. It's a hard problem, given the potentially conflicting goals. I don't think removing the feature will be welcome. 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. > I do know that there is all kinds of code, including user code, that calls > `file-remote-p' - if nothing else, to avoid tramp digging in its heels and > trying to access remote machines. If we cannot debug such code without first > manually fiddling with the mode-line spec, then that's a sorry situation, IMHO. 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. Any code that is eval'ed as part of displaying the mode line, or redisplay in general, will be susceptible to similar problems. A solution specific to a single function won't do, would it? > > > 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. And again, this particular function is not the issue; the issue is more general. > > The only way I know if is to stop > > calling it -- which is precisely what was suggested: set > > mode-line-remote to nil, which avoids the invocation of file-remote-p > > as part of mode-line redisplay. > > Not as an individual user - that's just Emacs Dev punting. When you debug, you _are_ a developer. > Perhaps the debugger could do that automatically. Not unconditionally, because it is perfectly valid to debug code that runs off redisplay. > 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.