Unwrap operator

language design
21

NixOS might be a little niche :wink: But even with a system charmap I find myself often inputting emoji via some chat-native replacement like :wink:. Which actually kind of demonstrates the point, inputting emoji is important, so there are many convenient ways to do it. Inputting math is much less important, so beyond special plugins/setups/toolchains it becomes a chore. I think that with a little tooling a programming language can make it quite ergonomic (but outside of my dreams I don't necessarily think that language needs to be rust).

22

Compose key support is native in Xorg, https://wiki.archlinux.org/title/Xorg/Keyboard_configuration#Configuring_compose_key, and there's apparently a UI since KDE 5.18 https://www.omgubuntu.co.uk/2019/12/kde-plasma-5-18-makes-it-easier-to-type-emoji or GNOME 3.28 https://www.omgubuntu.co.uk/2018/06/use-emoji-linux-ubuntu-apps.

Same as Rust doesn't support EBCDIC, we don't need to support literally everything. Rust uses { which already needs AltGr on German keyboards; emoji are at least as accessible as that.

1 Like
23

While I can technically do it on my current Ubuntu/Gnome based laptop, it's extremely far from ergonomic...

  • hit hotkey
  • cursor goes into some edit mode where most keyboard inputs are captured
    • E.g. control-c doesn't work
  • then either...
    • hit spacebar to get menu
    • navigate menu with arrow keys and enter (or perhaps a mouse), or
    • start typing the name of the emoji if you know it and then use your arrows
    • hit enter when you've selected the one you want
  • or...
    • just start typing the name of the emoji if you know it
    • press space once to see a preview of what the first hit was [1]
      • press enter to accept, or
      • hit space again and you're in menu mode like above, or
      • hit backspace to go back to searching inline
  • or if I got here by accident and don't want an emoji, hammer ESC multiple times until it gives up
  • or hammer enter and get either some of the captured characters or maybe an emoji depending on what got captured
  • if I switch apps while in this edit mode, the other app inherits that state to some extent and I have to hammer ESC again to get a functional keyboard

And it also doesn't work in various apps (such as my browser), where the hotkey gets interpreted as something else. (Nor when I work in non-unicode terminals, not that I expect that to be a factor.)

It's not exactly the thing in the article you linked; there is no search bar for example. The article does say the one it is talking about doesn't work in non-GTK apps.

99% of the time when I need an emoji on not-mobile, I'm in a webapp or standalone app with native support, typically :name: based. The other 1% of the time I paste it from somewhere.

None of my coding environments have native support.

Incidentally, :exclamation: in particular always requires some amount of selection and not just a name, because there are apparently 28 emoji [2] related to "exclamation" (so far), based on the picker described above anyway.

  1. Sort of, it's previewed in text presentation mode, but may be pasted with an emoji presentation selector, which is what happens when I search "exclamation" and get :heavy_heart_exclamation: pasted despite a preview of :heavy_heart_exclamation: for example. Excited to see if the distinction survives normalization when I post this... ↩ī¸Ž

  2. a handful are variants based on presentation mode ↩ī¸Ž

2 Likes
24

(Clearly it didn't, those are both emoji presentation mode. As it's presenting to me anyway. [1])

  1. This post is bested viewed at my resolution in my browser on my computer as me. ↩ī¸Ž

25

Just in case, a few ideas of operators, basically prefix them with a dot: ".?" (could even replace the current "?") ".!" ".!?" etc.

Additionally, such operators could be used even as function calls, e.g., ".!" as alternative to .unwrap() and ".!("error message")" as alternative to .expect("error message").

These operators are also easier to search/grep.

3 Likes
26

Given the rather amazingly enormous breakage this has the potential to cause across the ecosystem, I'm pretty sure this won't happen.

27
28

.! looks good, and doesn't break compatibility. It'd just require IDE support.

let s = file.read_utf8().!("Err");
29

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.