I think I will take some flak for this ... but honestly, I've always preferred running Emacs in my terminal. Weird things like this always happen when a windowing system gets involved (and I suppose, window system support was kind of bolted on to Emacs, not designed in from version 0). I started using the terminal exclusively on Linux when gtk + emacs --daemon was known to cause frequent crashes. I carried this over to using Mac OS without really thinking about it. I currently use Mac OS for work and some days I use Emacs with a native windows and sometimes just use my terminal. (Kitty is a really nice terminal. KKP is supported in Emacs with a third-party package, and kitty can do things like display underlines, italic, bold, etc. I use Windows Terminal at home and it really sucks compared to Kitty.)
There are advantages to using a native window (display your method doc popups in formatted markdown instead of plain text), but they have never really made up for the jank, so I've never committed to it. I'm glad the author took a look, though.
Some Emacs bindings don't work in the terminal, a big example is `C-M-%` , `query-replace-regexp` https://stackoverflow.com/questions/71302860/emacs-terminal-... to do a regex find and replace.
Yeah, that is one of the main reasons I don't use emacs in a terminal much (the main exception being that I use emacsclient with -t for terminal mode as $EDITOR and for quick editing). Some key bindings just don't work properly.
Works fine for me. Is it your terminal configuration that needs tweaking?
The reason is listed at the bottom of the page: "You can't type C-M-% on the terminal is because C-% is not part of the standard control codes." This page lists the standard control codes https://en.wikipedia.org/wiki/C0_and_C1_control_codes (e.g., `^_`). There are only a few special characters that are recognized by a terminal with control (while all the letter keys are [although I think shift and lowercase are combined?]).
Everything is recognized with the meta, because meta just sends an escape sequence followed by the key code for the other characters.
With all that said, there are thousands of reasons it could be working for you "it's just software" so anything can be programmed, but I'm not aware of say a terminal spec that supports more control codes. Usually when this works it's because the user has implemented one of the many workarounds available online (e.g., change the terminal emulator to send a different key code, and change Emacs to use that key code for the command). It's also possible the terminal emulator you're using has custom support built-in specially for Emacs.
I could fix this myself if I wanted to, but I've just found it's better for my sanity to work with terminal emulators as a clear spec (which includes only the limited set of control character codes) rather than work against that. For an example of how much work this can be to maintain, this is fixing all the discrepancies I've found in Alacritty where it doesn't send the correct key code by default https://github.com/robenkleene/Dotfiles/blob/4d06e9855465c00... I mainly did that to make terminal Emacs usable in Alacritty.
With all that said, if you have another terminal emulator handy, I'd be super curious if it works with that one as well.
Regarding your last sentence, I don't know the answer. If you really want to find out I would make an educated guess that it is one of the more feature-rich modern terminal applications (like kitty, wezterm, alacritty, ghostty)
Oh it's also possible it's triggering `M-%` instead of `C-M-%`, `M-%` definitely usually works (just an escape sequence followed by percent character). `C-h k` followed by the binding will of course show what command is triggered, `M-%` is the non-regex variant `query-replace`.
It depends on what you're trying to use it for. If you just use Emacs for coding, you're not going to gain anything from running it in a GUI. However, if you also use it to read documentation, take notes, etc.; being able to display images, different fonts, different sized fonts, etc. is pretty nice.
>If you just use Emacs for coding, you're not going to gain anything from running it in a GUI.
That's true only if you think pointing devices are useless for editing and navigating code.
ADDED: I withdraw this comment.
Just a heads up, in 2025 the mouse and trackpad work incredibly well with TUI applications. There are days I think the mouse works even better than with GUI applications because it tends to be easier to select any text on the screen than with a GUI. To be clear, I love both (TUI & GUI), but when I started integrating the mouse more into my terminal workflow, I was shocked at how well it worked.
Can you move point to a position by clicking that position with a pointing device?
Also, when you've selected some text with the pointing device, does Emacs sense the selection? I.e., does (list (region-beginning) (region-end)) return the start and end of the selection?
Yes and yes, I don't think there are any mouse issues I've had working with Emacs in the terminal (whereas there are tons of bindings issues).
I had no idea! Wow.
What terminal are you using that doesn't support a mouse? Or is it emacs that doesn't have mouse support?
Before writing my comment, I started Emacs as `emacs -nw` in Gnome Terminal and failed to find a way to move point with my mouse. If there is any additional configuration I need to do to Emacs or a different terminal-emulating app I need to install, I'd be glad to learn about it.
I didn't mean to suggest that pointing devices are completely useless in a terminal, but it has always been my experience that what the device can do is severely limited compared to graphical Emacs.
Looking at my config quickly, I think you probably need this:
(xterm-mouse-mode 1)
Or simply upgrade to the top of tree version of Emacs that now has native mouse support in the terminal.
Native UI integrations are pretty nice. For example, native sharing/send-to was recently merged https://xenodium.com/emacs-send-to-aka-macos-sharing-merged-...
I made the opposite choice with Vim, opting to always use GVim instead of the terminal. I was never able to set up terminal colors and mouse compatibility just right, and at 4k Gnome terminal would lag a bit. Terminals use windowing systems too. :P
This was 10 years ago though, before Kitty and the new Windows Terminal.
Emacs in a terminal is the best.
The fact that Emacs is happy in the terminal is what keeps me in Emacs and away from GUI editors that come and go over the years - that and Emacs' longevity....
I started on vim and hopping back and forth between my editor and my terminal is just some muscle memory that I cannot break - so I too have always run emacs in the terminal ever since I made the switch.
I've been meaning to switch to GUI emacs for 15 years, I usually have it working, vterm is nifty... but it just works great in the terminal and with terminals getting SO FUCKING GREAT lately, eh, is it really an upgrade? WezTerm and ghostty on Wayland with no X jank? Accelerated, ligatures, mouse and keyboard clipboard integration, high-DPI...
Can GUI anything keep up?
With a font like "Input Sans" you can fit about +30% more code on the same screen unless you're too pixel starved. Terminal can't do non-monospace. And even if it's just that I want character width to scale slightly with font weight...