[Feature Request/Proposal] Adding support for custom, static "shortcuts" area.

[nathanmp]

First off, I love the extension, thanks for making it! Really helpful.

I want to make a suggestion - the place on the bottom that displays search tips is really great, and I'd love to use that area to add/change info I frequently need and want to remember. For instance, I have an extension that gives me a sidebar I use to manage my todo lists. There's a shortcut for it, but I don't often remember the shortcut and have to open it manually. It'd be great if there was an option to change the data on the bottom to a custom value. Maybe it'd be possible to set a custom number of columns too, to display a bit more data.

I'd love to do this myself, but I want to do it with the least risk of breaking custom CSS, so I want to run my proposal by you:

• In the options menu, adding a checkbox + textarea that allows for/sets custom data in the default style you use (treating the input as a csv: shortcut,descriptive text). Line with only 1 field = just display the text (it's not a shortcut to display). Blank line = "break" to a new div.
• options.js parses them and sets a value in browser.storage.local.
• Those divs can be added to the tip_container div in newTab.js after line 261. (i.e. after the translations are used.)

#tip_container > div elements are inline-block, so I don't think the default css needs any changes. Do you want me to make a PR, and if so is that way to handle it OK?

[clemzarch]

Thanks a lot. I'm glad to hear others are finding it useful.
Custom shortcut tips is not a feature I'd have thought of, but I like the idea.

the least risk of breaking custom CSS

It's got like 10 users if we include my mom, and maybe 10% of the users have custom CSS. I think they'll handle some back-compat breaks. If need be, better do it now than once it has 5 million users :^)

In the options menu, adding a checkbox + textarea that allows for/sets custom data in the default style you use (treating the input as a csv: shortcut,descriptive text). Line with only 1 field = just display the text (it's not a shortcut to display). Blank line = "break" to a new div.

Sounds good to me. maybe not the most user-friendly but it's straightforward. I'll think of some way to explain it on the page.

options.js parses them and sets a value in browser.storage.local.

Will parsing require an external library? I'd like to keep the code relatively simple. (although right now options.js looks a bit like yandev spaghetti)

Those divs can be added to the tip_container div in newTab.js after line 261. (i.e. after the translations are used.)

Maybe it would be better around line 39, right after we check if the tips are enabled by the user:

if (options.show_search_tips) {
	document.getElementById('tip_container').style.visibility = 'visible';
}

Do you want me to make a PR, and if so is that way to handle it OK?

Please go ahead, I'll handle the new strings and translations.

[clemzarch]

Be advised, I pushed some changes, if (options.show_search_tips)... is now at line 39.

[nathanmp]

Thank you! I'm sorry for the very late response. Apparently my Github emails were turned off, whoops.
I guess this format might make more sense for parsing:

[app_name]
keys explanation

• app_name (the name of the program they apply too) is used to break sections and for a header
• keys is shown in the code-style format currently used for search shortcuts
• spaces more than 2 characters is used to show the end of the shortcut and beginning of the description
• if there aren't any keys, custom text can be displayed anyway as long as it's preceded by 2+ spaces

That way people can (optionally) line the shortcuts up so it's easier to format them and edit.

Will parsing require an external library? I'd like to keep the code relatively simple. (although right now options.js looks a bit like yandev spaghetti)

I can understand options.js better than some of my old code! It definitely won't require another library. It should actually be easily doable with regexes for each line (only tested with an online regex tester, haven't coded it yet):

• check if the line is empty - remove newline, check the length, proceed if not 0
• /\([.+\])/ - checks for an app_name, gives the group if so
• /^(.+(?= ))?(.+)$/gm - this should give 2 groups. The first is the shortcut if it exists, else it's blank. The second is the description of the shortcut

Quick question before I start - should there be some upper bound on the number of shortcut "sets" users are allowed to make? It should probably have a maximum number of cells so it doesn't get too cramped. This is my idea for the replacement:

container div, holds up to (3,4,5?) sets of shortcuts

shortcut divs, side by side, vertically centered

Thanks, and sorry for the delay!

[clemzarch]

It's no problem really, you're offering help, neither of us have real obligations to it, and the project has no deadline to honor.

So basically the tips would look like this:

---

Search Bar
^ History * Bookmarks % Tabs @ Search engines
Browser
Ctrl+Shift+T Reopen closed tab Ctrl+Shift+T Private window Ctrl+Y Show history window

---

(with more space between the elements)

I think it's good this way. In fact that's what the shortcuts used to look like some versions ago because it's how most games present their button prompts.

should there be some upper bound on the number of shortcut "sets" users are allowed to make

Let's see how 5 looks like, but it will also depend on resolution/window size. I'd be in favor of letting people manage the sections how they please, if they really want to entirely fill their screen with shortcuts.

Also, I'm wondering if we should let them modify even the default tips. Maybe it's something they would appreciate, but there would probably be cases were someone deletes stuff they didn't mean to. If we do let them, I'll add a button to do a factory-reset of the options.