RFC: Multiple search engines #134

Open
opened 2020-03-04 17:41:51 +00:00 by sloum · 5 comments
Owner

It has been suggested by user natpen that having multiple search engines would be a good feature.

Enabling syntax like this:

:search [engine name] [query...]

To support this we would need to add a map for search engines and add some kind of command to add them. Set will not work since set is a key and value setter, but we need a key (search) and two values (name and url). That map would need to be parsed and stored in bobmadillo.ini

Another, perhaps simpler, option is allow compile time additions to search in a map. This lets users build search engines into Bombadillo, but not on the fly. The regular search would still behave as it currently does, but the ability to call a specific search engine would be added.

Do either of these routes sound like good additions that we would want to pursue?

It has been suggested by user `natpen` that having multiple search engines would be a good feature. Enabling syntax like this: ``` :search [engine name] [query...] ``` To support this we would need to add a map for search engines and add some kind of command to add them. Set will not work since set is a key and value setter, but we need a key (search) and two values (name and url). That map would need to be parsed and stored in bobmadillo.ini Another, perhaps simpler, option is allow _compile time_ additions to search in a map. This lets users build search engines into Bombadillo, but not on the fly. The regular search would still behave as it currently does, but the ability to call a specific search engine would be added. Do either of these routes sound like good additions that we would want to pursue?
sloum added the
non-urgent
question
labels 2020-03-04 17:41:51 +00:00
Collaborator

It's a good idea, as you note the hard part will be management of the different search options.

For me it feels like a better fit for bombadillo.ini, especially for shared servers where you are running whatever is installed. The defaults would still come from defaults.go.

When you say get and set would not work, does that mean you don't think they could be extended? Perhaps it could be included later, and options added directly to the ini.

It's a good idea, as you note the hard part will be management of the different search options. For me it feels like a better fit for bombadillo.ini, especially for shared servers where you are running whatever is installed. The defaults would still come from defaults.go. When you say get and set would not work, does that mean you don't think they could be extended? Perhaps it could be included later, and options added directly to the ini.
Author
Owner

It could definitely be extended, but it does relate to the underlying data model... which is a flat key value store. I definitely agree that the default search should be provided at compile and then users would add more search options that would end up in bombadillo.ini. I'm just not sure the best way to go about it.

A simple solution would be to have gosearch and gemsearch or the like. That could work within the existing structures. However, that arbitrarily enforces a protocol. We could add a secondary search as searchurl2 in the ini and ssearch (second search) as the command? That would be easy enough to set up and would at least give folks a few options that could be changed by them as needed.

I can see the convenience of multiple searches.... Looking at web browsers most do not allow for quick and on the fly changing of where your search that gets typed into the url bar goes (only in settings). That doesnt mean we have to follow suit of course, but it does set a precedent. My current workflow has been to just bookmark a search page and navigate to it, which will then query me for input. It has generally worked fine.

I'll keep thinking on this one.

It _could_ definitely be extended, but it does relate to the underlying data model... which is a flat key value store. I definitely agree that the default search should be provided at compile and then users would add more search options that would end up in bombadillo.ini. I'm just not sure the best way to go about it. A simple solution would be to have `gosearch` and `gemsearch` or the like. That could work within the existing structures. However, that arbitrarily enforces a protocol. We could add a secondary search as `searchurl2` in the ini and `ssearch` (second search) as the command? That would be easy enough to set up and would at least give folks a few options that could be changed by them as needed. I can see the convenience of multiple searches.... Looking at web browsers most do not allow for quick and on the fly changing of where your search that gets typed into the url bar goes (only in settings). That doesnt mean we have to follow suit of course, but it does set a precedent. My current workflow has been to just bookmark a search page and navigate to it, which will then query me for input. It has generally worked fine. I'll keep thinking on this one.
Collaborator

Using a bookmark is a great way to do this with existing functionality.

Using a bookmark is a great way to do this with existing functionality.
Author
Owner

Using a bookmark is a great way to do this with existing functionality.

I agree. I think I am going to close this in favor of that solution, unless you think it would be better to leave open?

I'd like to redo the website/gopher sometime soon and have a bigger focus on getting started and faq. I think I'd probably remove the devlog as well as it has been a pain to keep up. Either way though: a suggestion like using bookmarks to manage search is a good thing to include in an faq when the time comes.

> Using a bookmark is a great way to do this with existing functionality. I agree. I think I am going to close this in favor of that solution, unless you think it would be better to leave open? I'd like to redo the website/gopher sometime soon and have a bigger focus on getting started and faq. I think I'd probably remove the devlog as well as it has been a pain to keep up. Either way though: a suggestion like using bookmarks to manage search is a good thing to include in an faq when the time comes.
Collaborator

My comment was more about it being a great current-state workaround, but I feel like this would be a good addition longer term (like 3.0 maybe).

  • A requirement for multiple search engines seems to be a byproduct of supporting multiple protocols.
  • Refining this behaviour from a bookmark action to a search-specific action seems more correct and intuitive.
  • You can see similar functionality in Firefox which I find works well. I also like DDG's bang shortcuts.

With that said, I don't search often in Bombadillo and have only just seen the two gemini search engines. So maybe I don't know what I'm talking about!

My comment was more about it being a great current-state workaround, but I feel like this would be a good addition longer term (like 3.0 maybe). - A requirement for multiple search engines seems to be a byproduct of supporting multiple protocols. - Refining this behaviour from a bookmark action to a search-specific action seems more correct and intuitive. - You can see similar functionality in Firefox which I find works well. I also like DDG's bang shortcuts. With that said, I don't search often in Bombadillo and have only just seen the two gemini search engines. So maybe I don't know what I'm talking about!
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: sloum/bombadillo#134
No description provided.