Keyword search

[InconsolableCellist]

@Jelmerro What do you think? It's parsing the Map every time you visit a URL, though I think the performance impact may be negligible. I didn't know where I could stick and fetch a Map object without just pulling the new String from the settings.

[Jelmerro]

Before I go into details about the implementation, I would recommend to check the contribute paragraph of the readme. The most important parts of that paragraph with regards to writing code, are the ones suggesting to use editorconfig and eslint. The eslint style guide clearly wasn't used while working on this, and as such I don't like the way the code is written currently.

I think a better name for this setting would be searchwords, but let me know what you think of this name. Besides that, I think we shouldn't implement this with some kind of JSON, but similar to other list-like settings with a value and a key. Examples of that are "containercolors", "redirects" and "permissionsallowed". They separate individual entries with a , so that you can append and remove entries easily, and each entry uses a ~ to separate the key and value. In your example: searchwords+=yt~https://www.youtube.com/results?search_query=%s.

[InconsolableCellist]

Alright, @Jelmerro, I updated it to use the string list and to pass eslint, so the style now seems consistent. I tried editorconfig and I believe it's passing, as I didn't see any complaints, but I'm not that familiar with that tool. My vim was already configured to indent with 4 spaces and use \LF, however, and there aren't any trailing whitespaces.

[Jelmerro]

My comment was mostly about the eslint style guide, I think there were no issues with editorconfig.

This is already much more consistent and it works well. There are just four small things I would like to change:

• No default entries, this is a breaking change, as it potentially breaks the workflow of people searching for that on DDG. You can just set the default value to an empty string and let people add these searchwords themselves, the current help docs contain enough info for people to figure it out.
• Can we highlight the navbar differently when a searchword will trigger instead of a regular web search? This way it doesn't come as a surprise when pressing enter. This becomes very important when people add a lot of these I think. You can also add an extra entry to the bullet points for the different categories in :h search. I was thinking of a color like purple or something by default (can of course be changed with colorschemes).
• The help for searchwords should come right after search, currently it's not. Please move it to the right place in the list of settings, they should be ordered alphabetically. You could also briefly mention that the color will change when a searchword triggers (as noted above).
• Finally, I am not sure if it makes sense to allow empty searches. Maybe it would be better to only trigger these searchwords if there is actually text behind them, and otherwise just do a regular search of just the word itself. This is another scenario where coloring the navbar for searchwords would help make clear when it activates.

Feel free to discuss these suggestions, this is just what makes sense to me.

[InconsolableCellist]

1. There's a default entry in settings.js in my commits above. Does it have to be somewhere else too? The default is for "yt"
2. I wasn't able to quickly figure out where I should make those changes. Where is that logic located? Would it change the text color, background color, or the color of the "Explore" word?
3. Oops, I forgot to reorder it after renaming it. Fixed
4. This is fixed now too

[Jelmerro]

I meant that I would prefer there to be no searchwords by default, not that you need to define them at other places too. It's confusing to suddenly introduce this without making it opt-in. Please just set it to an empty string in the defaultSettings and let users define these themselves.

I was talking about the border color of the navbar. As explained in :h search, the border color changes depending on what will happen when you press enter. It would be great if it would (for example) color purple when these searchwords will trigger. The code for that is here. And this also requires to define the colors in the default colorscheme here and here. If this is too complex, or you don't have time for this, I'll probably merge it anyway and add this myself.

[InconsolableCellist]

Good point about no keywords by default. I was figuring it'd be instructive to users, but there's really no point in forcing them to have a default, and the help explains how to use it.

I added a new style and set the bar to change colors (currently to #eee) when it detects a searchword.

I couldn't find a great way to avoid duplicating some code, now in isSearchword() in util.js:98 and actions.js:346. The only way I saw to solve it is something like a function that does "replace URL if URL is a Searchword/query pair (URL)", but that'd mean in suggest.js it'd have to check if the input and output to that function differ, and determine if it's a searchword from that. Alternatively, I could add a "isSearchword()" and "getSearchwordURL(URL)", but that would mean some duplicated code in util.js.

Ideally I'd want to return a touple, where the first element is True or False indicating if it's a searchword, and the second element is a key/value pair of the detected searchword and the replaced URL. You can probably do that with arrays in JS, but it just felt like it'd be a big departure from how this codebase does things, and isn't especially intuitive for future coders.

If you think those duplicated lines are a problem, or can think of a more elegant solution, let me know

[Jelmerro]

There are some small adjustments I want to make to the help and the appearance in the light colorscheme, but overall this seems ready to merge, thanks a lot for implementing this.

[InconsolableCellist]

Great, thanks!