A Definitive Guide to Enabling Italics in Vim and Tmux(rsapkf.netlify.com)
rsapkf.netlify.com
A Definitive Guide to Enabling Italics in Vim and Tmux
https://rsapkf.netlify.com/blog/enabling-italics-vim-tmux
35 comments
I had italics in vim (TERM was xterm-256color), but not in tmux (TERM was screen).
Added this to ~/.tmux.conf and it works:
Added this to ~/.tmux.conf and it works:
set -g default-terminal "xterm-256color"
BTW it matters to me when using vim as a markdown viewer (esp for github readme.md).That is the wrong thing to do. The correct terminal type for tmux is either "tmux" or "tmux-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...
* https://github.com/tmux/tmux/wiki/FAQ
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...
* https://github.com/tmux/tmux/wiki/FAQ
In case anyone thinks they're doing something equivalent by making a screen-256color-italic terminfo with the right keys and making sure your terminal uses that, but is then surprised that it doesn't work, the linked tmux FAQ ie very important:
> 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-*.
> 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-*.
That's slightly misleading. The applications that get directed to a "screen-wibble" terminfo entry will behave as if they are running under screen, because there will be no terminfo ritm/sitm capabilities and they won't emit any control sequences for specifying italics.
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.)
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.)
I'm down with the hacking aspect here, but why would I want to render comments in italics? Comments are often larger pieces of natural language, and there's a reason we don't typeset our books in all-italics - it's harder to read.
Interestingly, italic type was invented in 1500 in order to make smaller, more space-efficient books - so the first books in italics were in all-italics. It wasn't until decades later that italics started being used sparingly for emphasis.
https://en.wikipedia.org/wiki/Italic_type#History
https://en.wikipedia.org/wiki/Italic_type#History
There is also a reason why we don't typeset books in monospaced fonts, but oh well...
Yup, because it's cheaper (more words per line / fewer pages).
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.
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.
Well, setting whole books in fixed-width has never been the norm.
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.
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.
Though in that example, to be fair, a major point in readability is the quality of the scan. Of course the LaTeX document is nicer, because it's digitally rendered instead of low-resolution scanned from a paper original. ;)
That doesn't make me agree with you any less, though. Some words are just unnaturally wide in monospace.
That doesn't make me agree with you any less, though. Some words are just unnaturally wide in monospace.
> Well, setting whole books in fixed-width has never been the norm.
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.
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.
However when you’re programming, you’re looking for structural rather than semantic meaning of words.
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.
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.
In your example, I find the typewritten text to be very beautifully laid out. The latex rendering is cluttered and uses a font which is too thin.
Computer Modern was designed to be printed with ink presses, and so it assumes a certain amount of running in the liquid. If it will be rendered solely on-screen, it needs to be thickened slightly. Fortunately this is easy with Metafont; unfortunately the default TeX installations don't do it.
I agree that the layout of the R7RS document could be further improved.
> 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.
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.
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.
You're just reiterating points I've already made (eg https://news.ycombinator.com/item?id=22726239) but without understanding the point I'm making.
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.
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.
> without understanding the point I'm making.
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.
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.
Given that the printing press was invented 1500 something (in Europe, China was probably earlier), the couple dozen years with typewriters and dot-matrix printers seem like a mere blip.
Most people aren't 1500 years old ;) Even the invention of the dot-matrix printer is older than most on here (never mind the typewriter).
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.
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.
Monaco (and I'm the last guy in earth to be labelled an apple fan) is my favourite font. Its damn readable. There are a lot of other readable mono fonts.
Also code inherently has a structure whose readability is increased by monospace fonts.
Also code inherently has a structure whose readability is increased by monospace fonts.
> 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
Unless you are programming in FORTRAN or COBOL, I very much contest that claim
I do it because most of the time I’m more interested in code than comments.
In my experience comments often ”lie”, so I put them in italics because they’re to taken with a pinch of salt. :)
In my experience comments often ”lie”, so I put them in italics because they’re to taken with a pinch of salt. :)
I switch my theme based on how I’m trying to read. Some themes emphasize comments, others deprioritizes them.
I have a vim snippet which highlights comments when I'm on them but fades them when the cursor is away.
I don't use syntax highlighting. Italicized comments help my eyes skip them, especially when using a font whose italics characters are notably different (e.g. Operator Mono).
There is a growing number of monospaced fonts that provide cursive italics for differentiation e.g., Operator Mono, Dank, Victor Mono.
Some people prefer it, some people hate it.
Some people prefer it, some people hate it.
This delights my inner nerd, but my outer curmudgeon is miffed: I've fallen out of love with teletype-based UIs (not text-based UIs) and it now feels like epic "turd polishing" taken to absurd lengths.
It's 2020, italics shouldn't be hard eh?
It's 2020, italics shouldn't be hard eh?
The echo command check didn't work for me on MacOS, bash 3.2
This works
This works
printf "\e[3m foo \e[23m\n"
Although, you could use the sequence '^vESC' for each '\e' with echo.Mine only worked when I added [this][1]:
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_...
set t_ZH=^[[3m
set t_ZR=^[[23m
before `highlight Comment cterm=italic`.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_...
I'll file this under reasons I don't use arcane terminal editors. There are so much better uses of my time.
on a related note, can someone point me to a definitive guide for getting clipboards to work between vim, tmux, and my local machine?
my workflow rn is ... suboptimal
my workflow rn is ... suboptimal
You can set Vim to use the clipboard as default register, meaning all yank, delete and paste operations will directly use the clipboard:
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).
set clipboard=unnamedplus
Although of course that won't work if vim runs in ssh.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).
Use emacs + evil; y and p share the same clipboard as the system.
* 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...