bug#49624: compilation message end-column function off-by-one bug

[Juri Linkov <juri@linkov.net>]

>>> 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.