From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ernesto Alfonso Newsgroups: gmane.emacs.bugs Subject: bug#32676: Feature request Date: Sun, 7 Apr 2019 14:56:53 -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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000dba0b00585f7cc59" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="159765"; mail-complaints-to="usenet@blaine.gmane.org" 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 Sun Apr 07 23:58:13 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hDFnn-000fQi-VX for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Apr 2019 23:58:12 +0200 Original-Received: from localhost ([127.0.0.1]:44142 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDFnn-0005Th-0a for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Apr 2019 17:58:11 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:52323) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDFng-0005TV-5R for bug-gnu-emacs@gnu.org; Sun, 07 Apr 2019 17:58:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hDFne-0008Fi-Gh for bug-gnu-emacs@gnu.org; Sun, 07 Apr 2019 17:58:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35270) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hDFne-0008FW-CF for bug-gnu-emacs@gnu.org; Sun, 07 Apr 2019 17:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hDFne-0000xE-24 for bug-gnu-emacs@gnu.org; Sun, 07 Apr 2019 17:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ernesto Alfonso Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Apr 2019 21:58: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.15546742323607 (code B ref 32676); Sun, 07 Apr 2019 21:58:01 +0000 Original-Received: (at 32676) by debbugs.gnu.org; 7 Apr 2019 21:57:12 +0000 Original-Received: from localhost ([127.0.0.1]:48814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDFmp-0000w7-Hq for submit@debbugs.gnu.org; Sun, 07 Apr 2019 17:57:11 -0400 Original-Received: from mail-wr1-f48.google.com ([209.85.221.48]:36638) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDFmn-0000vs-SI for 32676@debbugs.gnu.org; Sun, 07 Apr 2019 17:57:10 -0400 Original-Received: by mail-wr1-f48.google.com with SMTP id y13so14040543wrd.3 for <32676@debbugs.gnu.org>; Sun, 07 Apr 2019 14:57:09 -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=n7M+AVcNAjDvJJ7bJqfCXa4cD0k/1qH8yHLBAF7tK8s=; b=RcbrORD6LHV9H0ZLsl5atEevqayB3pjMyjd59ECkw3bJXosTPE0iIVzYYbuWKphE6s cNnZy8thY6CwNlJTxkZp0Cv9pfaIEkN4toqfnCbopbdxHzMaTTibYLhfvBKF+h5veKNp N0JDsPDmAHt+NjUcYVJj/VBwTwc30AAN4x55V5tAoimYTjDrgC+ablmM+dK0oUzWCvAB +10NQKZnCevHCw7jT0cuxrfK7e7/p4OWYmUhZEFQljOMFZwkYgS9dwH4xODU7SKPMBzB gN0AxIdGGpbdJ3IwnJmrXk1/J9KvJdy2sXxMJAUCi11KhR738XCCAm6Ssb0vLz5GBdl0 Gqhg== 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=n7M+AVcNAjDvJJ7bJqfCXa4cD0k/1qH8yHLBAF7tK8s=; b=dh8/gmH1IJmHvJiQD+gUeuMiuT4TNGH5oKDkdwYlG4AjJA4rbZjOV/t7SQo5FLOFjv o0cXXLjBp7FtvWKRhOLfcWECtZD2K3aks5iHYImzdGuYVXdQJ9yreHrOYPjVX503p9q7 z2p0bT8yr9dIbBZ7zuUwvy9wY0xuez4XKuZ/f79JbIg5Dv29WR6F78j5m3ahUN5ovYhz bT69aVoLTHrCKJ/jwNrsTQ+ZbV2yVRyw21mMZZeC+Zeh5cntc+BGwm95xSjFw0yBgDUT X6O6VqhmnUdBNK8BAbdFrbkMos0NZiQk27KBQvf+4mC3YO6ptw/k2Fmtdlx5wODGwYUP YBqw== X-Gm-Message-State: APjAAAWpYQZurp78wGwueDOmIJt/OY7Uzfn9ab1O1p+Vm2Dc0JUPrnBK knzLg7xHXJMd3x9vGc/s2VJh19MT9coQy7eTYP0= X-Google-Smtp-Source: APXvYqwEAZYp9CbGVjEBEk1+TdV4VDnKlOfx9BFXB4VG2tU/ESZT2FTkMK8xxmJIp0G/Dg9jCQrai39tE3czO6ikVu0= X-Received: by 2002:a5d:494c:: with SMTP id r12mr16207113wrs.250.1554674223913; Sun, 07 Apr 2019 14:57:03 -0700 (PDT) In-Reply-To: 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: 209.51.188.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:157329 Archived-At: --000000000000dba0b00585f7cc59 Content-Type: text/plain; charset="UTF-8" I'd like to know if this patch is still being considered? Ernesto On Tue, Sep 18, 2018 at 1:51 AM Ernesto Alfonso wrote: > > 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. >> > --000000000000dba0b00585f7cc59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd like to know if this patch is still being consider= ed?

Ernesto

On Tue, Sep 18, 2018 at 1:51 AM Ernesto= Alfonso <erjoalgo@gmail.com&g= t; wrote:

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

It looks like (point) is always located<= br>at this place because compilation-next-error-function sets
overlay-ar= row-position to (point-marker), so it should be the
right place to highl= ight indeed.
Yes. I tried replacing compilation-current-er= ror with point and it works as expected. I am not sure how I would update t= he patch.

=C2=A0
While searching for this thr= ead, I came across another time qhwn a user made a query for the same featu= re I am proposing.


It provides another explanation of why hl-lin= e doesn't work well in this case.

Ernesto
On Sun, Sep 16, 2018 at 4:38 PM Juri L= inkov <juri@linkov.= net> wrote:
>> Do I understand correctly that your proposed feature 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.
--000000000000dba0b00585f7cc59--