From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ernesto Alfonso Newsgroups: gmane.emacs.bugs Subject: bug#32676: Feature request Date: Tue, 18 Sep 2018 01:51:04 -0700 Message-ID: References: <20180910050802.25922-1-erjoalgo@gmail.com> <83a7ollcq2.fsf@gnu.org> <874let1o3k.fsf@gmail.com> <831s9xl54b.fsf@gnu.org> <874leq1hw4.fsf@mail.linkov.net> <87worlgh0k.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000880ff60576216421" X-Trace: blaine.gmane.org 1537260608 4322 195.159.176.226 (18 Sep 2018 08:50:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 18 Sep 2018 08:50:08 +0000 (UTC) Cc: Robert Pluim , 32676@debbugs.gnu.org To: juri@linkov.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 18 10:50:03 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g2Bhr-0000ya-NF for geb-bug-gnu-emacs@m.gmane.org; Tue, 18 Sep 2018 10:50:03 +0200 Original-Received: from localhost ([::1]:39128 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g2Bjy-0005uO-EE for geb-bug-gnu-emacs@m.gmane.org; Tue, 18 Sep 2018 04:52:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50983) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g2Bjq-0005uJ-Rv for bug-gnu-emacs@gnu.org; Tue, 18 Sep 2018 04:52:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g2Bjl-0004FV-Pz for bug-gnu-emacs@gnu.org; Tue, 18 Sep 2018 04:52:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39365) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g2Bjl-0004FN-Lg for bug-gnu-emacs@gnu.org; Tue, 18 Sep 2018 04:52:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g2Bjl-0000eo-JT for bug-gnu-emacs@gnu.org; Tue, 18 Sep 2018 04:52:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ernesto Alfonso Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 18 Sep 2018 08:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32676 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 32676-submit@debbugs.gnu.org id=B32676.15372606852476 (code B ref 32676); Tue, 18 Sep 2018 08:52:01 +0000 Original-Received: (at 32676) by debbugs.gnu.org; 18 Sep 2018 08:51:25 +0000 Original-Received: from localhost ([127.0.0.1]:43623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g2BjA-0000ds-Ps for submit@debbugs.gnu.org; Tue, 18 Sep 2018 04:51:25 -0400 Original-Received: from mail-wr1-f66.google.com ([209.85.221.66]:38888) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g2Bj8-0000dd-70 for 32676@debbugs.gnu.org; Tue, 18 Sep 2018 04:51:22 -0400 Original-Received: by mail-wr1-f66.google.com with SMTP id w11-v6so1159689wrc.5 for <32676@debbugs.gnu.org>; Tue, 18 Sep 2018 01:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HiCkzvmzROfVxdaWH/5Avw6SMGXbzJl+M0jmifjQVNE=; b=To3HgMjzAD/FFlrKhNmePMtM9/BfG8BevZYLocTk5g8sDqktlsP+KMUOu5bgLn0Sr4 1vsaKSmPX54O25T645zWf5o0ggMekP1r8bl9eFFDIjhG1WT9jITpIvd6/dGotk6pI+fr zvHxNWU6CuXUgbUEj0x7dqNcPLNUk5jl1zgd1zOz3CR3VYOiHBPahBPvIR9/5QBCkmTa prMwpJb6VsAV5FulT0e+Jy07c3nrUc//ZUdSSWC7YVa/IgARl43ksLxx2oXa2hEZ6VaR Y1BV9xAMGCSnE381KgVLy52DYSviX/PUWmMzrKChYasubvME/YUaajaNJNNKPF1KEc/O TLNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HiCkzvmzROfVxdaWH/5Avw6SMGXbzJl+M0jmifjQVNE=; b=AbvMzRw7eg+X9Gy2DjGIE3zpqRh5dszKd4J2N2ksYq6bjOcdKnNaScry6kJVaooLYO SKce0YWqYqWWSDWXJkBzHV6brD73Otl5youTXwx+eS23LiEeMfSYn4zm5jnNcnHACBNP b0Pn1HWjqiXibSqG0waCiaJlR2JbMl9VuLH3V62j/V8+5heYXLWvKReGUu4JBiP7Fdya AFVvGtZ2qdYplGZA02Bwg6G7cjVIms4QD/qQrE3xgFWKd1nn65cs/alNzrKimpOhlC63 dJ8fmiT/DrtLIVGRst/DKFuDIwftFz6W/Kjl0o6AD8N5QLYuIWfLgpDWh12+er3ICsFp vZVQ== X-Gm-Message-State: APzg51BUzY3DdUfwB1YBYL4Nl3YZNjqxGAkGEfCp/GDFLZJqPhL0MRtg azEIHXfNEg8UICf8dUFyJA35wYrogwAeKvo7Grs= X-Google-Smtp-Source: ANB0VdaqvLFkgsGOnvQ6+JD5HsWVtfhBwYiLbX1iKBLpMm0fJgJEcVppGQiFc9wcJKTuhDPkWn4jHtWc2OTceVymJ24= X-Received: by 2002:adf:e3c4:: with SMTP id k4-v6mr22202799wrm.94.1537260676188; Tue, 18 Sep 2018 01:51:16 -0700 (PDT) In-Reply-To: <87worlgh0k.fsf@mail.linkov.net> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:150392 Archived-At: --000000000000880ff60576216421 Content-Type: text/plain; charset="UTF-8" > I agree that a timer is not necessary in next-error-last-buffer. > I just wanted to emphasize that your new customization could be like > next-error-highlight defcustom (but without a timer option). Yes. It looks like (point) is always located > at this place because compilation-next-error-function sets > overlay-arrow-position to (point-marker), so it should be the > right place to highlight indeed. Yes. I tried replacing compilation-current-error with point and it works as expected. I am not sure how I would update the patch. While searching for this thread, I came across another time qhwn a user made a query for the same feature I am proposing. https://groups.google.com/forum/#!topic/gnu.emacs.help/q1QucyB1Nzw It provides another explanation of why hl-line doesn't work well in this case. Ernesto On Sun, Sep 16, 2018 at 4:38 PM Juri Linkov wrote: > >> Do I understand correctly that your proposed feature is like > >> next-error-highlight, > >> but instead of highlighting the error locus, it highlights the error > >> message? > > > > Yes, although I don't think it's important to support a timer to turn off > > highlighting like next-error-highlight does since the error locus > > highlighting might get in the user's way in source buffers, but not in > the > > next-error buffer. > > I agree that a timer is not necessary in next-error-last-buffer. > I just wanted to emphasize that your new customization could be like > next-error-highlight defcustom (but without a timer option). > > > I don't see a reference to compilation-highlight-regexp or > > compilation-highlight-overlay in my patch or in this thread. Although I > did > > use compilation-current-error to find the mark at the error message > > location, which I think is not appropriate since that would be > > compilation-specific, and I think it should be (point) instead. Is this > > what you mean? > > I guess you need to highlight exactly the same place from where > the error was visited. It looks like (point) is always located > at this place because compilation-next-error-function sets > overlay-arrow-position to (point-marker), so it should be the > right place to highlight indeed. > --000000000000880ff60576216421 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I agree that a timer is not necessary in next-error-last= -buffer.
I just wanted to emphasize that your new customization could be= like
next-error-highlight defcustom (but without a timer option).
Yes.

