Feature: Option to Auto-Select Next Item After Delete (macOS Finder-style)

[star26bsd]

What feature or improvement do you think would benefit Files?

Add an optional setting to automatically select (not just focus) the next item after deleting a file or folder. This would enable macOS Finder-style keyboard workflow where users can sequentially delete multiple files by repeatedly pressing the Delete key.

While I understand that Files tries to mimic the native UX of Windows Explorer, I believe many users switch to it because Files is already so much better in many regards. MacOS people (like me) who struggle using Windows Explorer, will find Files a relieve. This feature would remove another every-day struggle using a file explorer on Windows, even though most Windows people will likely not use it.

Problem Description

Currently, after deleting a file using the keyboard:

1. The deleted file is removed from the list
2. The focus moves to the next item (dotted border/focus ring)
3. The next item is not selected (no highlighted background)
4. Pressing Delete again does nothing because no item is selected
5. User must press Arrow Down/Up or click to re-select before deleting another file

This mimics Windows Explorer behavior, but creates friction for users who:

• Are migrating from macOS where Finder auto-selects the next item
• Want to quickly review and delete multiple files sequentially
• Prefer keyboard-centric workflows without needing to re-select after each deletion

Expected Behavior (with proposed setting enabled)

After deleting a file using the keyboard:

1. The deleted file is removed from the list
2. The next item is automatically selected (highlighted background)
3. The next item also receives focus for keyboard navigation
4. Pressing Delete again immediately deletes the next file
5. User can sequentially delete files without additional keystrokes

Proposed Solution

Add a toggle setting in Settings > Folders (or Settings > Advanced):

Setting Name: "Auto-select next item after delete"
Description: "When enabled, the next item will be automatically selected after deleting a file or folder. This provides macOS Finder-like behavior for sequential deletions."
Default: Off (preserving current Windows Explorer behavior)

Technical Approach

The implementation would modify the post-delete handler in ShellViewModel to:

1. Check the user preference setting
2. If enabled, set both SelectedItems and FocusedItem to the next item in the list
3. If disabled, maintain current behavior (focus only, no selection)

Conceptual Code Change

// In ShellViewModel.cs, after delete operation completes

if (UserSettingsService.FoldersSettingsService.AutoSelectNextItemAfterDelete)
{
    var nextIndex = Math.Min(deletedItemIndex, FilesAndFolders.Count - 1);
    if (nextIndex >= 0)
    {
        var nextItem = FilesAndFolders[nextIndex];
        SelectedItems.Clear();
        SelectedItems.Add(nextItem);
        FocusedItem = nextItem;
    }
}

Use Cases

1. Photo/Media Curation: Reviewing a folder of images and deleting unwanted ones sequentially
2. Download Cleanup: Going through a Downloads folder and removing old files one by one
3. Code Cleanup: Removing obsolete files from a project directory
4. Cross-Platform Users: Users switching between macOS and Windows who expect consistent behavior

Platform Comparison

File Manager	Behavior After Delete
Windows Explorer	Focus only (no selection)
macOS Finder	Auto-select next item
Nautilus (GNOME)	Auto-select next item
Dolphin (KDE)	Auto-select next item
Total Commander	Configurable

Additional Context

• This is a non-breaking change as the default would preserve current Windows Explorer behavior
• The setting would benefit keyboard-centric users and those with accessibility needs
• Related closed issue: Bug: Deleting file in grouped folder moves selection to random item #9429 (addressed random selection, but maintained focus-only behavior)
• Similar focus/selection issues have been reported in Keyboard Navigation Between Files And Folders #8352, Bug: Focus is lost when changing tabs #15288, Bug: Keyboard focus is changed when layout changes automaticlly #16530

Thanks a lot!
Stephan

Requirements

Requirements Checklist

• New setting in IFoldersSettingsService / FoldersSettingsService
• UI toggle in Settings > Folders page
• Localization strings for setting name and description
• Modify post-delete handler in ShellViewModel
• Unit tests for both enabled/disabled states
• Documentation update

Files Version

4.0.21.0

Windows Version

10.0.26200.7462

Comments

No response

[yaira2]

Thank you for your feedback.

[MarathonMax]

I have asked for this feature before but here it is again: make "click again" behave differently than "'double-click". Right now, if an item is selected and you click on it again (this is different from a quick doubvle click), it behaves as if I had just double-clicked on the item. All other saoftwares differentiate between these two behaviors. Make Files do as such, Tks.,

[yaira2]

@MarathonMax that doesn't seem related to this proposal. If you already opened an issue, feel free to send a link.

[yaira2]

@star26bsd if we make this change, it'll probably be to make it the new behavior without adding a setting. One question that comes to mind is what is the expected behavior if the file is deleted externally?

[star26bsd]

@yaira2 based on a quick analysis of the behavior of various file managers and UX best practices, here's what I think is the most user-centric approach:

For user-initiated deletions (via Files UI/keyboard): Auto-select the next item. This enables the sequential deletion workflow, likely others.

For external deletions, I'd rather chose NOT to auto-select, due to:

1. Principle of Least Surprise: External changes shouldn't alter the selection state unexpectedly
2. Error Prevention: An unexpected selection could lead to accidental deletion of additional files if the user presses Delete
3. User Agency: The user didn't initiate the action, so they shouldn't receive an "action response"

This differentiated approach seems more aligned with modern UX principles than blindly copying either Windows Explorer (no auto-select ever) or macOS Finder (auto-select always).

Optionally, a subtle notification in the Status Center could inform the user about external changes without disrupting their workflow.

Hope my humble opinion helps!

[yaira2]

Principle of Least Surprise: External changes shouldn't alter the selection state unexpectedly

I should have phrased my question a little differently. More specifically, what should happen if the selected item in Files is deleted externally? The selection in Files will change since the previous selected item no longer exists, should the selection move to the next item? This is probably not a common scenario, but still important to consider.

[star26bsd]

Good point – I need to refine my earlier statement.

If the currently selected item is deleted externally, auto-selecting the adjacent item makes sense because:

• The selection must change (the item no longer exists)
• Moving to adjacent is the minimal disruption – it preserves spatial context
• This matches behavior in other list-based UIs (email clients, IDEs, etc.)

My earlier "no auto-select for external deletions" was meant for the case where a non-selected item is deleted – in that case, the existing selection should remain unchanged, and no new selection should appear unexpectedly.

[yaira2]

Thank you, it sounds like we're on the same page.

[yaira2]

@star26bsd would you like to work on this? If you do, we should just make this the new behavior without adding a setting.