RFC: Multiple search engines
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'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 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
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.
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.
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!
Deleting a branch is permanent. It CANNOT be undone. Continue?