In IME mode, event.start property is wrong in TEXTEDITING event in several conditions

[sunjunzero]

Pygame-CE version: 2.5.7
When input in IME mode, event.start will be wrongly set to len(event.text) in follow cases:

1. delete the first char in IME mode
   a)press same char in IME mode
   b)press left, let the start is 1
   c)press backspace to delete first char
   expected: new TEXTEDITING event with start 0 or -1
   actual: new TEXTEDITING event with len(text)
2. when the start is 1, press left
   a)press same char in IME mode
   b)press left, let the start is 1
   c)press left again
   expected: new TEXTEDITING event with start 0 or -1
   actual: new TEXTEDITING event with len(text)

Workarounds:
for case 1, the text in new event is shorter than previous event, so we can detect this case
for case 2, when text is more than 2 chars, when event.start switch from 1 to len(text), we can detect; but it there is only 2 chars typed in IME mode, we cannot detect it is pressing left or right.

[Fantastair]

I reported a similar bug in the official pygame repository two years ago (pygame issue 3968). The issue was caused by SDL and has since been fixed in SDL3 (SDL issue 7616). I'm not sure if it's the same as yours.

[sunjunzero]

I think it is the same issue.
Thank you for the quick response.

[oddbookworm]

Because this is an SDL issue, the options here are:

1. we try to backport whatever weird fix they did for SDL3 to SDL2 and compile our own
2. we live with this issue in SDL2-based pygame-ce and then it'll be fixed in SDL3-based pygame-ce

The problem with option (1) is that it would become a maintenance nightmare. Any time SDL releases a new version, we would have to recompile it ourselves with the new changes. Not to mention, we use dynamic linking to reduce the size of our wheels. That's not something we could easily mitigate for those on, say, linux with system-level SDL2/SDL3 w/sdl-compat without switching to static linkage. I don't think that's going to happen. Which leaves option (2)

We may be able to patch things in our internal event handling (maybe check for a keydown event at the same time), but I suspect that would be even more painful. It's probably easier to special-case in user code. I also don't see too many people using the TextEditing events, so I'm not sure it's worth the effort for us to fix for only a handful of projects. Also, we'd have to be very careful not to break anything else while we're at it. There's also a discussion I think to be had about whether this would be a change that might break someone's project out there.

[oddbookworm]

And one workaround user-side would be to look for a KEYDOWN event with either arrow key at the same time, or like, within a frame or so, depending on if SDL publishes them the same frame