From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#49624: compilation message end-column function off-by-one bug Date: Mon, 26 Jul 2021 20:06:20 +0300 Organization: LINKOV.NET Message-ID: <87h7ghku9w.fsf@mail.linkov.net> References: <462A3B1B-6632-4740-907D-03B67377452E@acm.org> <83h7gr781e.fsf@gnu.org> <83czrf773k.fsf@gnu.org> <5FDA92A6-421D-4A91-A2D9-D0101B115037@acm.org> <875yx6qtwg.fsf@mail.linkov.net> <5BAAD7D4-A578-4DB5-925E-ECE02B4F4B56@acm.org> <87pmvevv28.fsf@mail.linkov.net> <71FBE546-8821-497D-83A9-A6E4CF0BBBA3@acm.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15080"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) Cc: 49624@debbugs.gnu.org, Stefan Monnier To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 26 19:18:10 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m84Ez-0003lC-Th for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 26 Jul 2021 19:18:09 +0200 Original-Received: from localhost ([::1]:56460 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m84Ey-0002Mv-UC for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 26 Jul 2021 13:18:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49920) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m84Et-0002Mm-1x for bug-gnu-emacs@gnu.org; Mon, 26 Jul 2021 13:18:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39887) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m84Es-00016H-QX for bug-gnu-emacs@gnu.org; Mon, 26 Jul 2021 13:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m84Es-0000gv-3W for bug-gnu-emacs@gnu.org; Mon, 26 Jul 2021 13:18:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 26 Jul 2021 17:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49624 X-GNU-PR-Package: emacs Original-Received: via spool by 49624-submit@debbugs.gnu.org id=B49624.16273198522619 (code B ref 49624); Mon, 26 Jul 2021 17:18:02 +0000 Original-Received: (at 49624) by debbugs.gnu.org; 26 Jul 2021 17:17:32 +0000 Original-Received: from localhost ([127.0.0.1]:51433 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m84EO-0000gB-Ff for submit@debbugs.gnu.org; Mon, 26 Jul 2021 13:17:32 -0400 Original-Received: from relay9-d.mail.gandi.net ([217.70.183.199]:40799) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m84EL-0000fw-SQ for 49624@debbugs.gnu.org; Mon, 26 Jul 2021 13:17:31 -0400 Original-Received: (Authenticated sender: juri@linkov.net) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id BE65FFF805; Mon, 26 Jul 2021 17:17:21 +0000 (UTC) In-Reply-To: <71FBE546-8821-497D-83A9-A6E4CF0BBBA3@acm.org> ("Mattias =?UTF-8?Q?Engdeg=C3=A5rd?="'s message of "Fri, 23 Jul 2021 15:24:55 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:210753 Archived-At: >>> Not even 9dc3a46a444a46e00ed3287a3174d73ed9511dac >>> where the funcall for col and end-col originated? >>> In any case, no worry -- I'll deal with it. >> >> My apologies. This commit is so old that I even don't recognize it. >> I need to study this code again since I don't remember this part >> of compile.el. > > Thank you, but it's not that important. Let's not overthink it -- I'm > treating it as the bug it is and have pushed the obvious fix to master. I'm terribly sorry that it took so much time for me to realize that my commit 9dc3a46a444a46e00ed3287a3174d73ed9511dac was part of efforts to add column information to grep matches, also I needed to inspect the history of column-related code in compile.el to understand the reason of incrementing the value of end-col. Here are my findings: The commit c0090c20f88d1e8c99e9823db5b9cc25d98672bc with the log message (compilation-error-properties): Store one more than end-col, if present, so that transient-mark-mode will highlight last char too. turned an exclusive upper bound (e.g. [4, 6) that highlighted 2 chars) into an inclusive upper bound (e.g. [4, 6] that highlighted 3 chars) on the assumption that most compilation tools report inclusive ranges. Then without changing this logic in 9dc3a46a444a46e00ed3287a3174d73ed9511dac I added a funcall without incrementing its result by 1 on the assumption that the function can return an already inclusive result that doesn't need to offset by 1. Now your commit aa5437493b1ca539409495ecdc54cf420ea110b9 broke the highlighting of columns in grep-regexp-alist, so now visiting a grep match highlights an additional character that is not part of the grep match. Maybe there are more existing functions whose backward-compatibility is broken now. For example, (javac ,... 1 2 ,#'current-column (3)) uses ,#'current-column although not for end-col, so it's not affected.