13 ms·

Every time I see a project using icon font sets (this particular project recommends Nerd Font [1]), I feel something is very wrong. We already have a sort of wa

Every time I see a project using icon font sets (this particular project recommends Nerd Font [1]), I feel something is very wrong. We already have a sort of way (or two) to represent an image in the terminal, but icon fonts are a different beast because it essentially supports a vector representation. Code point collision is already happening (Nerd Font is already coping with this [2]), and in a long run this seems unsustainable. So... is there any way or proposal to encode a vector image in the terminal? (And no, iTerm doesn't seem to support SVG in its inline image support [3].) [1] https://github.com/ryanoasis/nerd-fonts https://github.com/ryanoasis/nerd-fonts [2] https://github.com/ryanoasis/nerd-fonts/wiki/Codepoint-Conflicts https://github.com/ryanoasis/nerd-fonts/wiki/Codepoint-Confl... [3] https://www.iterm2.com/documentation-images.html https://www.iterm2.com/documentation-images.html

darkpuma 7y ago
xterm has a Tektronix 4014 mode, but that's not exactly what's needed or desired..
- msla 7y ago
  xterm also has sixels, which give reasonably high-resolution color graphics in normal VT340 mode. https://github.com/saitoha/libsixel https://github.com/saitoha/libsixel By high-resolution I mean you can display JPEGs using sixels. You can run OpenGL programs using sixels.
pcwalton 7y ago
Unfortunately, the Unix terminal is a gigantic pile of hacks accumulated since the late 1960s. It's a miracle the software stack manages to stay upright at all; adding features and getting the entire ecosystem to support them would be tough. Introducing the concept of an external resource that has to be fetched doesn't seem impossible to me, but there are a lot of issues that would have to be thought through. Anyway, one nice thing about TrueType/OpenType fonts is that the vector representation is extremely well compressed. SVG or similar would be an efficiency loss. In this light, fonts are actually a fairly decent and practical way to represent vector symbols that will be cached and reused. Maybe a minimal practical solution might be to add an ANSI extension that requests an appropriate font for a particular area of the screen, perhaps with a URL from which a specific webfont can be fetched.
- lifthrasiir 7y ago
  > Introducing the concept of an external resource that has to be fetched doesn't seem impossible to me, but there are a lot of issues that would have to be thought through. I agree that an external resource is a lot of hurdles. What I had in mind while writing the reply was a stripped-down version of TrueType, with only a single `glyf` table allowed (probably with a minimal version of the `head` table as well). Judging from how icon fonts are used today, this might even be possible without a persistent font state.
- m463 7y ago
  > Unfortunately, the Unix terminal is a gigantic pile of hacks accumulated since the late 1960s stty sane
- hollerith 7y ago
  >Unfortunately, the Unix terminal is a gigantic pile of hacks accumulated since the late 1960s. Agreed, and I don't understand why most of the things still done in the Unix terminal have not transitioned to newer, less hacky environments. I managed to replace the vast majority of the things I was using the terminal for with uses of about 400 lines of Emacs Lisp code that I wrote about 5 years ago. A large fraction of my uses of the terminal since then have been for the purpose of my getting my Emacs environment and my data files installed on a fresh install of my OS and for recovering from those times when I inadvertently introduced a bug into my Emacs environment that my regression tests did not catch. The 400 lines of Emacs Lisp code submits a string I typed to bash with the -c flag then asynchronously (i.e., without blocking Emacs's UI) waits for output from the bash process. I also added a way for the user to arrange for a bell to ring when the process finishes. Notably, there is no provision for the user to cause anything to be sent to the process's stdin after the process is started, which allows the 400 lines of code to use a pipe instead of a pty (which is relevant to this comment thread because if OSes didn't need to support the pty abstraction, they could be significantly simpler). In the rare case when I want to send a string to the stdin of some process I use the shell to set things up: echo "here is the string" | some process That whole command line becomes one argument to a call to bash. The 400 lines of code I wrote cannot be used to interact with a REPL. E.g., if you use my 400 lines of code to run "python" by itself as a command line, the python process waits for user input, which will never come because there is no way to write to the python process's stdin. The closest analog in standard Gnu Emacs to the 400 lines I wrote is "shell mode" (shell.el) which consists of about 3 or 4 thousand lines of Emacs Lisp code. My code re-uses shell mode's code for interpreting (ignoring in my case) the escape sequences for ANSI color and for interpreting the escape sequences for "carriage control", but (like shell mode) does not handle the escape sequences for cursor addressing. IIRC the main reason I was dissatisfied with shell mode was that it contains hacky code to keep the bash process's "opinion" on what the current working directory is in sync with the shell mode buffer's "opinion" on what it is. In contrast, in my code, the buffer's "opinion" is the only one that matters (because every command line is processed by a fresh bash process on that bash process inherits its current working directory from the Emacs process when it is created). If I ever were to start to need to issue a great many command lines on a variety of remote Unix servers, I would probably take the time to write a replacement for ssh along lines similar to what I just described.
