Apart from all the other issues with this idea that others have mentioned, ¿ is a terrible operator to type unless you happen to use a Spanish keyboard layout or similar. Clearly § should be used instead for something, as that is inexplicably very easy to type on my Swedish keyboard. ¶, ¤ and € would also be good options. Why should we suffer using the USD sign when programming but not be able to use the Euro sign?
/s
My point is that people don't think enough about varying keyboard layouts when designing programming languages. Most programming languages are actually terrible on non-US keyboards. All the square and curly brackets for a start are under AltGr. Backticks (thanks markdown) are on a dead key, needing to press that followed by a space to prevent writing things like è.
Hm, I should design a programming language for international keyboards. Or at least for Swedish keyboards.
Bold of you to assume there's even a key for it. In the italian layout (on Windows) there's no key for neither ` nor ~, you have to type Alt + 96 or Alt + 126
ps: I hope that whatever will be the new const trait system it won't use ~const like the old one...
About keyboard yes, here there is several keyboards, is hard to do things when special symbols are not uniform across them, an option to handle it could be great, maybe a vscode option to replace custom symbols to the right ones, so we can use an easy key.
My conclusion is that we should use less special symbols. Stick to the few that are very common for the most common operations (*+-/% for arithmetic obviously, and those are common outside programming as well so likely exist on most layouts for latin alphabets, for other things I would need to do research, but "#'&()?!=<>;,.: are probably OK too?). Note that rust uses .await instead of a symbol even though that is common in async rust. I think that was a good choice.
The issue with your suggestion for mapping other symbols is that many ISO layouts have fewer such symbols, since we have as many keys as the US layout for example, but several of those keys are dedicated to other characters instead such as åäö (there goes three keys to three Swedish letters).
Start with Hakell's approach of allowing ⇒ instead of => and → instead of ->, add a bit of ≠/≤/≥ to make expressions better looking, with ∷ to make shorter TurboFish.
Then go for ≮ and ≯ (which are identical to ≥ and ≤ for Ord types, but different for floats),
Then start adding things which are easy to type of some keyboards, but not on others like already mentioned ¿ — and also ⌘.
That way there would be increasing pressure to add support for more symbols in Emacs or Neovim and, eventually, people would stop being limited to just ASCII.
That is a good idea, if you don't also need to write your native language. For me it is probably 50/50, making that a difficult decision.
I might try to figure out how make a custom one (which I presume will differ between X11 and Wayland unfortunately) that simply maps square and curly brackets and perhaps | (and I guess one more symbol) over ÅåÄäÖö. Leaving the rest of the Swedish layout untouched. That would be the most annoying and most common programming keys. I could also turn off dead keys in this layout.
Then I can just switch between that and normal Swedish depending on what I'm doing, hopefully with a shortcut.
Ask Greek or Russian guys about that. It's surprising how awfully various environments at doing that.
For some reason most “modern” OSes invent new and exciting ways to switch keyboard layout asynchronously by some “advanced” mechanism decoupled from normal way of delivering keypress events.
The end result: use MS-DOS, Windows 3.11 or early version of X11 — and everything works perfectly, employ “new”, “advanced” OS — and suffer regular situation where you think you have switched layout, but started typing too fast for computer to “notice” that and get garbled input. Why the heck is it so hard to include “layout changed” event in the same stream that other keyboard events come through? Heck, why the heck would one invent two (or more) mechanisms of switching layouts, invariably with one that is designed properly and “advanced” one that misbehaves. All desktop OSes that I know did that mistake: Windows 10, macOS, and in Linux GNOME/KDE.
Although I haven't tried new Wayland-based setups, perhaps they finally did that right there? I'm 99% pretty sure they would add and new, non-working one, later, if so, because every other setup went in that sequence: add something working (but not “advanced” enough), then add something else that makes people suffer…
Sorry about the rant, it's just one of pet peeves of me: why the heck everyone breaks that thing and then re-breaks it again and again? Why is it so hard to believe that even gigahertz-scale CPU may be too slow to cope with layout if you insisit on making changes to bazillion thing before “layout change happened” using JavaScript is acknoledged and makes it to the keyboard driver? Sigh.
Yep, § is just there, under Escape, on my Finnish keyboard.
I'm really hoping Rust does not get infected with all kinds of odd characters with obscure meanings. Makes code look like the random chars you get from transmission errors, hard work for my visual cortex to even recognise.
In Wayland events are always received in the order they are sent by the compositor even across different objects. Both the current keymap and pressed keys are received by the application as events after subscribing to any keyboard events using wl_seat.get_keyboard. So unless the application does something wrong, they should stay in sync. I haven't tried it though.
These are not the problem for all other OSes, too. What usually happens is that initial version hard-codes couple of ways to switch layout and them people ask for more thus someone have “bright” idea: hey, we already have this subsystem that handles global shortcuts (or it handles switches between virtual desktops or it may handle something else… the important part that it sits in that queue somewhere but not in the beginning) and they attach “keymap switch” duty to that component. At this point we have inherently flaky and unreliable system because there are queue and asynchrony between component that may decide to switch the keymap and component that attaches information about current keymap to the key event: it doesn't matter what that “intellectual” component is doing when I click Alt+Space or Shift+Shift (or any other combo I'm instructed to use), maybe it's busy interpreting JavaScript or maybe it's pushing commands into GPU — the end result is the same: for a few milliseconds (or even seconds if your system is busy under serious load) Alt+Space or Shift+Shift event is sitting in the keyboard queue while keyboard drivers continues to assign old layout to all the following events!
Of course when “intellectual” component is finally free to notice that there's something in the keyboard queue it's too late, some keypresses are already in the queue with wrong information about keymap and going into queue to fix that would be “layering violation”.
The keymap is handled by the applications themself on Wayland, not by the compositor or keyboard drivers. The wl_keyboard.key event only contains the physical keycode, which is basically the actual location on your keyboard where the key is located. It is the responsibility of the application (or generally the gui framework) to translate this keycode to a letter or other kind of logical key using the keymap that was passed by the compositor through the wl_keyboard.keymap event previously.
On Linux at least the keyboard driver doesn't know anything about keymaps. So whatever the root cause of this problem is on Linux, it has to be higher up the stack.
referring to your home directory isn't as required as you might think. i used plan9 for a while (which doesn't give ~ any special meaning), and you can get around pretty well dong cd; cd dir instead of cd ~/dir, i actually still mostly use this since it means you don't have to reach for the corner of your keyboard.
And who and how does guarantee that Alt+Space (or Shift+Shift, or whatever else was picked as combo that switches the keymaps) would be correctly processsed by something and would be able generate wl_keyboard.keymap event before the moment when keyboard driver would pick the next keypress to attach incorrect keymap information to it?
Who guarantees that “Здравствуй, мир.” entered as [З][д][р][а][в][с][т][в][у][й][Shift-shift][,][Shift-shift][м][и][р][Shift-shift][.] (with most of the text in Russian layout while comma and dot in English layout) wouldn't produce “Здравскуйю vирб” like many other “modern” systems tend to produce when they are slightly busy?
From your description (especially part or generally the gui framework part) is sounds as if we have another overengineered system ready to join the discussion about why it's “totally unreasonable” to expect that modern system with few gigahertz CPUs, fast buses and bazillion other things would be able to do what my first PC (too old to be even kept in school after decade of use there and only capable of running MS-DOS or Windows 3.x) did: make me able to use two layouts (mandatory in Russia, but also in Greece and Israel) without producing garbage.
I know how MS-DOS handled it because it was using that driver that I personally wrote in assembler (my first ever resident program lol… in an era where everyone else would play with 32bit OSes I was stuck with it) and which processes Right-Ctrl right there in the INT 9 handler. That guaranteed that even on that awful 4.77Mhz device I would never see that “Здравсвуйю vирб” text.
This also worked fine on early versions of Windows and early versions of GNOME, where Xkb was tasked with both attaching information about current keymap to the event and also was processing Shift+Shift or Right-Ctrl or whatever else was chosen to switch the layout.
I think that first to make my life miserable was KDE when it added some kind of daemon which was too slow to cope with me (and I'm not even super-fast typist!), then GNOME followed and Windows with macOS (on macOS only works in the way I explained while CapsLock switches reliably). I think Windows have finally added enough kludges to make it work reliably by Windows 11, but from what you are describing Wayland again went to the broken state.
i believe part of the problem may be in the fact that keymap switching (and especially input-method switching) is often not provided by the same program that is providing key events, and the program has no way of making the synthesized event replace the key event, basically it would need a way of locking the global event queue, which has the potential to deadlock the entire system.
In case the compositor handles it, it should be totally race free. It may depend on the desktop environment though who handles it.
Games expect physical keycodes. And while you can go from physical keycodes to logical keys using the right keymap, going the other way around is much harder. As such the application has to receive the physical keycode in the keyboard input event either way.
works in the way I explained while CapsLock switches reliably). I think Windows have finally added enough kludges to make it work reliably by Windows 11, but from what you are describing Wayland again went to the broken state.