Refactor proposal: move parser to a separate crate

[rszyma]

Changes I suggest to make:

• move parser code to a separate crate (similar to how it's done with keyberon)
• change conditional compilation (only regarding parser code) to runtime conditionals like if/else/match.

Reasoning:
Having the parser code in a separate crate will allow future tools like UI confgurator or even a LSP server to reuse the existing parser. I've personally stated interest in developing of such tools in #42 a while ago. This change could push forward #42.

[jtroo]

This seems like it should be reasonable enough to do since configuration parsing is fairly independent of runtime processing.

I don't have much knowledge about implementing LSP so I'm not sure what other interfaces would be needed for the parsing/config crate. I suppose it could just start off with the current interfaces that the rest of the kanata code uses which would be parsing a file to return the Cfg struct, and then more could be added over time.

[rszyma]

I suppose it could just start off with the current interfaces that the rest of the kanata code uses which would be parsing a file to return the Cfg struct, and then more could be added over time.

Makes sense.

Since you agreed, I'll start working on a PR.

[rszyma]

Or would you rather do it yourself? The amount of changes would be huge. I'm pretty sure that everything else besides src/kanata, src/main.rs and src/tcp_server.rs would need to be moved out of src to a separate dir, say parser.

change conditional compilation (only regarding parser code) to runtime conditionals like if/else/match

We could ignore this for now, as it only complicates things even more.

[rszyma]

Instead of just moving everything out, another possibility would be to alter parser code to add an intermediate tree representation that wouldn't be dependent of src/keys (which is dependent of src/oskbd).

To still have a validation of keys like the

kanata/src/keys/mod.rs

Lines 83 to 88 in 41878c5

	pub fn str_to_oscode(s: &str) -> Option<OsCode> {
	Some(match s {
	"grv" => OsCode::KEY_GRAVE,
	"1" => OsCode::KEY_1,
	"2" => OsCode::KEY_2,
	"3" => OsCode::KEY_3,

provides, instead of mapping key_str => OsCode, the parser crate could instead have mapping key_str => description_of_key (it would work as a documentation).

But that's only one of changes that would need to be made.

[jtroo]

Or would you rather do it yourself?

I don't have as much time+motivation to work on OSS these days so I wouldn't be able to make any promises for when it would get done.

Instead of just moving everything out, another possibility would be to alter parser code to add an intermediate tree representation that wouldn't be dependent of src/keys (which is dependent of src/oskbd).

As a first thought, it seems like it would require a lot of changes since currently all of the parsing functions return a keyberon Action. It does seem like a useful long-term change though.

(which is dependent of src/oskbd)

Ah good callout. I don't think this is necessary though, this part of the dependency should be removed in #466. I think the keys code could be moved out as well.

[gerhard-h]

so far config variables can not be changed during runtime, but maybe read-write variables become a thing in the future.
would that have influences on crate separation?

[rszyma]

Or would you rather do it yourself? The amount of changes would be huge

I don't have as much time+motivation to work on OSS these days so I wouldn't be able to make any promises for when it would get done.

I mean, just moving the parser as is to another crate shouldn't be much of a problem time-wise. I was trying to say that it would be PITA for you to review the changes if I did them, because git diff sadly can't show "renamed file X for Y" but rather treats renames as deleting a file and adding a completely different file. If you're okay with that, I can do the changes.

---

so far config variables can not be changed during runtime, but maybe read-write variables become a thing in the future.
would that have influences on crate separation?

Probably not. That's because the config parser is, just like jtroo said,

fairly independent of runtime processing

and writing variables would be done only in runtime. But this is only hypothetical, because there seems to be no good reason to have them in kanata.

[jtroo]

it would be PITA for you to review the changes if I did them, because git diff sadly can't show "renamed file X for Y"

One strategy to mitigate this is to have one commit in the history be moving the files as-is and then the rest of the commits are the actual changes.

[rszyma]

Okay, I can do that

[rszyma]

I was trying to say that it would be PITA for you to review the changes if I did them, because git diff sadly can't show "renamed file X for Y" but rather treats renames as deleting a file and adding a completely different file.

I just found out git mv command exists 😄