Inconsistent number of newlines produced by \n in key_sequence

[ChaiTRex]

Describe the bug
On X11, the number of newlines produced by the code below differs between GNOME Terminal 3.44.0 and gedit 41.0.

To Reproduce
The following code produces four newlines on GNOME Terminal and zero newlines on gedit:

Enigo::new().key_sequence("test\n\n\n\n");

The following code produces two newlines on GNOME Terminal and one newline on gedit:

Enigo::new().key_sequence("test\r\n");

Expected behavior
An \n in key_sequence should produce exactly one newline, regardless of application.

Environment (please complete the following information):

• OS: Linux (Pop!_OS 22.04)
• Rust: rustc 1.73.0 (cc66ad468 2023-10-03) and rustc 1.75.0-nightly (1c05d50c8 2023-10-21)
• Library: enigo 0.1.3
• X11: X.Org version: 1.21.1.4

[acrinklaw]

I did some debugging with xev and noticed that Enigo is using 0x0a for newline, while other libraries (like PyAutoGUI for example) use 0x0d for carriage return to simulate the newline when you call for it.

So it seems like an application specific interpretation of 0x0a, which seems to be the right behavior. But if you really wanted it to work as expected you'd have to force it to use 0x0d. VSCode / terminal are totally cool with 0x0a but Gedit/Kate/Libreoffice won't produce anything.

If you printf '\x0a' into a text file and open it with Gedit the newline doesn't appear but if you open it in vscode or with cat you see the new line. Not sure why this application specific interpretation is the way it is