feat: longer texts or more helpful output

[Rolv-Apneseth]

Part

Executable (CLI)

Description

Hi, cool tool, thanks for making it.

I tried to use ltrs check data.json, where that JSON file is quite large, and this is the returned error:

thread 'tokio-runtime-worker' panicked at /home/rolv/.local/share/cargo/registry/src/index.crates.io-6f17d22bba15001f/reqwest-0.11.18/src/into_url.rs:80:14:
a parsed Url should always be a valid Uri: InvalidUri(TooLong)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at /usr/src/debug/languagetool-rust/languagetool-rust-2.1.4/src/lib/server.rs:433:47:
called `Result::unwrap()` on an `Err` value: JoinError::Panic(Id(17), ...)

Now, knowing nothing about this tool's internals or the languagetool API it uses, I assume that the text is being passed as a query parameter and hence the too long error.

Is it possible to either pass the text in the body of the request (if it's a GET request then I suppose not) or split up the request into multiple requests?

I realise those might be too annoying to implement, so some helpful error output would also be fine.

Screenshots

No response

Additional information

version: languagetool-rust 2.1.4

[jeertmans]

Hello @Rolv-Apneseth, thank you for your feature request!

A long time ago, I started to implement an automated splitting of the text, see here:

languagetool-rust/src/lib/cli.rs

Lines 120 to 129 in 05a1857

	if cmd.filenames.is_empty() {
	if request.text.is_none() && request.data.is_none() {
	let mut text = String::new();
	read_from_stdin(&mut stdout, &mut text)?;
	request = request.with_text(text);
	}
	let mut response = if request.text.is_some() {
	let requests = request.split(cmd.max_length, cmd.split_pattern.as_str());
	server_client.check_multiple_and_join(requests).await?

This implementation, however, only applies to input data passed as text (i.e., with ltrs check -t <TEXT>), no filenames or JSON data.

This project has two parts: the language tool API (which is mostly complete) and the CLI. The CLI is not very flexible, and I miss time to work on it. I'd be happy to review any PR from the community, but I am afraid I cannot work on this project as much as I would like to, at least for the moment. In #117, I started a refactor of the library, to hopefully make things simpler in the future, but haven't had enough time to finish :/

[Rolv-Apneseth]

Oh ok, cool. Well I'd be happy to invest some time if no one with more knowledge of the code base is available - what do you need done to finish up that PR so that this feature could be implemented in the future?

[jeertmans]

Thanks for offering your help! I have added a small description to #117.

I think the best is that you first read it, as well as the content of the PR (i.e., the diff), and maybe try to fork / clone / checkout this branch and test locally?

Please let me know if you need help, but I suggest we continue our discussion in #117.

[Rolv-Apneseth]

Thanks, the description is helpful. I'll move the discussion there if I have more questions.