[HN Gopher] I just wanted Emacs to look nice - Using 24-bit colo...
___________________________________________________________________
I just wanted Emacs to look nice - Using 24-bit color in terminals
Author : signa11
Score : 350 points
Date : 2024-01-30 13:32 UTC (9 hours ago)
(HTM) web link (chadaustin.me)
(TXT) w3m dump (chadaustin.me)
| ggm wrote:
| I run emacs with minimal colour, so will probably never use this
| but I very much enjoyed the read. I'm rather used to the garish
| green of tmux and a small amount of rusty red brown from the
| amounts of emacs colour left in my life.
| vardump wrote:
| Just discovered today standard ANSI escape sequences work on
| Windows 10 command prompt. Even 24-bit color works fine!
|
| Try (not possible to copy paste, see [1]): echo
| ^[[48;2;255;0;0mHello^[[0m
|
| Hello is printed with a red (RGB(255,0,0)) background. "^[[0m"
| resets back to normal colors.
|
| [1]: You can type ^[ (escape) by pressing CTRL-'['. Don't type ^
| and [ as separate chars, that won't work.
| teddyh wrote:
| Just don't forget to add DEVICE=C:\DOS\ANSI.SYS
|
| to your C:\CONFIG.SYS file.
| bloopernova wrote:
| Digging around in terminfo is like holding a flickering, flaming
| torch up to some hieroglyphics in some deep catacomb. It's weird
| to think just how much complexity goes into a terminal
| application. Makes me even more grateful to the devs behind iTerm
| and Kitty (and all the others!)
|
| EDIT: for iTerm+zsh, I collected some functions for setting tab
| colors:
| https://gist.github.com/aclarknexient/84ebe33c1879f921685304...
|
| EDIT2: Contrast terminfo with the old-school method of connecting
| to HTTP or SMTP with telnet. Yeah, it's simple text but that text
| is being displayed by a complex application that supports all
| sorts of wild stuff!
| vidarh wrote:
| I use my own terminal, and early made the decision not to give
| a shit about terminfo, pretend to be rxvt, and deal with the
| fallout (now, admittedly, the only user I care about for my
| terminal is me - at least for now). Modern terminals supports
| enough of a shared subset that it's less painful doing that
| than having to deal with applications get all confused because
| they don't recognize your TERM variable, to the point where
| I've typically found the closest match whenever I've used a
| less common terminal in the past too. (This matters less if you
| don't regularly ssh into new systems, of course)
| bloopernova wrote:
| That's fascinating! Did you have a specific itch you wanted
| to scratch by writing your own terminal? Or was it a learning
| project that you found useful?
| vidarh wrote:
| A combination of a procrastination project, wanting a pure
| Ruby library I can use for output from hybrid applications
| (e.g. my editor) to be able to have a mostly terminal UI
| but being able to add in _limited_ graphics when available,
| and wanting a testbed for other terminal changes I want to
| experiment with in terms of creating more of a hybrid UI.
|
| A basic terminal can be fairly small - mine is ~1800 lines
| of Ruby at the moment, which I consider disappointingly
| large. For comparison st is ~8k lines, I think, and xterm
| is ~88k. But you can do a working terminal in far less than
| my 1800, even in more verbose languages, so it's a nice
| space to play in where you can get something that works in
| very little (set TERM to a dumber terminal than rxvt, dump
| any escape sequences your terminal doesn't yet understand
| to a log, and run the apps you need, then iterate...), and
| build up in whichever direction you want to something quite
| usable very quickly. Then you can spend a lifetime
| polishing quirky little details nobody with you will ever
| care about... ;)
| kps wrote:
| > pretend to be rxvt, and deal with the fallout (now,
| admittedly, the only user I care about for my terminal is me
| - at least for now
|
| It's fine when it's just you. Unfortunately, there are some
| widely used terminals that default to claiming to be xterm,
| but are _not_ xterm compatible.
| vidarh wrote:
| Frankly, I find most work well enough with xterm or rxvt
| termcaps to prefer that over having apps just refuse to
| even try to work until you've changed settings.
|
| But conversely, if distributed like that, I'd also feel
| that this implicitly means any failure to act like xterm is
| a bug they've implicitly suggested it is reasonable to
| report or complain about (and if the _version number_ doesn
| 't imply it's an early stage release, and it still doesn't
| work well with its defaults, I'd get cranky)
| tambourine_man wrote:
| I'd like to know more of the motivations for building your
| own terminal. Are you using a library or written all from
| scratch?
| vidarh wrote:
| See a lengthier reply elsewhere in this thread, re:
| motivations etc. but it's almost all from scratch. Frankly,
| a simple terminal is not a huge amount of work, and you can
| get something working "well enough" to start with with very
| little code.
|
| The huge amount of work comes from nailing all the quirks
| you will have to deal with if you let a bunch of other
| users loose on it, with their expectations of running all
| kinds of applications I've never tested that does weird
| stuff.
| tambourine_man wrote:
| Yeah, the last 10%. I saw your reply after posting mine,
| thanks.
| JoshTriplett wrote:
| Absolutely agreed. The main problem with that is providing
| new features that xterm doesn't support, but terminfo pretty
| much refuses to add new features anyway, so modern terminals
| have had to work around that with some combination of
| autodetection, separate environment variables, or YOLO
| approaches. So, at this point, I'm not sure it's worth
| supporting terminfo at all for most applications, either as a
| terminal emulator or as a CLI program. (The article makes a
| similar point about the negative value terminfo is providing
| for modern applications.)
|
| If you're building a program that takes over the terminal
| screen, you probably should use one of the established
| libraries that abstracts over terminfo and over old non-ANSI
| Windows consoles. But if you're doing light terminal handling
| in an application that doesn't take over the screen, such as
| emitting colors or doing simple cursor control, forget about
| terminfo and just handle two or three cases: ANSI,
| _optionally_ old pre-ANSI Windows consoles, and files
| /terminals with no support for anything. Rounding ancient
| terminals or terminal emulators to "no support" and giving
| them the same thing you'd give a redirection to a file seems
| entirely reasonable for a new program.
| electroly wrote:
| I suspect the author would have had a better time had they known
| to do "export COLORTERM=truecolor". This is mentioned in a
| footnote in the linked Emacs document about detecting truecolor
| support, and it appears in their Konsole screenshot, but I
| suspect it got lost inside their layers of terminal multiplexers
| (as, I find, it often does). It lets you skip past all this hard
| stuff straight to the part where the app understands that you
| want true color. A terminfo database isn't even required.
| bhaak wrote:
| Indeed. Going down the terminfo road lies madness only.
|
| This is partly due to the maintainer of ncurses being somewhat
| ... conservative and the new fangled terminal devs wanna move
| things fast.
| Sjonny wrote:
| COLORTERM is also a very weird thing. Most of the time I don't
| need it to be defined, but when using a screen session it
| suddenly looks very crappy when COLORTERM is set to truecolor.
| Removing the env var makes it look all normal again.
| bhaak wrote:
| Does your screen even support 24bit colors?
|
| If unsetting COLORTERM fixes the display problem then it is a
| program issuing 24bit colors but the terminal (in your case
| screen) not understanding the escape sequences.
| spudlyo wrote:
| Tmux supports 24-bit color. I bit the bullet and switched a
| few years ago, and my muscle memory remains exactly the same.
| I'm incredibly happy with the power, flexibility,
| configurability, and reliability of Tmux.
| Paul-Craft wrote:
| Alternatively, just use your favorite GUI Emacs with either
| `tramp` or `sshfs`.
| spudlyo wrote:
| > A terminfo database isn't even required.
|
| As of Emacs 28. You still need the terminfo database in older
| versions of Emacs.
| chadaustin wrote:
| You're right: I should have included COLORTERM in this history,
| and a couple of the other fits and starts, like the `RGB`
| terminfo capability.
|
| The issue I had with COLORTERM is that not every program
| respects it. In fact, I've had this in my .bashrc for a while:
| case $TERM in linux | screen*) unset
| COLORTERM ;; *) export
| COLORTERM=truecolor ;; esac
|
| (Screen does support 24-bit color now, so that case probably
| came from Ubuntu 18.)
| csdvrx wrote:
| Agreed - COLORTERM has its own problem. I prefer your
| approach, it looks very sound!
|
| A fork of terminfo may be needed if the description of modern
| terminal capabilities can't be added -- or if old and
| deprecated attributes repurposed for that job (like in your
| padding example): if you're automating the
| correction/creation of terminfos in ~/, IMHO, it may be
| better to piggyback on tic as much as possible.
|
| Anyway, to backport modern terminal descriptions to legacy
| programs, creating correct binary terminfos in ~/.terminfo
| seems the best practice. You can also invent new TERM. When I
| wanted to have italics etc about everywhere, personally
| that's just what I did for sixel-tmux:
| https://github.com/csdvrx/sixel-tmux/?tab=readme-ov-
| file#ste... : just declare a new $TERM you know to be right,
| and use that in the apps that let you use a little logic in
| their configuration file
|
| I do that in my .vimrc: " If Vim doesn't
| know the escape codes to switch to italic let
| &t_ZH="\e[3m" let &t_ZR="\e[23m" " Italics
| pseudo-auto toggle: force italics if we recognize it's
| supported from TERM if match($TERM, "xterm-256color-
| italic")==0 highlight Comment cterm=italic
| endif
|
| BTW you should package your emacs config file with the emacs
| APE from https://cosmo.zip/pub/cosmos/bin/emacs to do a
| cuteemacs, to carry your config files and everything in a
| portable binary: https://github.com/csdvrx/CuteVim
|
| Another idea: have you considered that the "program that
| would be run by .bashrc" to generate the "unambiguous 24-bit
| color capabilities" could set environment variables to
| communicate them? Like, if you can't stuff them in terminfo,
| stuff them in environment variables! Env var work well on
| Windows, and the configuration files of terminal programs
| could just use these when available to override.
|
| It's be like adding friends to your proposed TERMVERSION:
| TERMSETF24 etc where you've have a finer control than
| COLORTERM
| okasaki wrote:
| One of the most frustrating things about terminal Emacs is
| figuring out how to get nice colors in tmux. By the time I get it
| working finally, I have no idea which combination of the tens of
| things I did made it work.
| ParetoOptimal wrote:
| What features aside from session persistence do you use tmux
| for? I partially moved to emacs because I was annoyed with
| tmux/screen.
| okasaki wrote:
| Windows, panes, a nice bar with the time, scrolling.
| NoThisIsMe wrote:
| You can get all of that with just Emacs tho
| okasaki wrote:
| I guess but tmux is installed on every system I connect
| to, and emacs is not.
|
| Some systems only have ancient versions of emacs
| available in repos, limiting packages I could install.
| mksybr wrote:
| You don't need emacs on the other end to get those
| features, connect over SSH with TRAMP.
| dmm wrote:
| I really want to use TRAMP. Basic editing works but I had
| a lot of trouble getting lsp based programming modes,
| like rustic, working.
|
| Maybe I should try again. Terminal mode works but
| requires a lot of workarounds and copy/paste integration
| isn't perfect.
| sph wrote:
| The best thing about Emacs compared to vim/neovim is that it has
| first-class GUI support that's not simply a terminal emulator in
| a window.
|
| I know about gVim and hundreds of half-baked neovim frontends,
| but the default way of running emacs is through a bonafide GUI,
| and I love that.
|
| Terminals are alright, but they have too much historic cruft and
| limitations that actually do not make any sense in this day and
| age.
|
| If your issue is running Emacs on a remote server, there's TRAMP
| and emacsclient (does it work over TCP?)
| hazebooth wrote:
| this 10,000,000,000%!! (dr stone ref.) I love modal editing and
| vim a ton, but I couldn't stand the half baked solutions
| terminal editors gave me. We have an entire rich graphical
| platform, why not use it?
| smohare wrote:
| This depends heavily on your workflow. For example I use vim
| almost exclusively for editing files, and drop back into the
| shell to use external tools (e.g., git, linters, formatters,
| debuggers, file tree manipulation, etc.) So my terminal
| emulator is already the main application. For this workflow the
| lack of a dedicated GUI is almost immaterial.
| drivers99 wrote:
| The great thing about running everything in a terminal is you
| can copy anything that is shown in the terminal. Frustrating
| when a GUI app won't let you copy some text it's showing and
| you have to retype it somewhere else by hand
| NoThisIsMe wrote:
| This is not an issue with Emacs though, GUI or otherwise,
| because everything's just a buffer
| jimmaswell wrote:
| Many dialogs that look uncopyable actually support ctrl-c,
| sometimes even giving some funny ascii art of the buttons.
| anthk wrote:
| Emacs allows to copy anything into anything.
| TylerE wrote:
| _Pasting_ into a terminal is such a minefield, though.
|
| On net I'm not sure it's an improvement. Being a pure
| ncurses-esque console app limits the richness of what you're
| able to display. Native controls and dialogs are in fact a
| good thing and not a cardinal sin.
| hollerith wrote:
| I want to make sure that people understand that you do not _have_
| to use a terminal to interact with Emacs: instead, you can use
| one of Emacs 's "graphical" front ends for MacOS, Windows, X.org
| or Wayland.
|
| Visually, graphical Emacs looks so much like Emacs running in a
| terminal that if the tool bar has been turned off (and most users
| decide to turn it off) most non-users of Emacs will assume
| (incorrectly) that a graphical Emacs window they see running on a
| colleague's computer is a terminal window (unless perhaps the
| window is currently displaying an image). (Graphical Emacs is an
| image viewer among other things.)
|
| In a survey of Emacs users, 80% said that they use one of the
| graphical front ends.
| s1gnp0st wrote:
| Right. There's also the sophomorically named "TRAMP" for
| connecting from a locally hosted emacs session to files across
| a wide range of protocols including ssh.
| spudlyo wrote:
| TRAMP also exhibits a wide range of performance problems.
| Getting it not to hang the display of the buffer list or lock
| up Emacs completely for minutes at a time requires a deep
| dive in to a decade of Stack Overflow breadcrumbs. I've done
| this, and I'm still not completely satisfied with the
| performance. I do however love the concept.
| db48x wrote:
| No, it requires only one thing: turn on persistent SSH
| connections. This means that new SSH connections to the
| same server do not actually require opening a new TCP
| connection, do not require negotiating new session keys,
| and do not require additional authentication. To turn this
| on, add these settings to your ~/.ssh/config file:
| ControlMaster auto ControlPersist yes
| ControlPath ~/.ssh/control/%C
|
| You should also use key-based authentication so that TRAMP
| never has to ask for a password, but this is less important
| once you are using persistent connections. Add something
| like this to your ssh config: Host orod-
| na-thon Hostname 192.168.2.133 User db48x
| IdentityFile ~/.ssh/id_ed25519_your_private_key
|
| Now go to Emacs and open up /ssh:orod-na-
| thon:~/.ssh/authorized_keys. This is the TRAMP path for
| your authorized_keys file on the machine named orod-na-
| thon. It will ask you for your password. Paste in your
| public key (which you can get by opening up the .pub file
| that goes alongside the private key in ~/ssh), and save it.
| Now future connections to orod-na-thon will be able to
| authenticate automatically using this key pair, and there
| will be no password prompt when you open a file there.
| spudlyo wrote:
| Yes, that's great, and it makes things extremely snappy
| while the socket connection remains open. Sleep your
| computer overnight, experience some network stormy
| weather, leave Emacs buffers open for weeks (as one does)
| and eventually one of those ControlMaster sockets are
| going to become wedged, and when that happens you're
| going to go through some things.
| db48x wrote:
| If that happens and you don't want to suffer through the
| default 30-second (or whatever it is) timeout, then
| shorten it. Add `ConnectTimeout 5` to your config.
| spudlyo wrote:
| Good idea fine tuning the timeouts. I took your
| suggestion and dropped the SSH ConnectTimeout to 5, I was
| still using the default. I also peeked at the Tramp
| timeouts, and I realized that I had the variable as
| tramp-connect-timeout and not tramp-connection-timeout.
| Thanks!
| cycomanic wrote:
| One problem that I looked briefly into, but have not
| found a solution is that often I'm browsing the file
| system (in a terminal) on the remote box and want to open
| up a file in a certain location (often just for a quick
| edit). The process of typing pwd, and copying the
| location into emacs (similar applies to Neovim) already
| is too much friction, that it's easier to just open the
| barebones Vim on the remote.
|
| Anyone aware of a solution of how to start the local
| editor from the remote to open the remote file?
| db48x wrote:
| Best solution to that is to use Eshell. Run `M-x eshell`
| to open the shell inside Emacs (on your local machine),
| then type `cd /ssh:orod-na-thon:path/to/files`. This will
| transparently ssh to the server and change to the path to
| your files. The `ls` command will now show the files that
| exist on the remote server rather than the local
| computer. You might now expect that there would be an
| eshell command that you could type to open a remote file
| in your local Emacs, but there isn't.
|
| No, in Emacs you always open a file by typing `C-x C-f`.
| (Unless you rebound it to some other key, in which case
| make the obvious substitution.)
|
| Any time you hit `C-x C-f` to open a file it defaults to
| opening files from the working directory of the current
| buffer. The working directory of the eshell buffer is on
| the remote server, so the default list of files that you
| see are all the ones you were already looking at with
| `ls`. You can start typing a filename and autocomplete
| will do the rest.
|
| This is an even deeper and more convenient composition of
| the shell and the editor than having special commands for
| tasks like opening a remote file in the local editor.
| Paul-Craft wrote:
| `vterm` beats the crap out of `eshell` as a functional
| terminal, unless you've put a lot of effort into
| customizing it.
|
| https://www.masteringemacs.org/article/running-shells-in-
| ema...
| chrisfinazzo wrote:
| Counterpoint: If you want a terminal w/o the bloat of a full
| GUI, but still _most_ of the advantages, `xterm-mouse-mode`
| will get you 80% of the way there: (require
| 'mouse) (xterm-mouse-mode t) (mouse-wheel-mode
| t) (setq mouse-wheel-scroll-amount '(1 ((shift) . 1)))
| ;; scroll one line at a time (setq mouse-wheel-
| progressive-speed nil) ;; don't accelerate scrolling
| (setq mouse-wheel-follow-mouse 't) ;; scroll window under mouse
| (setq scroll-step 1) ;; scroll smoothly
|
| Also, I should point out that I use `(setq auto-save-default
| nil)` - as God intended.
| charcircuit wrote:
| >w/o the bloat of a full GUI,
|
| People are going to be using Emacs with a monitor. It's more
| bloat to have to have a GUI application that emulates a
| terminal and then run Emacs inside that emulator instead of
| just having Emacs be the GUI itself.
| db48x wrote:
| "without the bloat of a gui"? Aren't you missing the fact
| that the terminal emulator is itself a gui?
| globular-toast wrote:
| Good point. I never considered that people might think I run
| Emacs in a terminal. Graphical Emacs is a lot better, but it's
| still great that 90% of stuff works and looks the same in a
| terminal.
| eej71 wrote:
| I've always drifted back to the terminal based emacs for two
| reasons.
|
| While I've been using X11 off and on since the 90s, I still do
| not understand how to deal with fonts beyond helplessly
| googling for a constructive command I eventually stumble on
| something that works and then I have to leave it alone.
|
| The display performance of most terminal programs is still
| noticeably faster than the X11 setup I end up with in a
| corporate environment.
| cmrdporcupine wrote:
| The font stuff is 50x better than it used to be and there's
| even a reasonable font selector built right into the GUI with
| the "Set Default Font" in the context menu (ctrl-right-
| click). And then you can "save" that from the GUI and get a
| line like this in your .emacs: '(default ((t
| (:family "FantasqueSansM Nerd Font Mono" :foundry "PfEd"
| :slant normal :weight regular :height 98 :width normal)))))
|
| Which emacs knows how to modify, too.
| ataylor284_ wrote:
| I don't run emacs in a terminal emulator. Emacs _is_ my
| terminal emulator. All my terminal programs get run in a
| (graphical) emacs shell-mode buffer. The rare program that
| needs full screen control uses term-mode.
|
| It's not the most featureful or fastest terminal emulator, but
| I can jump around the buffer like any other buffer and
| seamlessly access it along with the other content I'm editing.
|
| On a remote computer where I can't run a graphical emacs, I
| either remotely edit files via tramp, or run a headless emacs
| server process and connect remotely with a graphical
| emacsclient.
| hollerith wrote:
| I do that, too, for the reason you describe, except instead
| of shell mode, I use a mode I wrote myself.
| radarsat1 wrote:
| I also use emacs graphically, somehow I managed to switch
| after years of using it in the terminal and now I prefer it.
| However, I've never managed to settle on any of the terminal
| emulation modes. Just too many keyboard shortcut conflicts
| and complicated magic to remember how to copy and paste
| between different types of buffers.
|
| These days I've pretty much settled on having and emacs
| window and GNOME Terminal side by side as my two main work
| windows, and it's pretty comfortable. I like that I can mouse
| select and copy from the terminal window and then C-y into
| emacs and vice versa.
|
| If I really have some need I might still open a shell or
| ansi-term session but it's pretty rare now. Sometimes it's
| convenient when I find myself in a remote shell session and
| want to have a text editor and shell vertically tiled, I'll
| just run emacs with ansiterm because for the life of me I
| can't ever remember the screen keyboard shortcuts for
| splitting windows.
| m463 wrote:
| I agree. I use X based emacs and the protocol is efficient. The
| experience seems as lightweight as using a terminal, and NOT
| like using VNC or similar.
|
| advantages include fonts (even different ones at the same
| time), menus, mouse, colors, multiple frames/windows, and
| more...
|
| You can also run the graphics locally use tramp to access
| remote systems. I can edit config files on a remote linux-based
| router which basically has busybox, with all the bells and
| whistles.
|
| a much better experience.
| barrkel wrote:
| I found it easier to tune the 16 color palette in each of my
| various terminal apps than to try and get application-side
| terminal codes just right.
|
| In my ~/.Xdefaults for rxvt-unicode: ! yellow
| Rxvt*color3:rgb:F5/79/00 ! magenta
| Rxvt*color5:rgb:AD/7F/A8 ! cyan
| Rxvt*color6:rgb:88/8A/85 ! white
| Rxvt*color7:rgb:BA/BD/B6 ! ...
|
| And in my custom theme .el: (if (display-
| graphic-p) (setq color-yellow "#f57900"
| color-bright-yellow "#fce94f" color-red
| "#ff6464" color-bright-red "#ef2929"
| ... color-cyan "#888a85") (setq
| color-black "black" color-white "white"
| ... color-bright-magenta "brightmagenta"))
|
| I then use these to set various faces
| `(minibuffer-prompt ((t (:foreground ,color-blue))))
| `(highlight ((t (:background ,color-bright-yellow))))
| `(region ((t (:background ,color-bright-blue))))
| `(shadow ((t (:foreground ,color-bright-cyan))))
| `(secondary-selection ((t (:background ,color-bright-
| magenta))))
|
| etc.
|
| As a bonus, colored `ls` output etc. is nicer too. The raw 16
| color palette is too saturated and often has bad contrast.
| loeg wrote:
| Yep. I just tune the 16-color palette in Terminology (it's an
| INI file) to my preferred theme for the same styling in the
| console and terminal applications (vim).
| jszymborski wrote:
| Yah, I do pretty much the same thing. The default colours are
| far too dark for the dark background, so I just increase the
| luminance of all the colours.
| rollcat wrote:
| > (if (display-graphic-p)
|
| This right here. Emacs actually supports graphical output (X11,
| Cocoa, Win32). Additional bonuses include: Esc is actually Esc;
| you can bind Ctrl+Shift or Cmd; you can use more than one font
| at a time; you can display a picture; change the shape of the
| cursor... It's like a time machine that takes you 20 years
| forward - into 1989.
| barrkel wrote:
| There is, however, considerable upside in having all the same
| key bindings whether you're in local UI (maybe using tramp)
| or ssh to a remote server. Tramp has limitations and is a bit
| clunky so I use it rarely.
|
| Clipboard integration and mouse cursor support are the two
| reasons I generally break out emacs-ui (my shell script for
| it), otherwise it's emacs-nox, generally.
| ryan-c wrote:
| `ls` actually supports 24 bit color if you put the sequences in
| DIRCOLORS
| moyix wrote:
| My guess is that widespread 24-bit support in terminal apps is
| still held back by the fact that the macOS terminal _still_ doesn
| 't support it. As far as I can tell nearly everything else does
| :(
| lxgr wrote:
| Is that really a good reason to not support it?
|
| It seems possible to offer graceful degradation for non-
| supporting terminals, and I'd be surprised if the number of
| Terminal.app users that would even notice the difference would
| be that high:
|
| Surely everybody who cares about a good terminal experience
| uses some third-party client already? Then again, maybe I'm
| underestimating managed/corporate devices that don't allow
| third-party terminal emulators, since they do have quite
| critical access in the end.
| moyix wrote:
| It's the default, which means it has a _lot_ of people use
| it. And IME the alternatives on mac aren 't very good.
| electroly wrote:
| > Surely everybody who cares about a good terminal experience
| uses some third-party client already?
|
| Unclear. The built-in Terminal app is pretty good otherwise,
| and true color isn't necessary for a lot (most?) of common
| terminal usage. It's not so poor that all command line users
| would definitely have a third party app.
| bhaak wrote:
| If you are not using iTerm2 on macOS, it's your own fault.
| moyix wrote:
| Tried it. Slow, uses lots of memory.
| mattigames wrote:
| Yeah, that's my experience as well, I find ConEmu on
| Windows to also be a bit slow.
| __alexs wrote:
| > The first edition of ECMA-48 is lost to time,
|
| Apparently there is a copy in Germany
| https://search.worldcat.org/title/1069189730
| worksonmine wrote:
| Interesting, as a Vim user I'm surprised Emacs doesn't have
| better theme support. I always assumed it had everything. In
| modern Vim there's even hex support.
| rlonstein wrote:
| I'm not sure why you say that.
| https://www.gnu.org/software/emacs/manual/html_node/emacs/Cu...
| and https://emacsthemes.com/ exists.
| matheusmoreira wrote:
| That timeline is very enlightening and those references are
| extremely useful. Must have taken a lot of time to find and make
| sense of all that material. I'm especially thankful for the
| explanation of terminfo files.
|
| > We used semicolon (like other SGR parameters) for separating
| the R/G/B values in the escape sequence, since a copy of ITU
| T.416 (ISO-8613-6) which presumably clarified the use of colon
| for this feature was costly.
|
| Non-free standards are self-defeating. What's the point of the
| standard if the people who need them to implement stuff can't
| read them?
| volemo wrote:
| I get that the post is about terminal witchcraft, but regarding
| the Emacs part I believe you, author, ought to look into TRAMP
| mode.
| psanford wrote:
| I tried using kitty recently. Its really neat, until you try to
| sshing somewhere. If the remote system doesn't have kitty in its
| terminfo, nothing works. Kitty's "solution" to this is to use a
| custom ssh wrapper, which I'm sorry, is not an acceptable
| solution. A simple solution would be to let users override what
| TERM gets set to, but they refuse to allow this on some moral
| ground.
|
| Maybe I'll try it again in a few years when its in more terminfo
| packages.
| IshKebab wrote:
| Yeah that's silly. TERM is as broken as web user-agents. You
| just have to accept that and `export TERM='xterm-compatible,
| like xterm-256color, like gnome-terminal'` or whatever :-D
| jrockway wrote:
| I just type 'export TERM=xterm' whenever I log onto one of
| these systems (I use tmux-direct as my $TERM). It seems like
| Debian 12 has a lot of newer terminfos these days in the
| default install, and I've tried to upgrade most places I ssh to
| that. Like our CI system can take a Docker image as the place
| where your code runs; so instead of using the default one from
| 2018 or whatever, I just made my own that has all these
| niceties.
|
| (I use kitty on Mac and Windows Terminal on Windows, but it
| ends up not mattering because I'm always in tmux, so that's the
| terminfo that remote machines need. I never bothered setting up
| 24 bit color though, so I have no idea if that would work with
| my setup. I switched to TERM=tmux-direct to get italic fonts in
| Emacs running on Linux inside tmux inside an SSH session from
| Windows Terminal. It works!)
| db48x wrote:
| Why not just install Kitty's terminfo file on the remote
| server? This is quick and easy to do, and only needs to be done
| once.
| vulcan01 wrote:
| That is what kitty's "custom SSH wrapper" does, if I
| understand correctly. Each time you ssh into a server, it
| will copy kitty's terminfo file if it doesn't already exist.
|
| I use the ssh kitten, it works fine.
| db48x wrote:
| Oh, that's nice. I don't see why anyone would be against
| using that.
| spudlyo wrote:
| Servers in workplaces are often ephemeral. It's easy enough
| to write provisioning code that updates the system terminfo
| database, but it needs to be written, tested, reviewed, and
| deployed. Speaking of deploys, how are your Q1 OKRs shaping
| up?
| shirro wrote:
| The distros I use (debian, arch) have a kitty-terminfo package.
| First thing I install when I ssh into a machine. My terminal
| settings just work and I don't have to do archeology on decades
| of obscure terminal escape sequences.
| jimmaswell wrote:
| Really shameful that they lock away _standards_ under such high
| prices that people have to go to such lengths to not buy them,
| with potential results like this. If it 's a standard it should
| be available. It maybe made sense to charge a _printing_ fee back
| when they were only available as books but I can 't believe a
| crappy pdf was $200.
| medo-bear wrote:
| Great article ! This is exactly how I use my Emacs, only in tty.
| Take that VS :)
| jedberg wrote:
| This is a cool deep dive into terminal standards and their
| footguns but... not sure why?
|
| Unless you're showing pictures in your terminal, why would you
| want true color and the overhead that introduces? If you're just
| doing a status bar on a black background, your eye won't really
| see the difference between FF0000 and FF1515 (which I picked
| because the next 16 bit color is FF3333 which you can already
| barely tell the difference from).
|
| I'm just saying I'm not sure I would want that much color choice,
| it would just give me anxiety about picking the right color!
| spudlyo wrote:
| > I'm just saying I'm not sure I would want that much color
| choice, it would just give me anxiety about picking the right
| color!
|
| Developers of themes for Emacs often target the GUI first,
| where 24-bit color is the default. If you're a hardcore
| terminal Emacs user (and there are many legit reasons for this)
| you're stuck by default with 256 colors, and the themes just
| don't look right due to having to map the carefully chosen
| colors to the nearest color in the 256 color palette.
| chadaustin wrote:
| Exactly correct. Loading solarized in 256-color emacs shows
| just how poorly the (carefully-selected) Solarized colors map
| onto the xterm-256color palette.
| bhaak wrote:
| It clearly depends on what you do but having more colors is
| nice.
|
| Even if 256 colors are available it's not enough. The palette
| of the 256 colors is gruesome. You can clearly see that a
| technical person without any knowledge of color theory designed
| it.
| jwr wrote:
| If only there was a way to magically pass extended modifier keys
| to Emacs over a terminal...
|
| It's the only thing stopping me from using Emacs remotely over a
| terminal: I really do need my Super modifier. Hyper I can live
| without, but being able to do shift-super-f for example is
| fundamental.
| globular-toast wrote:
| Hmm... My Emacs has just worked with full colour in terminal for
| years. I didn't know it was a thing that needed to be configured.
| Skimming through the article I hope I never have to know this
| stuff.
|
| I also have icons in my terminal by using nerd icons.
| spudlyo wrote:
| The article is a deep dive on the evolution on terminal color,
| mentioning some of the "colorful" characters in the scene. This
| is specifically about the ultimate 24-bit expression of gawdy
| terminal bling, aka COLORTERM=truecolor. Perhaps you're not the
| kind of person who would notice if their Emacs color theme
| looked wrong because the theme designer's carefully chosen
| 24-bit color was mapped to the nearest color in the 256 color
| palette of the stock terminal.
| globular-toast wrote:
| Oh, I am that kind of person, believe me. Mine looks
| identical in the terminal. I use zenburn theme. The only
| thing I ever set in my bashrc is `TERM=xterm-256color`. I'm
| not sure why. I do have `COLORTERM=truecolor` set, but I
| didn't do it myself. It just works for me with or without
| those variables set in both xterm and alacritty.
| austinshea wrote:
| This is fantastic! Thank you for writing this and sharing it.
| chewxy wrote:
| Meanwhile I want my emacs to look more like this
| https://imgur.com/a/h0jA1ro
|
| (in case anyone thinks that's serious, it's a joke. I only use
| Cool Retro Term for presentations)
|
| edit: apparently my emacs works with 24 bit colour out of the
| box: https://imgur.com/a/BM5OTxp. The syntax highlighting is a
| bit annoying though.
| com2kid wrote:
| I have a deep love for cool retro term, I am sad that the
| project is mostly abandoned and has multiple issues on MacOS.
|
| IMHO none of the other retro terms look nearly as good.
| spudlyo wrote:
| https://muppetlabs.com/~mikeh/crt_emacs.png
|
| Cool Retro Term is great, I want to use it in a presentation as
| well.
| BigParm wrote:
| This is why I just use VSCode now.
|
| I enjoyed tinkering for years. One day my Vim colors wouldn't
| work in Tmux for like the 5th time in my life. I said, you know
| what? I'm done with all of this.
|
| I appreciate that what you did is fun. I just thought I'd share a
| perspective that sometimes we're sick of tinkering.
| kens wrote:
| That's a very interesting investigation. However, perhaps
| computing has lost its way, when a production system uses
| emulators of 1970s terminals to run a 1970s editor on a version
| of a 1970s operating system. I really think that we're stuck in a
| local maximum and there are probably much better ways to do
| things. Our computers are millions of times more powerful now,
| but we're still doing things the same way as literally half a
| century ago.
| TylerE wrote:
| People may be stuck in what they think is a local maximum. I
| ditched emacs close to 20 years ago (for jEdit, later Sublime
| and finally IntelliJ) and have never regretted it in the
| slightest.
|
| I don't want my editor to read usenet or play solitaire. I want
| it to edit text and surface useful contextual information, and
| otherwise stay out of the way and let me devote my mental
| energy to the task at hand and not futzing with the damn editor
| config.
| omaranto wrote:
| Wow, this looks so much harder than simply running GUI Emacs.
___________________________________________________________________
(page generated 2024-01-30 23:00 UTC)