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#15841: Display bugs with cache-long-lines non-nil Date: Tue, 12 Nov 2013 18:31:32 +0200 Message-ID: <83txfh1t0b.fsf@gnu.org> References: <871u2xf9st.fsf@gmail.com> <9jiow9uhoa.fsf@fencepost.gnu.org> <87wqkopylw.fsf@gmail.com> <87bo20fh3h.fsf@web.de> <834n7q95d5.fsf@gnu.org> <87r4aqww3j.fsf@nbtrap.com> <83r4aq3s4r.fsf@gnu.org> <87fvr3ni2o.fsf@rosalinde.fritz.box> <877gceo3n9.fsf@rosalinde.fritz.box> <87mwla6inw.fsf@rosalinde.fritz.box> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1384273999 3997 80.91.229.3 (12 Nov 2013 16:33:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Nov 2013 16:33:19 +0000 (UTC) Cc: 15841@debbugs.gnu.org To: Stephen Berman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 12 17:33:23 2013 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 1VgGu2-0006pX-8z for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Nov 2013 17:33:22 +0100 Original-Received: from localhost ([::1]:43817 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgGu1-0004Uh-PY for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Nov 2013 11:33:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58122) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgGtp-0004TG-RH for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2013 11:33:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VgGtj-00076J-4v for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2013 11:33:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34979) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgGtj-000766-0a for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2013 11:33:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VgGti-0006Zz-9D for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2013 11:33:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Nov 2013 16:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15841-submit@debbugs.gnu.org id=B15841.138427394625226 (code B ref 15841); Tue, 12 Nov 2013 16:33:02 +0000 Original-Received: (at 15841) by debbugs.gnu.org; 12 Nov 2013 16:32:26 +0000 Original-Received: from localhost ([127.0.0.1]:48994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VgGt6-0006Yl-1e for submit@debbugs.gnu.org; Tue, 12 Nov 2013 11:32:25 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:39424) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VgGt3-0006YV-B1 for 15841@debbugs.gnu.org; Tue, 12 Nov 2013 11:32:22 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MW500J00SIK5B00@a-mtaout22.012.net.il> for 15841@debbugs.gnu.org; Tue, 12 Nov 2013 18:31:35 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MW500IKTSKNSFC0@a-mtaout22.012.net.il>; Tue, 12 Nov 2013 18:31:35 +0200 (IST) In-reply-to: <87mwla6inw.fsf@rosalinde.fritz.box> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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:80329 Archived-At: > From: Stephen Berman > Cc: 15841@debbugs.gnu.org > Date: Tue, 12 Nov 2013 11:03:47 +0100 > > > I tracked the problematic fontification and motion behavior to > > insert-directory in files.el: it happens during the loop when > > decode-coding-region is called on the file names of the subdirectory > > entries. I stepped through the code with Edebug but could not tell why > > it goes wrong here, and I'm too tired to pursue it further now. Also, > > when I step through this code, the "available" information is added at > > the end of the entire subdirectory listing, unlike what I observed above > > when just invoking `i' and then `C-g'. I guess this is due to the > > interaction of redisplay with stepping through the code; it's still > > clear that the subdirectory listing is being treated as part of the line > > containing the `..' entry. > > I set a breakpoint on decode_coding_object and stepped through it after > invoking `i', but the Dired display changed to show the problematic > fontification only upon exiting decode_coding_object. I don't know how > to find out when cache_long_scans is checked other than manually tracing > the call chains of each subroutine of decode_coding_object, which is too > laborious. There's no need: I already established that, as you point out, the changes to the buffer that cause the problem are indeed made by decode-coding-region. The problem becomes visible when redisplay, entered after decode-coding-region finishes its job, re-fontifies portions of the buffer that were affected by the changes. The way this affects redisplay is through forward-line and line-beginning-position, of which JIT Font Lock is a heavy user. That's why you only see the effect after decode-coding-region returns. > Is it possible to have execution halt when cache_long_scans is > checked, and if so, how? Watchpoints are the answer. But in this case, there's only one place in the whole Emacs where this variable is consulted: in search.c, around line 610, so you could just put a breakpoint there. In any case, I already traced through the code that is involved, and the immediate reason for the assertion violation is that the cache isn't being updated wrt changes in buffer size (which are caused by decoding the stuff brought in by 'ls'). However, a naive attempt to force such updates didn't solve the whole problem: the aborts are gone, but the infloop is still there, and also other minor display issues. So I guess there's another factor at work there... I also need to figure out how to keep the cache up to date without penalizing performance, which would render the cache worthless. > Or is there a better way to try to track down this bug? The cache has only 3 public interfaces (see region-cache.c), so it is easy to put breakpoints in all of them and see what happens. That's what I did. Thanks.