It looks like (point) is always lo= cated
at this place because compilation-next-error-function sets
over= lay-arrow-position to (point-marker), so it should be the
right place to= highlight indeed.
Yes. I tried replacing compilation-curr= ent-error with point and it works as expected. I am not sure how I would up= date the patch.

=C2=A0
While searching for th= is thread, I came across another time qhwn a user made a query for the same= feature I am proposing.
It provides another explanation of why hl-line doesn'= t work well in this case.

Ernesto
On = Sun, Sep 16, 2018 at 4:38 PM Juri Linkov <juri@linkov.net> wrote:
>> Do I understand correctly that your proposed f= eature is like
>> next-error-highlight,
>> but instead of highlighting the error locus, it highlights the err= or
>> message?
>
> Yes, although I don't think it's important to support a timer = to turn off
> highlighting like next-error-highlight does since the error locus
> highlighting might get in the user's way in source buffers, but no= t in the
> next-error buffer.

I agree that a timer is not necessary in next-error-last-buffer.
I just wanted to emphasize that your new customization could be like
next-error-highlight defcustom (but without a timer option).

> I don't see a reference to compilation-highlight-regexp or
> compilation-highlight-overlay in my patch or in this thread. Although = I did
> use compilation-current-error to find the mark at the error message > location, which I think is not appropriate since that would be
> compilation-specific, and I think it should be (point) instead. Is thi= s
> what you mean?

I guess you need to highlight exactly the same place from where
the error was visited.=C2=A0 It looks like (point) is always located
at this place because compilation-next-error-function sets
overlay-arrow-position to (point-marker), so it should be the
right place to highlight indeed.
--000000000000880ff60576216421--