RFC: Multiple search engines #134
Labels
No Label
blocked
bug
build
documentation
duplicate
enhancement
finger
gemini
gopher
help wanted
http
in progress
invalid
local
needs-info
non-code
non-functional
non-urgent
question
release
rendering
suggestion
telnet
terminal
urgent
wontfix
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: sloum/bombadillo#134
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
It has been suggested by user
natpen
that having multiple search engines would be a good feature.Enabling syntax like this:
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
gosearch
andgemsearch
or the like. That could work within the existing structures. However, that arbitrarily enforces a protocol. We could add a secondary search assearchurl2
in the ini andssearch
(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).
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!