use a textarea in advanced-search-filter tab

[pmario]

This PR fixes [IDEA] Advanced Search Filter Tab Should Allow Multi-line Input #8193

Advanced Search Filter Tab

• This PR uses a textarea as the AdvancedSearch Filter tab input element, so multiline filter strings can be used.
• This will especially be convenient once we can have comments in filter strings.

Keyboard Widget

• It adds a new disable parameter to the keyboard-widget. Default: "no" for backwards compatibility
• It updates the documentation for the keyboard-widget

keyboard-driven-input Macro

• It sets the textarea to "autoHeight" and limits max-width and min-width to 80%, so users can only change the height
• It adds a disableUpDownCancel parameter to the macro, which allows the default textarea navigation
• If the keyboard widget is disabled the class="tc-disabled" is set to the DOM element for easier debugging and styling if needed
• It updates the macro docs.

Default Styles

• It adds tc-advanced-search-filter as a new class
• It sets the default width for all input elements to 80%, to allow longer input strings

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
tiddlywiki5	✅ Ready (Inspect)	Visit Preview	May 17, 2024 3:21pm

[Jermolene]

Hi @pmario thank you this is a worthwhile improvement. The appearance would be better if the icons were aligned with the top of the textarea, not the bottom.

As a side note, it's shocking to see how much code was needed. It would seem to be a consequence of the extremely invasive way that we implemented keyboard shortcuts for the tabs in advanced search. Its a shame we couldn't make the implementation entirely encapsulated within the tabs macro.

[pmario]

Yea, the keyboard-driven-input is a bit of a beast. But we need to be aware, that webpages usually use the tab-key to navigate input lists. Which I personally think was one of the biggest mistakes ever made in IT.

The biggest portion was the removal of the "cancel-actions" and the "input-accept-variant-actions", which where connected to the Esc- and Enter-Keys. Since we need them for text-area navigation, I did entirely remove that code.

Adding the disable parameter to the keyboard widget is something that we initially "forgot" for other elements too. See the button-widget. So it adds up here too.

The keyboard-driven-input is made to be used for all input elements that produce lists. So limiting it to tabs, IMO would be an issue. On the other hand, there should be some potential to simplify the code with the new v5.3.x syntax.

[pmario]

@Jermolene The icon position has been adjusted.

[Jermolene]

Thanks @pmario I still think this is a useful change, but I have a concern: I did not realise at first that this PR breaks the ability to navigate the advanced search filter tab results with the keyboard. This is a regression, and it seems it would be hard to avoid.

The complexity of this PR does make me question the value of the keyboard shortcut support in advanced search. The implementation is very messy, and complicates future improvements. The keyboard shortcuts for switching tabs seem particularly egregious because that should clearly be part of the tabs macro.

I'd like to have a rethink. One idea would be to add an entirely new tab to advanced search called something like "Tools", "Toolbox", "Manager" etc. that contains a developer-oriented console for working with filters. Besides the use of a textarea, it could also be the place for your idea of a means to set arbitrary variables that are available to the filter expression. Let's give it some more thought, I'm open to suggestions.

[pmario]

[...] I did not realise at first that this PR breaks the ability to navigate the advanced search filter tab results with the keyboard. This is a regression, and it seems it would be hard to avoid.

That's funny. For me it was a positive side effect.

I find it problematic, that cursor down changes the filter-input area. It's OK for the other inputs. Creating advanced filter strings (that work) is very difficult and loosing the input can be frustrating. While the filter, that created the list comes back with the first ESC. Hitting ESC again clears the input and the filter string is gone forever.

Anyway. I'll create a new PR, that implements the "disable" attribute for the keyboard widget, which imo should be independent from the multi-line input.

I'm OK with a new Tools tab that implements the multi-line input. If the keyboard widget can be disabled, it could also be a plugin.