Bug 190844 - [Apply Patch] Hunk compare editor needs to provide more information
Summary: [Apply Patch] Hunk compare editor needs to provide more information
Status: ASSIGNED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Compare (show other bugs)
Version: 3.3   Edit
Hardware: Other Linux
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform-Compare-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-04 12:57 EDT by Stefan Xenos CLA
Modified: 2019-09-06 16:06 EDT (History)
4 users (show)

See Also:


Attachments
Mockup that shows how to move the insertion point without additional toolbar buttons (67.59 KB, image/png)
2007-11-30 14:46 EST, Stefan Xenos CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Xenos CLA 2007-06-04 12:57:43 EDT
It is currently quite hard to merge hunks using the hunk compare editor. Basically, there's quite a bit of information contained in the patch that is useful for performing the merge but is omitted from the hunk editor.

1. Provide a stronger affordance for the suggested insertion location.

The hunk editor currently sets the initial scroll bar positions to show where it believes the correct insertion point is. Most users don't notice this, and the suggested insert point is lost once the user moves the scroll bars. Suggestion: show the suggested insertion point on the left, and provide up/down arrows to move it around in the file.


2. Provide some way to display the before state. 

It can be hard to figure out where a hunk goes unless you can see the original lines. Especially in the case of deletions where the context lines have changed, we need some way to see the lines that were deleted.

Suggestion: Include a button and a context menu action to "show before state" - this can open a dialog or a third pane that shows the lines that the patcher is looking for.


3. Provide some way to see the hunk in context.

Users have complained that the hunk itself is often not enough to determine what the change does. In these cases, it would help if they could see the hunk in its original context.

Suggestion: allow the caller who opens the editor to supply the original version of the file as well as a hunk. If it is supplied, show the entire file (or, say 200 lines in each direction), grayed out, around the hunk.
Comment 1 Michael Valenta CLA 2007-06-04 14:37:28 EDT
I agree with point 1. Point 2 is already provided (i.e. the ancestor contains the before lines). I think that point 3 is worth investigating.
Comment 2 Stefan Xenos CLA 2007-06-25 12:04:54 EDT
Regarding point 2:

Thanks for the tip. I'm now showing the ancestor pane by default. However, it is hard to tell by looking at the editor that the upper quadrent contains the deleted lines, and I'm not sure that most users would know what they're supposed to do when they see the three-paned editor.

I would suggest showing the deleted lines in the right pane, in strikethrough. In the event of a modify, show the "before" lines in strikethrough, followed by the "after" lines. The after lines would have the blue background and context lines would be undecorated (as they are now).

I suspect that most users will not intuitively understand what the "common ancestor" means in the case of a hunk, but *will* understand that strikethrough text means a deletion.
Comment 3 Stefan Xenos CLA 2007-11-30 14:46:06 EST
Created attachment 84222 [details]
Mockup that shows how to move the insertion point without additional toolbar buttons

This shows an alternative way to show the buttons for moving the insertion point (the LCS buttons are not shown).

Rather than putting them on the toolbar, they can be attached to the insertion point marker itself along with a grippy that lets you drag it up and down.
Comment 4 Szymon Brandys CLA 2008-05-09 04:23:54 EDT
Mass update - removing 3.4 target. This was one of the bugs marked for
investigation (and potential fixing) in 3.4 but we ran out of time. Please ping
on the bug if fixing it would be really important for 3.4, and does not require
API changes or feature work.
Comment 5 Eclipse Webmaster CLA 2019-09-06 16:06:04 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.