bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode

bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode

[Dmitry Gutov]

1. Make some changes, save, open vc-diff buffer.

2. Extend region over the pieces of the hunk that `diff-refine-hunk'
highlighted.

If there are only a few such pieces, you only see a discrepancy between
the pieces where region starts and ends (if either is within a refined
part), because the region is partly visible there.

If most of the hunk was refined (a lot of changes), however, the region
becomes mostly invisible (aside from the bits between reginements).

In GNU Emacs 24.3.50.3 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.6)
 of 2014-01-13 on axl
Repository revision: 116011 monnier@iro.umontreal.ca-20140113153301-ozd3taipkkc7p5cr
Windowing system distributor `The X.Org Foundation', version 11.0.11405000
System Description:	Ubuntu 13.10

bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

Dmitry Gutov <dgutov@yandex.ru> writes:

> 1. Make some changes, save, open vc-diff buffer.
>
> 2. Extend region over the pieces of the hunk that `diff-refine-hunk'
> highlighted.
>
> If there are only a few such pieces, you only see a discrepancy between
> the pieces where region starts and ends (if either is within a refined
> part), because the region is partly visible there.
>
> If most of the hunk was refined (a lot of changes), however, the region
> becomes mostly invisible (aside from the bits between reginements).

I'm not sure I understand the recipe at all, but what I did was

C-x v =

in a file that had changes, and then created a region with the mouse
over an arbitrary bit of that buffer:


[-- Attachment #2: Type: image/png, Size: 88951 bytes --]

[-- Attachment #3: Type: text/plain, Size: 236 bytes --]


And the results don't look obviously wrong to me.  So is this something
that has been fixed already, or am I reproducing it wrong?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode

[Kévin Le Gouguec]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I'm not sure I understand the recipe at all, but what I did was
>
> C-x v =
>
> in a file that had changes, and then created a region with the mouse
> over an arbitrary bit of that buffer:
>
> <screenshot>
>
> And the results don't look obviously wrong to me.  So is this something
> that has been fixed already, or am I reproducing it wrong?

I'm not sure I understand the original recipe either, but the following
steps do show something inconsistent IMO:

1. emacs -Q CONTRIBUTE
2. C-x v g
3. move to "461cb9217d8 CONTRIBUTE (Paul Eggert 2019-05-25 10)"
4. =
5. move to the first removed line ("Briefly, …")
6. C-SPC
7. C-f C-f …

As long as point does not go past the refinement (before the comma), the
region's background has the region face's background.

Once point moves past the refinement, only non-refined parts keep the
region face's background; refined parts keep the refinement background.

bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode

[Kévin Le Gouguec]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> 1. emacs -Q CONTRIBUTE
> 2. C-x v g
> 3. move to "461cb9217d8 CONTRIBUTE (Paul Eggert 2019-05-25 10)"
> 4. =
> 5. move to the first removed line ("Briefly, …")
> 6. C-SPC
> 7. C-f C-f …
>
> As long as point does not go past the refinement (before the comma), the
> region's background has the region face's background.
>
> Once point moves past the refinement, only non-refined parts keep the
> region face's background; refined parts keep the refinement background.

I'd say "one picture is worth a thousand words", but… obviously this
saying dates from before we learned how to encode words and pictures
into bytes.


[-- Attachment #2: Emacs-Screenshot-2020-12-06-16:41:33.pdf --]
[-- Type: application/pdf, Size: 26108 bytes --]

[-- Attachment #3: Emacs-Screenshot-2020-12-06-16:41:37.pdf --]
[-- Type: application/pdf, Size: 26110 bytes --]

bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Date: Sun, 06 Dec 2020 16:39:04 +0100
> Cc: 16514@debbugs.gnu.org, Dmitry Gutov <dgutov@yandex.ru>
> 
> As long as point does not go past the refinement (before the comma), the
> region's background has the region face's background.
> 
> Once point moves past the refinement, only non-refined parts keep the
> region face's background; refined parts keep the refinement background.

This is expected, since we sort overlays so that the one whose extent
is larger wins.

To do anything else the overlays should have priorities.

bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode

[Andreas Schwab]

On Dez 06 2020, Kévin Le Gouguec wrote:

> Once point moves past the refinement, only non-refined parts keep the
> region face's background; refined parts keep the refinement background.

That's because the refine face is placed by an overlay that's above the
region overlay.  The non-refine face is part of a text property.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode

[Dmitry Gutov]

On 06.12.2020 16:55, Lars Ingebrigtsen wrote:
> in a file that had changes, and then created a region with the mouse
> over an arbitrary bit of that buffer:

Hi Lars,

your example doesn't contain any "refined" pieces. Which are key to 
reproducing the problem.

Anyway, Kevin gave a good example.

bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode

[Dmitry Gutov]

On 06.12.2020 17:58, Eli Zaretskii wrote:
>> From: Kévin Le Gouguec<kevin.legouguec@gmail.com>
>> Date: Sun, 06 Dec 2020 16:39:04 +0100
>> Cc:16514@debbugs.gnu.org, Dmitry Gutov<dgutov@yandex.ru>
>>
>> As long as point does not go past the refinement (before the comma), the
>> region's background has the region face's background.
>>
>> Once point moves past the refinement, only non-refined parts keep the
>> region face's background; refined parts keep the refinement background.
> This is expected, since we sort overlays so that the one whose extent
> is larger wins.
> 
> To do anything else the overlays should have priorities.

So it's probably correct from the low-level primitives POV.

But is this a good UI? And shouldn't we maybe tweak the high-level 
implementation (perhaps, the way how the refinements are applied) so 
that the behavior is better?

bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode

[Eli Zaretskii]

> Cc: larsi@gnus.org, 16514@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 6 Dec 2020 21:34:44 +0200
> 
> > This is expected, since we sort overlays so that the one whose extent
> > is larger wins.
> > 
> > To do anything else the overlays should have priorities.
> 
> So it's probably correct from the low-level primitives POV.
> 
> But is this a good UI? And shouldn't we maybe tweak the high-level 
> implementation (perhaps, the way how the refinements are applied) so 
> that the behavior is better?

I agree that the end result is not the best one.  If by "tweak the
high-level implementation" you meant something like use priorities for
the relevant overlays, then that's exactly what I tried to hint at.

IOW, yes, we should do something on the application level to cause the
selected region look consistently.

bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode

[Lars Ingebrigtsen]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> I'm not sure I understand the original recipe either, but the following
> steps do show something inconsistent IMO:
>
> 1. emacs -Q CONTRIBUTE
> 2. C-x v g
> 3. move to "461cb9217d8 CONTRIBUTE (Paul Eggert 2019-05-25 10)"
> 4. =
> 5. move to the first removed line ("Briefly, …")
> 6. C-SPC
> 7. C-f C-f …
>
> As long as point does not go past the refinement (before the comma), the
> region's background has the region face's background.
>
> Once point moves past the refinement, only non-refined parts keep the
> region face's background; refined parts keep the refinement background.

Ah, thanks.  Yes, that does look pretty odd.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no