Gnus in the Terminal (rendering)

At a general level, does anyone use gnus in their terminal? At a more specific level, has anyone experienced weird rendering issues with it (and does anyone know how to solve them)? Whenever I view an Inbox, it just jumps all over the place with entire rows showing up twice and text which had been present, but is no longer, sticking around. It makes things near unusable, unfortunately, and doesn't seem to matter which terminal I use. ​ https://preview.redd.it/f308gpswpmq91.png?width=1920&format=png&auto=webp&s=c600eae699e92eb84a9275c1f661836e1b0eb616 This is a small example; that third row is just displaying the one above it and even kept the line highlight from when I passed over it.

I've had this when using org-indent in the terminal. As a workaround, I change the size of the terminal and then change it back.

It works for the moment (kind of) but things go back to Hell, unfortunately, as soon as you go past the bottom of the buffer (since you need to fill the buffer with the new messages to look at). The interesting thing with using highlight line mode with this is the highlight line feature causes the entire row to be rerendered (rather than just the bits with text) but say you scroll through most of the buffer to render it properly – scrolling up causes rows to be rerendered with the wrong text they were displaying before you scrolled down.

It used to be the case that there were a large number of incompatible terminals. Each had a different way to encode commands such as cursor movements, color changes, and so on. No one programmer could ever hope to make their programs compatible with them all, so a database was created that contained all information needed to use a terminal. Instead of writing your program for one terminal, you would instead open up the database, read out the commands you needed to use for the current terminal, and then use those commands to implement your program. This database is called terminfo¹. Emacs does exactly that. It reads the value of the `TERM` variable from the environment and uses the value to find the right entry in the terminfo database. Your problem looks exactly like what happens when you have set your `TERM` variable to a value which is incompatible with the terminal that you are actually using. Usually you won’t notice any problems right away, because there has been enough consolidation in the terminal market that there aren’t as many differences between terminals any more. Most terminal emulators just do whatever xterm does, and xterm mostly does whatever a real VT-52/VT-100/VT-220/etc would do. Do any of your shell init files like ~/.bashrc or ~/.zshrc set `TERM` to anything? If so, comment that line out and restart your shell. Normally your terminal emulator will set `TERM` to the correct value before it starts your shell, so changing the value of `TERM` is usually a bad idea. On the other hand, it could be that your terminfo database is wrong. This can happen when you use a modern terminal like kitty or alacritty with an old terminfo database. Usually terminal emulators come with a file that you can compile into your terminfo database using a program called `tic`. However, if that were the case then Emacs would actually print an error message rather than start up (“emacs: Terminal type asdlfkj is not defined.”). You can use the `infocmp` program to query your terminfo database if you need to debug this kind of problem. ¹ Actually the first database was called termcap; terminfo came along later. It added additional features and has since superseded termcap.

Thanks for the advice! I just checked and I don't have `TERM` set, any. I typically use Kitty and that's set to `xterm-kitty` (by Kitty) but I also tried with Alacritty, Foot, and Urxvt and got the same result in all of them: otherwise perfect performance until I open Gnus (or Wanderlust, as well; I see the same result in that Summary buffer, too). You know, maybe it's the Emojis…; I was double checking things before I responded to you and noticed that Alacritty had a bit of a better time with things (though not perfect). I'm sure it's some kind of configuration thing but Alacritty doesn't display all of the Emojis and, for some of those it does show, it shows a simplified, black/white version. I scrolled down past all the subjects which had Emojis in them (well, I thought I had; I didn't realize, yet, some of them just weren't showing) and had a much easier time with things. It wasn't an exhaustive test but no issues with rendering. So then I retried Kitty and similar experience. Not all Emojis caused problems but, when I did run into problems, there was an Emoji on the screen. Scrolling down to a page which had no Emojis on the screen caused solid rendering, again.

Odd. If TERM is getting set correctly then you would expect better results. Also, emoji _shouldn’t_ mess up a working terminal emulator, but we all know that reality is messy. Maybe your terminal emulators are guessing the width of the emoji differently from Emacs? Both of them need to know whether a character will occupy 1, 2, or more character cells. You didn’t say what version of Emacs you are using, but if it is old enough then it might not know how wide the emoji are supposed to be.

Very true. Maybe? I don't think I did anything with my Emacs config. to mess around with fonts, any…; and not much of anything with my terminal settings others than the font to use (Fira Code) and font size. I'm running the latest Emacs, 28.1.