stefco_ 7y ago
We have some standardized emoji like . Seems like the partial 2019 solution would be to use emoji that should work in any modern font (you could make a more UNIXy-feeling font if you want everything to look less skeuomorphic and more stripped-down). This doesn't cover every programming-specific use case, but it's a nice compromise I haven't seen mentioned here.
- lifthrasiir 7y ago
  Indeed, there is a WG2/UTC proposal to officially add Powerline symbols to Unicode [1]. The problem of this approach is that those standards are very strongly (and probably rightly) governed with a lot of crufts and limitations, for example you can't put Github symbol there because it is trademarked. [1] https://www.unicode.org/L2/L2019/19068-powerline-syms.pdf https://www.unicode.org/L2/L2019/19068-powerline-syms.pdf
- saagarjha 7y ago
  Note that Hacker News strips emoji out from comments.
- pvg 7y ago
  the partial 2019 solution would be to use emoji that should work in any modern font This usually works not by having fonts define emojis (most don't) - it's just that systems reach in and render emojis from a dedicated emoji-defining font when they encounter them. So it's not like the world is full of fonts that define 'standard emojis' or funky powerline symbols.
albertzeyer 7y ago
I recently collected a list of image support in terminal emulators here: https://github.com/albertz/wiki/blob/master/terminal-escape-codes.md#images https://github.com/albertz/wiki/blob/master/terminal-escape-... The only more or less widely used solutions are iTerms image support (PNG images, no vector), or Sixel (xterm and some other exotic ones). There is also ReGIS (https://en.wikipedia.org/wiki/ReGIS https://en.wikipedia.org/wiki/ReGIS), which is a vector format, which might be supported by xterm (not sure).
enriquto 7y ago
> So... is there any way or proposal to encode a vector image in the terminal? For raster images there are sixels, and for vector there are the tektronix codes. These are standard in xterm since forever. Of course, they could be modernized, using real raster pixels and something like a subset of svg. I guess before standarization it would be better to have a reference implementation included in a major standard terminal.
Tepix 7y ago
hterm[1] supports ReGIS which is vectors graphics. A standard xterm supports vt340 if you start it with the option "-ti vt340" which supports ReGIS as well. [1] http://41j.com/hterm/ http://41j.com/hterm/
knolax 7y ago
Personally I always found using icons as defeating the whole point of using a terminal; One of the primary reasons I prefer terminal UIs over GUIs is that I don't have to decipher a bunch of strange hieroglyphs.

darkpuma 7y ago

xterm has a Tektronix 4014 mode, but that's not exactly what's needed or desired..

msla 7y ago
xterm also has sixels, which give reasonably high-resolution color graphics in normal VT340 mode. https://github.com/saitoha/libsixel https://github.com/saitoha/libsixel By high-resolution I mean you can display JPEGs using sixels. You can run OpenGL programs using sixels.

pcwalton 7y ago

Unfortunately, the Unix terminal is a gigantic pile of hacks accumulated since the late 1960s. It's a miracle the software stack manages to stay upright at all; adding features and getting the entire ecosystem to support them would be tough. Introducing the concept of an external resource that has to be fetched doesn't seem impossible to me, but there are a lot of issues that would have to be thought through. Anyway, one nice thing about TrueType/OpenType fonts is that the vector representation is extremely well compressed. SVG or similar would be an efficiency loss. In this light, fonts are actually a fairly decent and practical way to represent vector symbols that will be cached and reused. Maybe a minimal practical solution might be to add an ANSI extension that requests an appropriate font for a particular area of the screen, perhaps with a URL from which a specific webfont can be fetched.

lifthrasiir 7y ago
> Introducing the concept of an external resource that has to be fetched doesn't seem impossible to me, but there are a lot of issues that would have to be thought through. I agree that an external resource is a lot of hurdles. What I had in mind while writing the reply was a stripped-down version of TrueType, with only a single `glyf` table allowed (probably with a minimal version of the `head` table as well). Judging from how icon fonts are used today, this might even be possible without a persistent font state.
m463 7y ago
> Unfortunately, the Unix terminal is a gigantic pile of hacks accumulated since the late 1960s stty sane
hollerith 7y ago
>Unfortunately, the Unix terminal is a gigantic pile of hacks accumulated since the late 1960s. Agreed, and I don't understand why most of the things still done in the Unix terminal have not transitioned to newer, less hacky environments. I managed to replace the vast majority of the things I was using the terminal for with uses of about 400 lines of Emacs Lisp code that I wrote about 5 years ago. A large fraction of my uses of the terminal since then have been for the purpose of my getting my Emacs environment and my data files installed on a fresh install of my OS and for recovering from those times when I inadvertently introduced a bug into my Emacs environment that my regression tests did not catch. The 400 lines of Emacs Lisp code submits a string I typed to bash with the -c flag then asynchronously (i.e., without blocking Emacs's UI) waits for output from the bash process. I also added a way for the user to arrange for a bell to ring when the process finishes. Notably, there is no provision for the user to cause anything to be sent to the process's stdin after the process is started, which allows the 400 lines of code to use a pipe instead of a pty (which is relevant to this comment thread because if OSes didn't need to support the pty abstraction, they could be significantly simpler). In the rare case when I want to send a string to the stdin of some process I use the shell to set things up: echo "here is the string" | some process That whole command line becomes one argument to a call to bash. The 400 lines of code I wrote cannot be used to interact with a REPL. E.g., if you use my 400 lines of code to run "python" by itself as a command line, the python process waits for user input, which will never come because there is no way to write to the python process's stdin. The closest analog in standard Gnu Emacs to the 400 lines I wrote is "shell mode" (shell.el) which consists of about 3 or 4 thousand lines of Emacs Lisp code. My code re-uses shell mode's code for interpreting (ignoring in my case) the escape sequences for ANSI color and for interpreting the escape sequences for "carriage control", but (like shell mode) does not handle the escape sequences for cursor addressing. IIRC the main reason I was dissatisfied with shell mode was that it contains hacky code to keep the bash process's "opinion" on what the current working directory is in sync with the shell mode buffer's "opinion" on what it is. In contrast, in my code, the buffer's "opinion" is the only one that matters (because every command line is processed by a fresh bash process on that bash process inherits its current working directory from the Emacs process when it is created). If I ever were to start to need to issue a great many command lines on a variety of remote Unix servers, I would probably take the time to write a replacement for ssh along lines similar to what I just described.

stefco_ 7y ago

We have some standardized emoji like . Seems like the partial 2019 solution would be to use emoji that should work in any modern font (you could make a more UNIXy-feeling font if you want everything to look less skeuomorphic and more stripped-down). This doesn't cover every programming-specific use case, but it's a nice compromise I haven't seen mentioned here.

lifthrasiir 7y ago
Indeed, there is a WG2/UTC proposal to officially add Powerline symbols to Unicode [1]. The problem of this approach is that those standards are very strongly (and probably rightly) governed with a lot of crufts and limitations, for example you can't put Github symbol there because it is trademarked. [1] https://www.unicode.org/L2/L2019/19068-powerline-syms.pdf https://www.unicode.org/L2/L2019/19068-powerline-syms.pdf
saagarjha 7y ago
Note that Hacker News strips emoji out from comments.
pvg 7y ago
the partial 2019 solution would be to use emoji that should work in any modern font This usually works not by having fonts define emojis (most don't) - it's just that systems reach in and render emojis from a dedicated emoji-defining font when they encounter them. So it's not like the world is full of fonts that define 'standard emojis' or funky powerline symbols.

albertzeyer 7y ago

I recently collected a list of image support in terminal emulators here: https://github.com/albertz/wiki/blob/master/terminal-escape-codes.md#images https://github.com/albertz/wiki/blob/master/terminal-escape-... The only more or less widely used solutions are iTerms image support (PNG images, no vector), or Sixel (xterm and some other exotic ones). There is also ReGIS (https://en.wikipedia.org/wiki/ReGIS https://en.wikipedia.org/wiki/ReGIS), which is a vector format, which might be supported by xterm (not sure).

enriquto 7y ago

> So... is there any way or proposal to encode a vector image in the terminal? For raster images there are sixels, and for vector there are the tektronix codes. These are standard in xterm since forever. Of course, they could be modernized, using real raster pixels and something like a subset of svg. I guess before standarization it would be better to have a reference implementation included in a major standard terminal.

Tepix 7y ago

hterm[1] supports ReGIS which is vectors graphics. A standard xterm supports vt340 if you start it with the option "-ti vt340" which supports ReGIS as well. [1] http://41j.com/hterm/ http://41j.com/hterm/

knolax 7y ago

Personally I always found using icons as defeating the whole point of using a terminal; One of the primary reasons I prefer terminal UIs over GUIs is that I don't have to decipher a bunch of strange hieroglyphs.