(Idea) Reuse Search Bar For Custom Search Providers

Emilaia commented 3 years ago

I like homer a lot, and it is currently my "new tab" for any browser I use, but I just thought the only thing it lacked was a regular online search bar.

I was thinking it may be possible to reuse the current search bar that you can focus when pressing /, to also be used with custom search engines (some call these providers), so that it can easily be used for when you want to search something online.

Let me show you an example setup, followed by the specifics of how this could work.

Example Configuration

The configuration could be with a yaml, and be something like this:

providers:
   - name: "Google"
     prefix: "g"
     url: "https://www.google.com/search?q=<q>" #where <q> would be just a wildcard to replace the escaped query with.
     logo: "my-logo" # or "assets/my-icon.svg"
     target: "__blank" # optional

Example Execution

Now as to the specifics of how would could work, you first use / to focus into the search bar, and then you type out a provider prefix (for this example g), followed by a space, so the searchbar textbox at this stage has g(space) as its value.

Given how g matches the provider prefix for Google, the magnifying glass in the search bar changes to that provider's icon as confirmation you are going to search on that engine.

You type in your query, press enter, the query is converted, escaped and added to the configuration url, and you are redirected to the final search url.

Things To Consider

I understand this comes with the conflict of distinguishing an online search and entries search, and I originally wanted the keystroke flow to be / (search bar focus) + /<prefix><space><query>, basically the same as above, only that you click the / key twice, so that the textbox would end up with /g(space), but / won't be registered in the search box, as it's used to focus on it on the first place. But to be honest, if you type in something like g(space) and expected a single app or website, there's something odd with your configuration in the first place, so I don't think the g(space) idea is that flawed.
We are looking for exact prefix matches, so it could be possible to have g and gg as prefixes without conflict.
It is always possible to make this function for a separate search bar with optional auto focus.
Some people might want to control how the query is converted, let's say you want to convert <q> into <a>, <b> and <c>, and then have them return in the shape of: ?c=<c>&b=<b>&a=<a> (just for an extreme example). I could only think of this being solved with a custom script/script path option, but as the website it's static this'll be unlikely, and only leaves room for a target regex + a replace regex. Though I just mainly wanted to expose this edge case, a regular escape should work for almost everything.
You may have noticed there was a name field that went unused throughout the explanation, that's mainly because I only added it so that whoever is configuring the yaml can remember what it was for at a glance. However, dashboards like SUI, would use this name to provide a button that opens a modal listing all your options and their prefixes for in case you forget, so there is some potential application to it. But it isn't actually part of the core functionality, so you can simply ignore it if needed.

Don't know if this will eventually be considered for implementation or not, but regardless, thanks for giving it a look, and hope you have a nice day.

robinschneider commented 3 years ago

How about double press your hotkey and then have your google search? Would be easier to implement and also I would prefer to press my hotkey twice instead of the prefix.

Emilaia commented 3 years ago

How about double press your hotkey and then have your google search? Would be easier to implement and also I would prefer to press my hotkey twice instead of the prefix.

I think providing a way to bind your own keyboard shortcuts has the potential to complicate things, for the person that has to make it.

The specific idea you're proposing of double clicking a key isn't outrageous, but if more optional modules are added down the line, it could mean that you have to constantly toggle listening for hotkeys on and off. Like, if you were using the search bar to filter items, you wouldn't want that query to accidentally trigger a hotkey, those type of scenarios would need to be taken care of every time. And if you later want to add other modules/cells that could also benefit from hotkeys, now you'd have to check for conflicts for that as well. So enabling custom hotkeys in general, not specifically for this module, could lead to maintenance hell.

If the end goal is to type in an online search query fast, the best would be to have a selectable default search provider, so without typing a keyword, you could search on Google by default for example. And if on top of that you allow for this new bar to be optionally auto focusable, every time you open a new tab, you could immediately just type your google query, no focus command, no keyword.

So the least conflictive way to go about it, would be a new bar that everyone can pick if they want or not, that everyone can pick of they want to auto focus to or not, with a default search engine of their choice, that should still let you type / if you want to switch to filter search with the other bar.

But the reason I didn't propose this from the get go, was just to reuse what was already there, as I don't know how much of a hazzle would be to add a new module from 0.

Just wanted to wait for the dev to give their point of view eventually.

CourteousCoder commented 2 years ago

How about double press your hotkey and then have your google search? Would be easier to implement and also I would prefer to press my hotkey twice instead of the prefix.

I think providing a way to bind your own keyboard shortcuts has the potential to complicate things, for the person that has to make it.

If I may, I would like to suggest something that might solve both problems.

Currently the proposed key flow is

Hotkey to focus search bar (i.e. /)
The / character. Llet's call this the "leader"
The defined prefix (i.e. g)
The space character ( ) Let's call this the "delimiter".
The search query

It appears that once the search bar is focused, the / acts as a leader for the "prefix" and the space character acts as a delimiter from the search query.

What if we instead allow for configuring these values and allow a default? For clarity, I am going to rename the term "prefix" to be "key" and deem that all text that comes before the search query shall be called the "prefix".

I tried to be very thorough in keeping this well-defined.

Examples

The originally proposed behavior could be achieved with:

search:
  leader: "/"
  delimiter: " " # space character
  providers:
    - name: "Google"
      key: "g"
      url: "https://www.google.com/search?q=<q>" #where <q> would be just a wildcard to replace the escaped query with.
      logo: "my-logo" # or "assets/my-icon.svg"
      target: "__blank" # optional

But if you want to double-press "/" (hotkey) for google, then you can do something like this:

search:
  leader: "" # empty string means do not use a leader. Regular app-searching will be disabled, and you will need to add it as a provider if you want to search apps.
  delimiter: "" # empty string means that all text after "leader" that will be parsed as a provider key until it equals the last matching provider in the order listed below. If none match or if no providers are defined and both "leader" and "delimiter" are empty, then all searching is disabled.
  providers:
    - name: "Homer Search"
      key: "" # empty string guarantees it will match if nothing else defined earlier matches
      url: "https://homer-demo.netlify.app/?search=<q>" # this is the url to your own homer instance because "leader" is empty.
    - name: "Google"
      key: "/"
      url: "https://www.google.com/search?q=<q>" #where <q> would be just a wildcard to replace the escaped query with.
      logo: "my-logo" # or "assets/my-icon.svg"
      target: "__blank" # optional

This might be more robust than necessary but at least it covers as many custom use cases as possible I think.

AfricanHipp0 commented 2 years ago

Hey @Emilaia and @DanielSchetritt were either of you able to get this to work? I can't seem to get it to not use default search, which then prevents the trigger to use google

bastienwirtz / homer