This is kind of a problem in that it reduces the number of potential early users, testers and ultimately contributors. Sure it is still early in its development process, but it is important work to do in order to gain traction.
As a non-native English speaker who speaks 4 languages, I have almost never found myself using any other language than English in a code editor or IDE. And I never seen anyone who did, except for very occasional editing of localisation data files.
I have seen used (mainly in comments): Japanese, French, German, Dutch, Chinese (don't know if it was TC or SC; if those are even different unicode ranges or whether they are differentiated by font), and, if I remember correctly, Afrikaans. It's also kinda funny and a little off-putting to see English keywords side-by-side with, like, Dutch variable names.
Indeed, navigating keyboard internationalization is a rabbit hole within a time-sink. Luckily, in most cases, you can just plop in a library, and it works, but it's probably not that simple here. All the wtf edge cases, plus the quirks of different operating systems and hardware manufacturers—it's the stuff of nightmares.
An alternative way of looking at this: a text editor's main job is to turn keys pressed into characters to be inserted in the document and commands to be executed.
Keyboard handling is so fundamental that a text editor must deal with it, perfectly, from the beginning.
The cited issues aren't merely a severe and high impact bug cluster, but also an inexcusable design defect that disqualifies the whole project; I suppose someone decided to use Rust despite the lack of sufficiently mature input handling libraries.
> Keyboard handling is so fundamental that a text editor must deal with it, perfectly, from the beginning.
That would be nice but in reality it's such a tricky and subtle problem that nobody does it perfectly. All the operating systems and browsers are buggy in different ways, nevermind anything with smaller budgets. The deeper you get into proper text handling, the more you will realize that nobody has solved it.
Handling dead keys and displaying national characters is solved problem and has been since MS-DOS times. It's really not that "tricky and subtle problem" in 2023. Unless one is inventing keyboard handling from scratch again.
Dead keys are a drop in the ocean of what goes into international keyboard handling, and even that functions differently in every browser and OS. Which browser or OS do you think has it solved, or do you think that all of them are solved despite giving different results for the same sequence of presses?
Displaying text is an even deeper issue and also broken, the further you go from latin alphabets.
Referencing MS-DOS really takes the cake though. The Unicode standard wasn't even released until late 1991. They're still updating it even today, because it's a lot of work to handle international languages.
Perfection is unlikely, but serious developers should aim to be less buggy than the competition and/or limited by operating system and hardware shortcomings.
That's a very strong opinion about a project that is at 0.3 and is attending to many simultaneous problems, including building their own UI solution.
It's certainly an issue, especially for non-English users, but it doesn't "disqualify the whole project"; it just means that's not what they're prioritising at this time.
Prioritising glamorous and interesting aspects like plugins and "their own UI solution" over boring correctness is not the way to deliver a good text editor.
https://github.com/lapce/lapce/issues/2244
https://github.com/lapce/lapce/issues/1094
https://github.com/lapce/lapce/issues/1689
https://github.com/lapce/lapce/issues/2731