Skip to content
This repository was archived by the owner on Dec 15, 2022. It is now read-only.
This repository was archived by the owner on Dec 15, 2022. It is now read-only.

File diff mouse selection UX outline bugs and improvements #471

@kuychaco

Description

@kuychaco

Currently mouse selection behavior while shift/cmd-clicking across hunks is inconsistent. In this issue I will outline the various permutations of user actions and proposed behavior of each.

Refer to #469 for context on plans for indicating hunk/line mode and proposed rules for entering each mode.

Factors:

  • in hunk or line mode
  • selection via regular click, shift-click, or cmd-click
  • selecting a line or hunk header

Behavior for regular clicking (with no modifier keys) is as expected 👍 . The following outlines the current and proposed behavior for shift/cmd-clicking

When lines are selected in line mode...

  • selecting another line:
    • expected behavior for the cases of shift/cmd-clicking other lines is pretty straightforward and is already implemented 👍
  • selecting a hunk header:
    • proposed behavior: shift/cmd-clicking should retain previous selections, and additionally select or unselect lines as appropriate, keeping line mode (per File diff selection mode improvements #469)
    • current behavior: the clicked hunk is selected 👍 , BUT previous selections are lost, hunk mode is entered 👎

When a hunk is selected and we're in hunk mode...

  • proposed behavior: when selecting another hunk header or a line within a hunk while pressing shift or command, the entire hunk is additionally selected or unselected as appropriate, keeping hunk mode
  • current behavior when shift/cmd-clicking:
    • when selecting a line: selected line is selected 👍 , BUT the original hunk selection is partially lost, and the selection mode is switched to line 👎
    • when selecting a hunk header: hunk is selected 👍, BUT the original selection is lost 👎

Note: current drag behavior is as expected.

Given that we're seriously considering dropping the diff view as it currently exists in favor of showing diff information in a text editor so that users can more easily edit their diffs and view context around hunks (#391 (comment)), I'm having doubts as to whether it's worth investing the time and energy to make these fixes/improvements. I'm inclined to let this sit for now and focus on other issues and features. Especially since these inconsistencies aren't blocking for using the diff view effectively.

Versions

GitHub Package Version (git --git-dir ~/.atom/packages/github/.git rev-parse head): 65a2403

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions