[HN Gopher] XTerm: It's Better Than You Thought
___________________________________________________________________
XTerm: It's Better Than You Thought
Author : zdw
Score : 58 points
Date : 2021-01-11 17:57 UTC (4 hours ago)
(HTM) web link (aduros.com)
(TXT) w3m dump (aduros.com)
| ogogmad wrote:
| Does XTerm support unicode?
| sprash wrote:
| Obviously yes. But depending on your distribution or locale
| settings you might have to launch the uxterm[1] wrapper instead
| of xterm if it doesn't work out of the box.
|
| 1.: https://invisible-island.net/xterm/manpage/uxterm.html
| snvzz wrote:
| Yes. And it should be the default if you open an xterm today.
| bitwize wrote:
| Yeah, I'd say xterm is pretty freakin' awesome.
|
| While Hackernews was busy grooming their Alacritty setup and
| holding drag races between it, iTerm, and whatever bloated
| terminal Microsoft came up with to see which could cat a huge
| file the fastest, I've been just using xterm. xterm -- it's the
| standard terminal emulator.
|
| xterm:
|
| * actually emulates a terminal and passes a set of compliance
| tests to determine how VT-compatible a terminal is (other TEs
| emulate xterm, poorly)
|
| * is still compatible with bitmap fonts
|
| * has a reputation for being slower than other TEs, but that's
| only because by default it doesn't cheat and commits every screen
| update. Other TEs, in order to increase their chances of winning
| the drag race, will skip updates they think you won't see. This
| can be enabled via a command-line option or X resource in xterm,
| but makes xterm less compatible.
|
| * comes with every Linux or BSD distro and works fast on nearly
| any graphics adapter
| asguy wrote:
| For people interested in playing around with different terminal
| emulators, you'd do yourself a service trying kitty
| [https://github.com/kovidgoyal/kitty].
|
| It made my experience on high DPI screens far better. You can
| find it packaged up in the usual places (e.g. Debian).
| jasonjayr wrote:
| I've recently taken up alacritty (+ tmux), which is fast; nice,
| and scales on displays sensibly.
|
| I'd been using urxvt w/ a plugin for tabs for eons previously.
| I'be been mutating my tmux config to match the urxvt + screen
| binding I've been used to.
| dharmab wrote:
| I switched to kitty because it supports a killer feature I
| became accustomed to in iTerm- a keybind for "Open a new
| terminal in the same directory as the current terminal."
| markstos wrote:
| alacritty offers that as well.
| chrisseaton wrote:
| > Offloads rendering to the GPU
|
| I don't understand this - isn't all rendering on a typical
| macOS or Linux desktop done via the GPU?
| markstos wrote:
| I believe the software has to take advantage of the GPU. The
| `foot` terminal renders on the CPU instead of the GPU, but
| beats GPU-accelerated `alacritty` anyway due to other
| effiency hacks described on their Performance page:
|
| https://codeberg.org/dnkl/foot/wiki/Performance
| chrisseaton wrote:
| Hmm I think it's more the case that an application has to
| go out of its way to not render on the GPU. High level
| frameworks' basic rendering operations are, of course,
| always GPU accelerated. They'd be crazy not to be! It looks
| like Foot is rendering using CPU by talking directly to the
| compositor.
| AstroNoise58 wrote:
| There are various ways to take advantage of the GPU -- the
| so-called GPU-accelerated terminals contain bespoke OpenGL
| programs ("shaders") to do rendering on the GPU. Here's an
| interesting way of doing it:
| https://tomscii.sig7.se/2020/11/How-Zutty-works
| DonHopkins wrote:
| https://medium.com/@donhopkins/the-x-windows-disaster-128d39...
|
| The Nongraphical GUI
|
| XCalc After Several Resizings
|
| https://miro.medium.com/max/434/0*LIDAYbj5NRANRGl7.gif
|
| X was designed to run three programs: xterm, xload, and xclock.
| (The idea of a window manager was added as an afterthought, and
| it shows.) For the first few years of its development at MIT,
| these were, in fact, the only programs that ran under the window
| system. Notice that none of these program have any semblance of a
| graphical user interface (except xclock), only one of these
| programs implements anything in the way of cut-and-paste (and
| then, only a single data type is supported), and none of them
| requires a particularly sophisticated approach to color
| management. Is it any wonder, then, that these are all areas in
| which modern X falls down?
|
| Ten years later, most computers running X run just four programs:
| xterm, xload, xclock, and a window manager. And most xterm
| windows run Emacs! X has to be the most expensive way ever of
| popping up an Emacs window. It sure would have been much cheaper
| and easier to put terminal handling in the kernel where it
| belongs, rather than forcing people to purchase expensive
| bitmapped terminals to run character-based applications. On the
| other hand, then users wouldn't get all of those ugly fonts. It's
| a trade-off.
| mcguire wrote:
| Don, did you ever figure out the difference between a "client"
| and a "server"?
| SllX wrote:
| Here's a non-Medium version[1], since Medium is similarly but
| completely unrelatedly, a disaster.
|
| [1]http://www.art.net/~hopkins/Don/unix-
| haters/x-windows/disast...
| gnu8 wrote:
| The original UNIXUX site is very clever, but if the guy who
| actually wrote it is linking to Medium instead, I'm not sure
| if we can overrule him.
| SllX wrote:
| No one is getting overruled, you now have one additional
| choice of links to click on for the same material, free of
| charge.
| Steltek wrote:
| I use xterm because I'm too lazy to switch, I guess. It was never
| bad enough for me to switch and it's present virtually
| everywhere, so I don't need to bother installing my favorite
| niche term (kind of like sticking with bash when zsh was
| indisputably more awesome).
|
| To the best of my knowledge, one downside is the text rendering
| is synchronous. Read a character off the tty, try to display it
| on the screen. It's fine until you go and cat /dev/mem or
| something like that. Many GNOME-ish terminals use vte which drops
| frames if it can't keep up rendering.
|
| I also run into problems with bad display managers or DEs that
| don't load ~/.Xresources or ~/.Xdefaults (looking at you Debian
| gdm).
| bitwize wrote:
| > To the best of my knowledge, one downside is the text
| rendering is synchronous.
|
| I find this to be a feature, it's part of what makes xterm a
| terminal emulator.
|
| There's a speedhack in recent xterm that makes it behave more
| like libvte, but I forgot the incantation to enable it.
| jd3 wrote:
| Something that I noticed recently is that the latency/input lag
| feels lower in xterm compared to unicode-rxvt.
|
| I used urxvt from ~2011 until a couple of months ago and I have
| been really liking the speed and simplicity of xterm since then.
| markstos wrote:
| `xterm` lacks Wayland support-- a more secure alternative to X11.
|
| For a fast terminal with Wayland support, check out `alacritty`
| or foot:
|
| https://codeberg.org/dnkl/foot
|
| `foot` (foo terminal) benchmarks faster than alacritty and offers
| a client/server mode for even faster startup for new terminal
| windows.
| andrelaszlo wrote:
| What about xclock?
| MarkusWandel wrote:
| OMG UTF8! Next I suppose someone will show me how to disable
| those !@#%ing colour control codes that always make my text
| blink? I don't want colour. I don't want syntax highlighting. I
| just want my old-school terminal. Mind you I'll probably have to
| sacrifice my cherished 8x15bold font (still installable after all
| these years) if I really want to go UTF8.
| epilys wrote:
| You might be interested in https://no-color.org/ I implemented
| it for my mail client (listed on the website)
| dn3500 wrote:
| I set TERM=vt102 to get rid of the garish colors. You still get
| the basic colors, which can be useful sometimes.
| fanf2 wrote:
| You might like the showBlinkAsBold Xresources setting
| https://www.freebsd.org/cgi/man.cgi?query=xterm&apropos=0&se...
| BikiniPrince wrote:
| I do!
|
| I use the terminal everything and even my IDE.
|
| Give me all the fancy features and dream up more.
|
| Just actually support vt100 when it is needed and in sometimes
| worse situations.
|
| Our "serial" console solution is even worse then the old school
| days. God help us if we need to use it for more then the
| occasional evaluation.
| qnxub wrote:
| I've found the latency of Konsole to be phenomenally low. I can
| definitely tell the difference between Konsole and GTK-based
| terminals, but I can't really tell the difference between the
| latency of Konsole and XTerm.
| DonHopkins wrote:
| https://medium.com/@donhopkins/the-x-windows-disaster-128d39...
|
| Date: Wed 10 Apr 91 08:14:16 EDT
|
| From: Steve Strassmann <straz@media-lab.mit.edu>
|
| To: UNIX-HATERS
|
| Subject: the display from hell
|
| I have a "window system" on my unix box. You see, in the unix
| world, "system" means "a bunch of unrelated programs." But that's
| not what I want to talk about here today. I want to talk about
| overlay planes.
|
| My HP 9000/835 console has two 19" color monitors, and some
| extremely expensive Turbo SRX graphics hardware to drive them.
| You'd think that I could simply tell X windows that it has two
| displays, the left one and the right one, but that would be
| unthinkably simple. After all, if toys like Macintoshes can do
| this, unix has to make it much more difficult to prove how
| advanced it is.
|
| So, what I really have is two display devices, /dev/crt0 and
| /dev/crt1. No, sorry, I lied about that.
|
| You see, the Turbo SRX display has a graphics plane (with 24 bits
| per pixel) and an overlay plane (with 4 bits per pixel). The
| overlay plane is for things like, well, window systems, which
| need things like cursors, and the graphics plane is to draw 3D
| graphics. So I really need four devices:
|
| /dev/crt0 -- -- the graphics plane of the right monitor
|
| /dev/crt1 -- -- the graphics plane of the left monitor
|
| /dev/ocrt0 -- -- the overlay plane of the right monitor
|
| /dev/ocrt1 -- -- the overlay plane of the left monitor
|
| No, sorry, I lied about that.
|
| /dev/ocrt0 only gives you 3 out of the 4 overlay bits. The fourth
| bit is reserved exclusively for the private use of federal
| emergency relief teams in case of a national outbreak of Pixel
| Rot. If you want to live dangerously and under threat of FBI
| investigation, you can use /dev/o4crt0 and /dev/o4crt1 in order
| to really draw on the overlay planes. So, all you have to do is
| tell X windows to use these o4 overlays, and you can draw
| graphics on the graphics plane. No, sorry, I lied about that.
|
| X will not run in these 4 bit overlay planes. This is because I'm
| using Motif, which is so sophisticated it forces you to put a 1"
| thick border around each window in case your mouse is so
| worthless you can't hit anything you aim at, so you need widgets
| designed from the same style manual as the runway at Moscow
| International Airport. My program has a browser that actually
| uses different colors to distinguish different kinds of nodes.
| Unlike a PC Jr, however, this workstation with $150,000 worth of
| 28 bits-per-pixel supercharged display hardware cannot display
| more than 16 colors at a time. If you're using the Motif self-
| abuse kit, asking for the 17th color causes your program to crash
| horribly.
|
| So, thinks I to myself cleverly, I shall run X windows on the
| graphics plane. This means X will not use the overlay planes,
| which have special hardware for cursors. This also means I cannot
| use the super cool 3D graphics hardware either, because in order
| to draw a cube, I would have to "steal" the frame buffer from X,
| which is surly and uncooperative about that sort of thing. What
| it does give me, however, is a unique pleasure. The overlay plane
| is used for /dev/console, which means all console messages get
| printed in 10 Point Troglodyte Bold, superimposed in white over
| whatever else is on my screen, like for example, a demo that I
| may be happen to be giving at the time. Every time anyone in the
| lab prints to the printer attached to my machine, or NFS wets its
| pants with a timeout, or some file server threatens to go down in
| only 3 hours for scheduled maintenance, another message goes onto
| my screen like a court reporter with Turett's syndrome.
|
| The usual X commands for refreshing the screen are helpless to
| remove this incontinence, because X has no access to the overlay
| planes. I had to write a program in C to be invoked from some
| xterm window that does nothing but wipes up after the mess on the
| overlay planes. My super 3D graphics, then, runs only on
| /dev/crt1, and X windows runs only on /dev/crt0. Of course, this
| means I cannot move my mouse over to the 3d graphics display, but
| as the HP technical support person said "Why would you ever need
| to point to something that you've drawn in 3D?"
|
| Of course, HP claims X has a mode which allows you to run X in
| the overlay planes and "see through" to the graphics planes
| underneath. But of course, after 3 months of calls to HP
| technical support, we agreed that that doesn't actually work with
| my particular hardware configuration. You see, I have the top-of-
| the-line Turbo SRX model (not one, but two on a single
| workstation!), and they've only tested it on the simpler, less
| advanced configurations. When you've got a hip, forward-thinking
| software innovator like Hewlett-Packard, they think running X
| windows release 2 is pretty advanced.
| teddyh wrote:
| My absolutely essential XTerm settings: ! Convert
| Meta-x into "ESC x", not "o" XTerm.VT100.metaSendsEscape:
| true ! Allow HT (TAB) in paste; i.e. do not convert
| to space character XTerm*VT100.DisallowedPasteControls:
| BS,DEL,ESC ! Assume window titles are UTF-8 encoded
| XTerm.VT100.utf8Title: true
|
| (Add to your ~/.Xresources and/or ~/.Xdefaults file.)
| mixmastamyk wrote:
| It's decent and supports direct-color and all the obscure
| features of xterm of course, that others don't like querying and
| setting the color palette.
|
| It doesn't support most(any?) of the bleeding-edge sequences for
| hyperlinks and underline styling.
|
| It may have better input latency than xfce, but what are you
| running it on, a 486? Maybe for RPi, but--it has poor paint
| performance as well. It will flash if you try to do animation or
| scroll a complex screen. Bit of a toss up on the that front.
|
| Anyway I find it useful for testing terminal sequences, but it's
| a tough sell as a daily driver. Things like tabs and a proper
| scrollbar are a minimum for me.
| tutfbhuf wrote:
| > Things like tabs and a proper scrollbar are a minimum for me.
|
| I use xterm in tmux, no need for native scrollbar or tabs.
| mixmastamyk wrote:
| Do you mean the reverse? I'm using a number of applications,
| the terminal is but one. So, I find a consistent interface is
| desirable.
| sprash wrote:
| Further tips that might interest people:
|
| Xterm should support sixels out of the box but needs further
| configuration to make it work properly:
| XTerm*decTerminalID: 340 XTerm*numColorRegisters: 256
|
| If you want to scroll the content in alternate screens like less
| instead of the scrollback buffer with your scroll-wheel you have
| to enable: XTerm*alternateScroll: true
|
| If you want a subtle and less jarring visual terminal bell you
| can enable this option which flashes only the current line and
| not the whole screen: XTerm*visualBell: true
| XTerm*visualBellLine: true XTerm*visualBellDelay: 20
| dunham wrote:
| Many years ago, I was surprised to find out that XTerm can also
| emulate a vector-based tektronix terminal.
|
| The only application for it that I found was a previewer for
| TeX's dvi files that could render on the Tektronix terminal by
| drawing a lot of tiny horizontal lines.
| nickjj wrote:
| Here's a few other useful binds related to zooming out, in and
| resetting zoom: Ctrl <Key> minus: smaller-vt-
| font() \n\ Ctrl <Key> plus: larger-vt-font() \n\
| Ctrl <Key> 0: set-vt-font(d) \n\
|
| And 2 other config options to help reduce trailing spaces when
| selecting text: xterm*highlightSelection: true
| xterm*trimSelection: true
| zbuf wrote:
| Thanks for those trim settings, useful!
|
| I'll swap you for these. I don't want any automatic opening of
| URLs, but I do want to make it easier to copy-paste them:
| xterm*on3Clicks: regex [^ ''""()<>$+]* xterm*on4Clicks:
| line xterm*on5Clicks: group
| znpy wrote:
| All these Xorg/X11 problems people complain about... I honestly
| don't see them.
|
| I've been using Xorg in one form or another since 2005-2006 and
| frankly since we all got automatic configuration and said godbye
| to Xorg.conf it's been a very very pleasant experience.
|
| I've been using both nVidia and intel cards, 1/2/3 monitors (in
| various arrangement) and network stuff (ssh -X and similar), and
| a videogame from time to time.
|
| Even xterm, with the right fonts, it's a very nice setup. I
| almost can't see the difference between a gtk emacs window and an
| emacs session running in xterm-unicode with proper fonts and
| antialiasing.
|
| Xorg might not be "optimal", but it works very well for me and I
| won't be switching to anything else until a wayland or whatever
| reach feature parity (including but not limited to network
| transparency).
|
| Whatever,
| jhallenworld wrote:
| You can get a tabbed xterm this way (From stack exchange):
|
| Do sudo "apt-get install suckless-tools", then run this command
| to have a tabbed xterm: tabbed -c xterm -into &
|
| Press Ctrl+Shift+Enter to open a new tab and Ctrl+Q to close a
| tab. You'll find more info in the man page for tabbed.
| megous wrote:
| xterm is sadly very slow (you see line by line re-draw in
| midnight commander and things like that) on glamor/GPU
| accelerated Xorg server on all my ARM devices. I switched to st
| (https://st.suckless.org/) on my ARM devices, and while it has
| less features, it doesn't have this performance issue.
|
| I never figured why that is, other than it not being a CPU issue.
| mixmastamyk wrote:
| I believe it is not buffering draws, although have never
| checked the source.
|
| Edit: I found this at the arch wiki:
| Troubleshooting - Flickering on scroll
| Warning: Double buffering may cause non-bitmap fonts to render
| incorrectly. Rebuild xterm using ABS and include
| the --enable-double-buffer flag: ./configure
| --prefix=/usr \ ... --with-utempter \
| --enable-double-buffer
|
| Could be more friendly.
| megous wrote:
| Hmm, I confused xterm with urxvt.
| [deleted]
| aftbit wrote:
| How can I set an arbitrary background color? I want something
| like 0x1A1B1C as I have for alacritty.
| jhallenworld wrote:
| xterm -bg '#bebebe'
| cylinder714 wrote:
| xterm -bg \#1A1B1C -fg white
| [deleted]
| gumby wrote:
| > ...it turns out xterm has incredibly low input latency compared
| to modern terminals.
|
| This boggles my mind. What on earth does a windowed terminal need
| to do that should result in _any_ latency on a modern machine?
|
| We had full ANSI-addressible displays that ran faster than the
| eye could read over serial lines in the 1980s. What on earth
| additional does a terminal program do and why would I want that?
| UI_at_80x24 wrote:
| I use a mixed environment. My servers are FreeBSD, OpenBSD, and
| about 5 different linux distros.
|
| I can only get consistent screen output if I use Xterm. rxvt,
| Alcrtty (sp?), Konsole, Gnome Terminal and all others that I have
| tried mungle ncurses, and/or other screen decorations (like using
| ASCII +------+, or TAB/Space, "decorations").
|
| Even if I do get rxvt dialed in from one client, if I connect
| from a different workstation with a different client it's all a
| mess again.
|
| I know xterm is the slowest of the bunch, but it always works
| with minimal putzing.
| AstroNoise58 wrote:
| Most "modern" terminals are surprisingly buggy (for lack of a
| better word), that is, they do not conform to the VT100-series
| specs (and less documented, but well known quirks). Here's a
| look at some of them:
| https://tomscii.sig7.se/2020/12/A-totally-biased-comparison-...
___________________________________________________________________
(page generated 2021-01-11 22:03 UTC)