From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#9679: 24.0.90; After rgrep, next-error goes to the wrong line Date: Sat, 08 Oct 2011 19:30:12 +0300 Organization: JURTA Message-ID: <87wrcf78dq.fsf@mail.jurta.org> References: <8739f6w35v.fsf@mail.jurta.org> <87r52o7rqj.fsf@mail.jurta.org> <874nzk68av.fsf@mail.jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1318092020 13542 80.91.229.12 (8 Oct 2011 16:40:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 8 Oct 2011 16:40:20 +0000 (UTC) Cc: 9679@debbugs.gnu.org To: Ari Roponen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 08 18:40:16 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RCZwc-00011f-0s for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Oct 2011 18:40:14 +0200 Original-Received: from localhost ([::1]:60214 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RCZwb-0006aV-Bb for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Oct 2011 12:40:13 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:41252) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RCZwR-0006VW-LE for bug-gnu-emacs@gnu.org; Sat, 08 Oct 2011 12:40:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RCZwQ-0000RP-Bp for bug-gnu-emacs@gnu.org; Sat, 08 Oct 2011 12:40:03 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46438) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RCZwQ-0000RK-AC for bug-gnu-emacs@gnu.org; Sat, 08 Oct 2011 12:40:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RCZwP-0003dg-T1 for bug-gnu-emacs@gnu.org; Sat, 08 Oct 2011 12:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 Oct 2011 16:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9679 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 9679-submit@debbugs.gnu.org id=B9679.131809196313939 (code B ref 9679); Sat, 08 Oct 2011 16:40:01 +0000 Original-Received: (at 9679) by debbugs.gnu.org; 8 Oct 2011 16:39:23 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RCZvm-0003cm-Qg for submit@debbugs.gnu.org; Sat, 08 Oct 2011 12:39:23 -0400 Original-Received: from smarty.dreamhost.com ([208.113.175.8]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RCZvj-0003cd-PT for 9679@debbugs.gnu.org; Sat, 08 Oct 2011 12:39:21 -0400 Original-Received: from ps18281.dreamhostps.com (ps18281.dreamhost.com [69.163.218.105]) by smarty.dreamhost.com (Postfix) with ESMTP id 181FA6E809E; Sat, 8 Oct 2011 09:39:18 -0700 (PDT) Original-Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id A2FC8451C4A1; Sat, 8 Oct 2011 09:39:13 -0700 (PDT) In-Reply-To: (Ari Roponen's message of "Fri, 07 Oct 2011 20:48:41 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (x86_64-pc-linux-gnu) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 08 Oct 2011 12:40:01 -0400 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:52426 Archived-At: >> mode: grep-mode, buffer: # >> col: 13, screen nil >> col: 7, screen nil >> col: 13, screen nil >> col: 7, screen nil >> mode: grep-mode, buffer: # > > Grep finished (matches found) > mode: grep-mode, buffer: # > col: 13, screen nil > col: 7, screen nil > col: 13, screen t > col: 7, screen t > mode: grep-mode, buffer: # Thanks, I can now reproduce this bug. Its occurrence depends on the frame's size. When frame's dimensions are 80x43 with 43 lines or more, so the first grep hit is visible in the *grep* buffer, then font-lock kicks in, calculates absolute column positions, after that `compilation-next-error-function' calculates relative column positions with markers for BOTH grep hits, where the final position of the second grep hit is correct. But when frame's dimensions are 80x42 with 42 lines or less, so the first grep hit is not visible in the *grep* buffer, then fontification doesn't start, and when you call `next-error', `compilation-next-error-function' calculates column positions with markers only for the FIRST grep hit, because the second grep hit is not fontified yet in the *grep* buffer. The second grep hit gets processes later with `jit-lock-fontify-now' that calls `compilation-internal-error-properties' and uses `compilation-move-to-column' to calculate columns. The problem is that `compilation-internal-error-properties' calculates column marker positions differently than `compilation-next-error-function'. Its markers have wrong positions as a result. `compilation-next-error-function' is always called in the *grep* buffer where it gets the buffer-local value of `compilation-error-screen-columns' and keeps its value locally. After that it visits the source buffer and correctly calculates column positions using `compilation-move-to-column'. `compilation-internal-error-properties' tries to do the same, but uses a different algorithm. It gets the global value of `compilation-error-screen-columns' instead of buffer-local from the *grep* buffer. Another difference that contributes to the wrong position is using: (beginning-of-line (if end-line (- line end-line -1) (- loc marker-line -1))) Contrary to this, `compilation-next-error-function' doesn't call `beginning-of-line' after `compilation-move-to-column' moves to the correct column. Unfortunately, I can't fix this, because I don't understand why there are two implementations of column position calculations.