Allow customization of search result display. Example: [title] ([vault_name])
Current search results shows on each line:
[categoryicon] [vaulticon] [title]
It would be lovely if there were a feature that would allow users to customize the search result display using a simple bracket syntax using pre-defined allowable variables. For example, I would like my search results to display as:
[vaultname]: [categoryicon] [title]
or:
[categoryicon] [title][NEWLINE][vaulticon] [vaultname] ([lastedited])
or:
[categoryicon] [title,50] ([vaultname])... where ",50" indicates truncate to 50 characters.
I could explain my use case... but invariably users will want customization options. Using bracket syntax, or a drag and drop interface to select available variables, would add a lot of flexibility and works very well in my experience. It would be important for customizations to be platform specific as mobile UI is more constrained than desktop UI.
A simple implementation would look something like:
1) Identify which existing variables Proton would like to allow in search results.
2) Identify which formatting mechanisms Proton would like to allow. Ex. newline, truncate, etc...
3) Publish syntax and list of variables+formatting options to a website. This could be an advanced feature
4) Add "Advanced > Customize Search Result Display Format"
4.1) Show a text input (or text area) with a "Verify Syntax" button
4.2) Clicking "Verify Syntax" would use regex to locate all suspected-variables found between brackets, loop through the list, and ensure validity. For example, [title] would pass whereas [thisisnotavalidpredefinedvariable] would fail.
5) When search results are displayed use the user-defined format instead of the default one. Simple regex + replace.
Implementing this way is much more flexible than the existing hardcoded way. It should allow users to customize to fit their specific device (phone, tablet, desktop). If you add new features in the future, for example a tagging mechanism, it is easy to add a new allowable variable [tags]. Note that documentation would need to be version specific as [tags] might be an allowable variable in v2.3.0 but not v2.2.0.
Implementing this would close a number of exiting open feature requests and likely reduce the number of future search result feature requests to a minimum.