A Definitive Guide to Enabling Italics in Vim and Tmux
rsapkf.netlify.com
rsapkf.netlify.com
* echo -e is not portable across shells, and even across versions of the same shell sometimes. The test output should be generated with printf. https://unix.stackexchange.com/q/65803/5132
* The article erroneously says "If you don't see italicised foo above, then you need to add a custom terminfo." where what it should say is "If vim does not emit this control sequence", or it should have an intermediate example using tput in place of hardwired control sequences. A custom terminfo will not affect the echo/printf command of the raw control sequences at all.
* The sideswipe about "better terminal emulators" mentioning only 3 fashionable ones is not well-founded. In fact, most terminal emulators (from XTerm to Konsole, including even recent VTE-based ones) support italicization. Supporting the boldface/roman/italics triad that has been in Unix document processing for approaching half a century is not a niche or novel thing.
* The xterm-256color entry in terminfo already has ritm= and sitm= capabilities (via xterm-base and ecma+italics). There's no need to make one's own from someone's file on GitHub. https://invisible-island.net/ncurses/terminfo.ti.html#tic-xt...
* The correct terminal type for tmux in terminfo is tmux or tmux-256color, which again already have ritm and sitm (again via ecma+italics). There is no need for a "new entry called 'tmux'". One should already have been there for roughly 5 years now. https://invisible-island.net/ncurses/terminfo.ti.html#tic-tm...
Added this to ~/.tmux.conf and it works:
set -g default-terminal "xterm-256color"
Even "screen" and "screen-256color" are not perfectly correct descriptions of tmux nowadays (italics actually being a case in point); and there is no problem with importing a "tmux-256color" entry into a more-than-half-a-decade-old terminfo database. The database structure lends itself both to copying individual records and to having extra records in one's home directory.
You should not be using "xterm-" anything with tmux, or with any terminal or terminal emulator that is not actually XTerm. Indeed, this mis-use is called out right at the top of the tmux FAQ.
* http://jdebp.uk./Softwares/nosh/guide/commands/TERM.xml#MIS-...
* https://invisible-island.net/xterm/xterm.faq.html#other_vers...
> As of tmux 2.1, if default-terminal is set to "screen" or matches " screen-* ", tmux will behave like screen and italics will be disabled.
This means that you must use a terminfo name that doesn't start with screen-*.
tmux's own behaviour does change, but that is secondary, and a bit of a bodge. (The applications will emit what they think is something else, but will end up emitting the ECMA-48 code for italics, so tmux refuses to recognize it.)
You could argue it is easier to read (and better for the environment too) but it wasn't that long ago when fixed width was the norm (typewriters, dot-matrix printers, early micro-computers / mainframes, etc) and people read just fine.
Personally I find fixed-width very hard to read for regular text.
For example, compare these two documents:
http://www.laputan.org/pub/papers/aim-349.pdf
http://www.larcenists.org/Documentation/Documentation0.98/r7...
I know which one I prefer when it comes to typography and readability.
That doesn't make me agree with you any less, though. Some words are just unnaturally wide in monospace.
In books, I agree. Even Gutenberg's press had variable width "types". However not everyone reads books regularly and fixed width was all that was available in offices (well, that or handwritten documents). So for a great many people like myself, fixed width typefaces were still the norm.
The only true meaning of natural text is the meaning given to the words; but the only true meaning of code is the way punctuation is organised around superficial natural texts within the elements.
Fixed width was used because the toolchains for it were cheaper (with computers, that included software that allowed to visualize document appearance.)
In the era when typewriters and dot-matrix printers dominated, sag, casual office documents, professional print still used proportional type for all the same reasons that that is the norm today, and that it was for centuries before typewriters, much less dot matrix printers.
I wasn't saying variable width didn't exist. My point was that a great many of us used to spend hours each day (many still do, in fact) working with fixed width and we managed just fine. The reason for my point is because some people on here love to overstate and exaggerate the effect different type-faces have on readability when often it's more of an issue with familiarity (eg if you only ever read fixed width typefaces then variable width types can sometimes take a moment to adjust to).
To illustrate this point, use a variable width typeface in your code editor. It's still perfectly usable but man is it jarring when you're used to monospaced fonts.
You haven't previously clearly articulated your point, it wasn't clear if you were being wrong but relevant (i.e., claiming that there was no significant usability advantage to proportional fonts for text documents) or making an accurate rebuttal of a strawman argument (i.e., correctly claiming that fixed-width text has non-zero usability in rebuttal to the claim that was never made that it is completely unusable.) As such, I made the generous assumption that you understood the context which favored assuming the former, but you seem to have instead settled on the latter position.
> To illustrate this point, use a variable width typeface in your code editor. It's still perfectly usable but man is it jarring when you're used to monospaced fonts.
I recently transitioned to Input Sans, a proportional coding font, for all code editing full-time, after having used monospaced fonts for coding pretty much exclusively since elementary school, for a little over 35 years; it was a big improvement and the transition was not jarring at all.
A fair amount of the older workforce did grow up with typewriters and, later, dot matrix printers (or even teletypes) in their offices. Many on even started their careers using computers that only supported monospaced typefaces. I remember the first time I saw variable width fonts on a VDU (as they used to call "monitors") and it took me a second or two to adjust to typeface because most of my text consumption up to that point had been with fixed with characters.
Or to use an analogy: horse-drawn ploughs might have pre-dated tractors by hundreds of years but that doesn't mean I have more experience with seeing horses ploughing fields than tractors.
Also code inherently has a structure whose readability is increased by monospace fonts.
Unless you are programming in FORTRAN or COBOL, I very much contest that claim
In my experience comments often ”lie”, so I put them in italics because they’re to taken with a pinch of salt. :)
Some people prefer it, some people hate it.
It's 2020, italics shouldn't be hard eh?
This works
printf "\e[3m foo \e[23m\n"
set t_ZH=^[[3m
set t_ZR=^[[23m
I was recently wondering how I'd make some keywords italic, like VSCode, which italicizes `self.foo` and others in Python. This thread came at the right time. I found this [post][2] that may help, in combination with OP.
[1]: https://stackoverflow.com/a/21077380/
[2]: https://www.reddit.com/r/vim/comments/dgbvw4/how_can_i_have_...
my workflow rn is ... suboptimal
set clipboard=unnamedplus
Not sure about tmux, I found it too cumbersome when it comes to scrolling and text selection, so I switched to dvtm some time ago(which has its own issues).