Problems with Websearch Plugin

[NachtaktiverHalbaffe]

I saw the new websearch plugin, was excited and installed it. There I encountered two problems:

1. With the default configuration there are two tabs opened with each query:
   • One with right google search
   • One with the url "https://{query}"
   • The CLI also prints two times the exact same messaege that its opening something in the current browser session
2. I have trouble configuring a custom search engine or it doesnt work (See configuration below). Can you provide a working one and update the example configuration in the corresponding Readme which explains it a little better for users without Rust/RON experience?

   Config(
   prefix: "#",
   engines: [Google, Custom {
   name: "Searx"
   url: "searx.be/?q="
   }] 
   )

I hope we can get this resolved quickly like my last issue

[Kirottu]

Alright with the latest commit this stuff should be fixed, the example config was wrong and there were oversights in the plugin that I made.

[NachtaktiverHalbaffe]

Thanks, it improved alot and now the custom option is showing up. Still have one problem: When using the custom url, it doesnt open the right query. Instead it opens a window with the wrong adress (again "https://{query}", which is a fallback as far as I understood the code). With your example config this problem also occurs. I dont know Rust, so its hard to find the actual bug by myself

My updated config:

Config(
  prefix: "#",
  engines: [Custom(name: "Searx", url: "searx.garudalinux.org/?q={}",), Google] 
)

[Kirottu]

Does your updated config work? It could be that I messed the example up again.

[NachtaktiverHalbaffe]

The custom part now shows up with the right name in the runner, but opening doesn't seem to work (opening "https://{whatever the query is}"). Also with the newest commit the fist bug which i described in the original issue comment reappears.

Im using the AUR package to built, but I assume that the package should be up to date with the latest commit

[Kirottu]

Ok that's weird as it worked for me when I was testing it yesterday after making fixes, so I'll need to look into it more.

[Kirottu]

Alright after testing again, it seems to work fine for me with this config:

Config(
    prefix: "?",
    engines: [Google, Custom(
        name: "SearX",
        url: "searx.be/?q={}",
    )]
)

If it still doesn't work for you I am lost as to what is going on.

[NachtaktiverHalbaffe]

Sadly its still the same issue on my end. Also tried changing browsers ans same issue. At least google is kinda working at the moment.

Found follwing snippet;

#[handler]
fn handler(selection: Match, config: &Config) -> HandleResult {
    let engine = &config.engines[selection.id.unwrap() as usize];

    if let Err(why) = Command::new("sh")
        .arg("-c")
        .arg(format!(
            "xdg-open https://{}",
            engine
                .value()
                .replace("{}", &encode(&selection.title.to_string()))
        ))
        .spawn()
    {
        println!("Failed to perform websearch: {}", why);
    }

    HandleResult::Close
}

If I understood it correctly this part of the code it launches just a adress with https://{whatever the query is} as a fallback and only prints an error if also the fallback fails. So seems that fallback behaviour is kicking in on my place.

Maybe some debug logs before the fallback measurement takes place could help debugging on my end.

[Kirottu]

There is no fallback here, it takes the URL the engine provides and then replaces the placeholder, {}, with the encoded query.

[NachtaktiverHalbaffe]

Ah, interesting to know. But it seems that somwhere there the error must be. My thought on the symptons (from a non-rusty perspective):

1. When https://{whatever the query is} is opened in my case, I think "xdg-open https://{}" only inserts the query and not the the query into the url string and that into the xdg open string. So there must be some corner case where it fails to completly insert the string or skips the insertment into the url string and inserts the string directly in to the spawning pocess
2. When it opens two windows, the command "xdg-open https://{}" must be executed twice. Could be that for some reasons the whole handler functions calls twice or the command-spawner inside of it. This only happens
   • This happens with all preconigured engines, but not with the custom engine
   • Because the additional opened window has the same symptome as the before described symptom, coulf it be with the preconfigured engines that it also ifres the Custom engine additonallyfor some reason?

In general could it be that the {}-signs as a pattern for inserting the queries etc. could have some side-effects?

[Kirottu]

{} as the replaceable pattern should have no side effects, it's only "special" when in the context of a formatting macro, and formatting macros only accept literals. I really do not understand how it fails to substitute in the URL, as it works fine on my machines.

[abenz1267]

Works on my machine without issues as well.