* bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode
@ 2014-01-21 4:44 Dmitry Gutov
2020-12-06 14:55 ` Lars Ingebrigtsen
0 siblings, 1 reply; 10+ messages in thread
From: Dmitry Gutov @ 2014-01-21 4:44 UTC (permalink / raw)
To: 16514
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode
2014-01-21 4:44 bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode Dmitry Gutov
@ 2020-12-06 14:55 ` Lars Ingebrigtsen
2020-12-06 15:39 ` Kévin Le Gouguec
2020-12-06 19:33 ` Dmitry Gutov
0 siblings, 2 replies; 10+ messages in thread
From: Lars Ingebrigtsen @ 2020-12-06 14:55 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 16514
[-- 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode
2020-12-06 14:55 ` Lars Ingebrigtsen
@ 2020-12-06 15:39 ` Kévin Le Gouguec
2020-12-06 15:48 ` Kévin Le Gouguec
` (3 more replies)
2020-12-06 19:33 ` Dmitry Gutov
1 sibling, 4 replies; 10+ messages in thread
From: Kévin Le Gouguec @ 2020-12-06 15:39 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 16514, Dmitry Gutov
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode
2020-12-06 15:39 ` Kévin Le Gouguec
@ 2020-12-06 15:48 ` Kévin Le Gouguec
2020-12-06 15:58 ` Eli Zaretskii
` (2 subsequent siblings)
3 siblings, 0 replies; 10+ messages in thread
From: Kévin Le Gouguec @ 2020-12-06 15:48 UTC (permalink / raw)
To: 16514
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread* bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode
2020-12-06 15:39 ` Kévin Le Gouguec
2020-12-06 15:48 ` Kévin Le Gouguec
@ 2020-12-06 15:58 ` Eli Zaretskii
2020-12-06 19:34 ` Dmitry Gutov
2020-12-06 16:10 ` Andreas Schwab
2020-12-07 13:19 ` Lars Ingebrigtsen
3 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2020-12-06 15:58 UTC (permalink / raw)
To: Kévin Le Gouguec; +Cc: larsi, 16514, dgutov
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode
2020-12-06 15:58 ` Eli Zaretskii
@ 2020-12-06 19:34 ` Dmitry Gutov
2020-12-06 19:56 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: Dmitry Gutov @ 2020-12-06 19:34 UTC (permalink / raw)
To: Eli Zaretskii, Kévin Le Gouguec; +Cc: larsi, 16514
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?
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode
2020-12-06 19:34 ` Dmitry Gutov
@ 2020-12-06 19:56 ` Eli Zaretskii
0 siblings, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2020-12-06 19:56 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: larsi, 16514, kevin.legouguec
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode
2020-12-06 15:39 ` Kévin Le Gouguec
2020-12-06 15:48 ` Kévin Le Gouguec
2020-12-06 15:58 ` Eli Zaretskii
@ 2020-12-06 16:10 ` Andreas Schwab
2020-12-07 13:19 ` Lars Ingebrigtsen
3 siblings, 0 replies; 10+ messages in thread
From: Andreas Schwab @ 2020-12-06 16:10 UTC (permalink / raw)
To: Kévin Le Gouguec; +Cc: Lars Ingebrigtsen, 16514, Dmitry Gutov
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."
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode
2020-12-06 15:39 ` Kévin Le Gouguec
` (2 preceding siblings ...)
2020-12-06 16:10 ` Andreas Schwab
@ 2020-12-07 13:19 ` Lars Ingebrigtsen
3 siblings, 0 replies; 10+ messages in thread
From: Lars Ingebrigtsen @ 2020-12-07 13:19 UTC (permalink / raw)
To: Kévin Le Gouguec; +Cc: 16514, Dmitry Gutov
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode
2020-12-06 14:55 ` Lars Ingebrigtsen
2020-12-06 15:39 ` Kévin Le Gouguec
@ 2020-12-06 19:33 ` Dmitry Gutov
1 sibling, 0 replies; 10+ messages in thread
From: Dmitry Gutov @ 2020-12-06 19:33 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 16514
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-12-07 13:19 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-01-21 4:44 bug#16514: 24.3.50; Region overlay looks bad on refined hunks in diff-mode Dmitry Gutov
2020-12-06 14:55 ` Lars Ingebrigtsen
2020-12-06 15:39 ` Kévin Le Gouguec
2020-12-06 15:48 ` Kévin Le Gouguec
2020-12-06 15:58 ` Eli Zaretskii
2020-12-06 19:34 ` Dmitry Gutov
2020-12-06 19:56 ` Eli Zaretskii
2020-12-06 16:10 ` Andreas Schwab
2020-12-07 13:19 ` Lars Ingebrigtsen
2020-12-06 19:33 ` Dmitry Gutov
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).