No, I don’t have Slack installed so I cannot confirm your behavior. However, as mentioned, in GNOME Text Editor the underlined “u” for inserting Unicode identifiers only appears when pressing the key binding as set up for the dconf key org.freedesktop.ibus.panel.emoji unicode-hotkey. That means that if I change the value to a non-default one, then the default value ('<Control><Shift>u') won’t trigger the Unicode entry mode. So it’s working as expected.
Hi @ytrium , it is already empty. This is the solution I’ve been adopting successfully since 2022, but for some unknown reason stopped working (for me) recently.
Guess it’s related to wayland, on Fedora 43, there’s no more x11 backend with Gnome 49.
On Debian 13, the ibus-setup works with gnome x11 session but not wayland.
I have cleared the hotkey and it works with the gnome-terminal with your solutions.
But the shortcut still exists and affects GUI applications based on GTK(evolution in my case).
Electronjs apps also use gtk if I get it right.
Yes, it is specific to Wayland. That bug report I mentioned before states this specifically. And the response from GNOME devs also affirm clearly there are no plans to make it customizable on Wayland:
Yes, gtk does not let you customize that.
…
I don’t want that key to be customizableIt has been Ctrl-Shift-u since before slack existed…
Regarding Slack (which I use at work), I filed a bug report there, but they also don’t seem too inclined to make it customizable.
That would be really inconvenient.
I didn’t see the shorcut in a KDE live image, iirc. so this might be still related to gtk.
Maybe this still be a problem with libgtk.
the codes are in gtk/gtkimcontextsimple.c around line 866, which belongs to libgtk-4.so file. Make a change and recompile libgtk-4.so/libgtk-3.so locally might do the trick.
I guess it work by putting the modified libgtk-4.so/libgtk-3.soin the~/.local/lib64/or/usr/local/lib64` ?
Even though it might work, it’s a burden that doesn’t pay off IMHO. I’d rather change my habits to work around this than keep patching GTK whenever a new version is released. In Slack it’s actually pretty easy: if you paste (ctrl+v) a URL while some text is selected, it automatically creates a link for you (which would otherwise require selecting the text and pressing ctrl+shift+u).
Totally agree with that.
But how does x11 session get ride of this issue? Is it done on the x11 side?
I did some work on recompiling the libgtk, I made a note at: onequid / gtk-shortcut-experiement · GitLab
Hope it would do a little bit help if anyone’s interested in working on the issue.
Maybe this was configurable on X11 and they just didn’t bother to change there since X11 is a dying breed. Anyway, considering the conversation on that gitlab issue, looks like GNOME devs will not accept a patch to make this specific key combo configurable, which would again lead to the uncomfortable alternative of locally patched versions 
Observed that there are no more unicode input in evolution and Ptyxis(terminal emulator) after removing the unicode shortcut via ibus-setup, both are developed by the gnome org.
Which means in a big chance it is still configurable with wayland-backend, though not sure with wayland or xwayland or .
I made some more tries based on this guess with VS Code, but didn’t manage to make it work. I also updated the note in the gitlab repo mentioned above.
So downstreams (Electron/VSCode/Chromiun in my case) might be able to do something to get over it.
Still believe a change should be made in gtk, even if it could be configured by downstreams, as ibus is probably needed as the default IM module, which could make things more complicated on other DE not based on gtk like KDE, LXQt etc.
Yes, it would be great if these downstreams you mentioned could somehow change it, if you manage to find a way to do it, please share with us 
Is there any way to remap keyboard input at Electron level so that it would translate another key combo to ctrl+shift+u before it reaches the wrapped app (eg. Slack)? Gemini suggests it might be doable using Electron’s --preload flag and providing a custom JavaScript wrapper that would do the translation, like this:
// inside a preload.js file
window.addEventListener('keydown', (e) => {
if (e.ctrlKey && e.shiftKey && e.code === 'KeyU') {
e.stopImmediatePropagation(); // Tell Slack to ignore this
// Trigger your alternative action here
}
}, true); // The "true" ensures we catch it during the capture phase
But, honestly, at least for Slack, the ctrl+v alternative seems good enough for me (YMMV).
With the following steps mainly, the Ctrl+Shift+u shortcut would not bother VS Code 1.111 in a wayland session.
# clean the unicode shortcut as metioned previously
ibus-setup
export GTK_IM_MODULE=ibus
code --ozone-platform=x11
Tested with Fedora 43 with gnome-shell 49.4
I’d take my words back as the xwayland works properly . gtk/ibus + wayland has the issue.
That could be indeed an option @onequid , but I wouldn’t want to increase my dependency on anything x11-related just to be able to use this (or any) specific shortcut. YMMV of course
As a side note, Slack app came up with a clever workaround: if you copy a link to the clipboard, select a text and press ctrl+v, it will automatically create a link; this is faster and more convenient than opening the insert link dialog, thus making ctrl+shift+u unnecessary. But then again, this is just one app, the problem still exists.