Allow TAB to select option from EditorSuggestorPopup content

jjjpanda commented 2 months ago

⚠️ Please check that this feature request hasn't been suggested before.

[X] I searched previous Ideas in Discussions didn't find any similar feature requests.
[X] I searched previous Issues didn't find any similar feature requests.
[X] I am only requesting a single feature. Multiple changes should be split into individual requests, with links between them.
[X] I believe my requested feature will be generally applicable to other users, not just me: it is not uniquely tied to my personal workflow.

🔖 Feature description

Currently, the only way to select any content from the EditorSuggestorPopup is using the mouse or arrow key + ENTER. Many editors, especially IDEs allow both TAB or ENTER to select and auto-complete a suggested phrase. I believe a setting switch to allow this (and swallow TAB keypresses to not indent) should be implemented.

✔️ Solution

In EditorSuggestorPopup

 app.scope.register([], 'Tab', () => {
            const editor = this.context?.editor;
            if (editor) {
                editor.exec('indentMore');
                // Returning false triggers preventDefault
                // Should prevent double indent if tabs start to get passed through
                return false;
            }
            return true;
        });

This section is included to allow for indents during the EditorSuggest, with a boolean flag from the Settings object passed into the constructor of EditorSuggestorPopup, a line directly calling selectSuggestion() can be added to mimic the behavior of the ENTER key.

❓ Alternatives

No response

📝 Additional Context

No response

claremacrae commented 2 months ago

Hi, this is intentional, based on past feedback from users. With tasks in lists, it is much more likely to want TAB to indent than it is to select from the list. See:

https://github.com/obsidian-tasks-group/obsidian-tasks/issues/2187

I believe a setting switch to allow this (and swallow TAB keypresses to not indent) should be implemented.

Each extra option that we add to user settings adds complexity both for code-maintainers and for users, so the barrier to entry for new user settings is very high.

jjjpanda commented 2 months ago

Thank you for the quick response! I understand the concern with adding complexity here. Based on what's been described in #2187, #2183, and from the steps to reproduce in both of those issues:

press enter to create task 2. the dropdown appears (due date, etc.) for the task 2. press tab to try to nest task 2. Nothing happens. Press escapeor click the mouse to get rid of the dropdown. Now I can nest task 2 using tab.

Create a task Press enter Try to indent by pressing tab

It seems like the use case for indenting with TAB was being blocked by the immediate dropdown that appears as soon as enter is pressed. Would a feature like this be possible if the dropdown only appeared after typing a space and not at the start of a task? Or specifically for my case, maybe this feature could be only for dataview task formatting (where an explicit [-dataview inline is required for autosuggest).

claremacrae commented 2 months ago

Thank you for the quick response! I understand the concern with adding complexity here.

Thank you for your kind understanding.

It seems like the use case for indenting with TAB was being blocked by the immediate dropdown that appears as soon as enter is pressed.

Would a feature like this be possible if the dropdown only appeared after typing a space and not at the start of a task?

I don't understand what this is trying to change.

Or specifically for my case, maybe this feature could be only for dataview task formatting (where an explicit [-dataview inline is required for autosuggest).

Making the behaviour different depending on format is adding complexity in a different place, so definitely not of interest.

(This auto-suggest code is already complex because of differences in the two data formats, and I do not wish to make it more so.)

claremacrae commented 2 months ago

In view of this size of the backlog for this project, and the demotivating effect of a very long backlog on volunteer energy levels, I'm going through a slow process of reviewing tasks for things that are one or more of the following:

unlikely to be realistically achievable, from the design of the current code, and the planned future refactorings
not sufficiently high priority to a broad community of users, based on the feedback I receive from a variety of sources
do not fit the core purpose of the Tasks plugin
are better covered by a different plugin - to share the development and maintenance effort

So I'm marking this one as 'not planned'. This doesn't mean 'won't fix' - it means not likely to be done in the foreseeable future.

obsidian-tasks-group / obsidian-tasks