unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@jurta.org>
To: Ari Roponen <ari.roponen@gmail.com>
Cc: 9679@debbugs.gnu.org
Subject: bug#9679: 24.0.90; After rgrep, next-error goes to the wrong line
Date: Sat, 08 Oct 2011 19:30:12 +0300	[thread overview]
Message-ID: <87wrcf78dq.fsf@mail.jurta.org> (raw)
In-Reply-To: <m3pqi8r8ue.fsf@gmail.com> (Ari Roponen's message of "Fri, 07 Oct 2011 20:48:41 +0300")

>> mode: grep-mode, buffer: #<buffer *grep*>
>> col: 13, screen nil
>> col: 7, screen nil
>> col: 13, screen nil
>> col: 7, screen nil
>> mode: grep-mode, buffer: #<buffer *grep*>
>
> Grep finished (matches found)
> mode: grep-mode, buffer: #<buffer *grep*>
> col: 13, screen nil
> col: 7, screen nil
> col: 13, screen t
> col: 7, screen t
> mode: grep-mode, buffer: #<buffer *grep*>

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.





  reply	other threads:[~2011-10-08 16:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87r4uwybeh.fsf@gnu.org>
2011-10-06  6:14 ` bug#9679: 24.0.90; After rgrep, next-error goes to the wrong line Ari Roponen
2011-10-06 15:27   ` Juri Linkov
2011-10-07  5:15     ` Ari Roponen
2011-10-07  8:41       ` Ari Roponen
2011-10-07 15:20       ` Juri Linkov
2011-10-07 15:51         ` Ari Roponen
2011-10-07 16:36           ` Juri Linkov
2011-10-07 17:48             ` Ari Roponen
2011-10-08 16:30               ` Juri Linkov [this message]
2011-10-09  5:38                 ` Ari Roponen
2012-05-06  6:23                   ` Ari Roponen
     [not found]   ` <handler.9679.C.13363577086087.notifdonectrl.0@debbugs.gnu.org>
2012-05-13  6:39     ` bug#9679: acknowledged by developer (close 9679) Ari Roponen
2012-05-13  9:18       ` Chong Yidong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wrcf78dq.fsf@mail.jurta.org \
    --to=juri@jurta.org \
    --cc=9679@debbugs.gnu.org \
    --cc=ari.roponen@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).