
Aminal: Golang terminal emulator from scratch - guessmyname
https://github.com/liamg/aminal
======
panic
I hadn't heard of SIXEL
([https://github.com/saitoha/libsixel/blob/master/README.md](https://github.com/saitoha/libsixel/blob/master/README.md))
before. It's cool to see a standard for bitmap graphics in the terminal
catching on.

~~~
vtesucks
I think currently one of the most popular Linux termemu is kitty which also
supports this. So its definitely catching on.

~~~
codetrotter
KiTTY is useful for Windows users but are any significant amount of people
using it on Linux? I would imagine that aside from people using the default
terminal emulators that come with their distro or desktop environment like
xterm, gnome-terminal and konsole, the most widely used terminal emulator on
Linux would be urxvt.

Personally I use terminology which I am satisfied with.
[https://www.enlightenment.org/about-
terminology.md](https://www.enlightenment.org/about-terminology.md)

~~~
m45t3r
OP is talking about this Kitty
([https://sw.kovidgoyal.net/kitty/](https://sw.kovidgoyal.net/kitty/)), not
this one [http://www.9bis.net/kitty/](http://www.9bis.net/kitty/).

~~~
codetrotter
Ah, I see. Thanks.

------
jchw
While a GPU accelerated terminal emulator sounds great on paper, do keep in
mind that GPU acceleration doesn't really give you that much in terms of raw
performance. You still have to render glyphs individually, almost always on
CPU. So, the reality is probably more that GPU acceleration gives you more
flexibility, rather than giving you performance. Anecdotally, I just ran this
and it takes roughly twice as long to slog through my dmesg as gnome-terminal.

That said... pretty cool. I don't know if there already existed VT100
emulation written in Go, but it doesn't hurt to have that. Plenty of
applications might want to embed a terminal or otherwise have terminal
emulation.

~~~
bpye
With a fixed width font in a single size surely caching glyphs goes a long
way? Most of the characters probably come from a small set of characters, and
obviously a cache can support full unicode. I guess you couldn't do subpixel
hinting but an alpha blended character can be tinted any colour for FG/BG.

~~~
jchw
You can do caching with any renderer, GPU or not. Almost any text renderer
caches glyphs to some degree. Of course, even fixed width fonts can have
things like ligatures and composite characters which complicate matters.
Rather than caching individual code points, you'd really need to cache
something more like individual grapheme clusters.

Subpixel rendering is tricky, but should be possible to do with shaders. You
could just render to a normal single channel texture at 3x the horizontal
spatial resolution (basically, stretched 3x horizontally) then when rendering
move 1 pixel across the glyph rendering for each subpixel, alpha blending
individually.

~~~
bpye
Ah true. I guess I personally do not use a font with ligatures so it didn't
really come to mind.

Subpixel renderering with shaders is a neat idea, is it something that has
been done before?

~~~
jchw
I don't know; I assume yes because it seems possible and I doubt I'm the very
first person to think about it.

------
TheDong
it's great to see more terminal emulators, especially ones that have good
unicode support and are trying to be faster than the average garbage.

There's at least one other terminal emulator that does things akin to the
image-catting and viewing colors when you click them, namely terminology [0].

There's also at least one other that uses opengl for faster rendering
(alacritty [1]).

I don't know of any other that do both these things; use opengl for speed and
also innovate in interactivity.

[0]: [https://www.enlightenment.org/about-
terminology.md](https://www.enlightenment.org/about-terminology.md)

[1]: [https://github.com/jwilm/alacritty](https://github.com/jwilm/alacritty)

~~~
elithrar
Also: iTerm2 can use macOS’ Metal graphics API to great effect:
[https://gitlab.com/gnachman/iterm2/wikis/Metal-
Renderer](https://gitlab.com/gnachman/iterm2/wikis/Metal-Renderer)

------
enriquto
Sixel is great. But you could also interpret the headers of common image file
formats as terminal escape sequences, so that you can directly "cat lena.png"
and see the image. Now, _that_ would be a real hack!

~~~
laumars
The terminal couldn't do that as it wouldn't know the difference between a
user typing `cat lena.png` into Bash from typing the same sequence of
characters into vim (for example).

This is why there are separate commands like `icat` which will output ANSI
escape sequences for rendering a PNG. Unfortunately a great many of these are
terminal specific (iterm, terminology, kitty and VT200/VT300 (sixel) all have
their own unique escape sequences. The closest to a standard we have is sixel
and, frankly, I don't think it's that good on modern systems[1]). So you end
up with different command for each "standard" you want rendered.

The approach I've taken in my own $SHELL is to have a builtin command like
`cat` (I call it `open`) and that auto-detects which terminal emulator you're
running and picks the right encoding to match what is supported by the
terminal (if no standard can be auto-detected, then it falls back to ANSI art
using coloured blocks). However the issue with that is now people need to run
new custom shell instead Bash / Zsh / whatever. But the logic behind the auto-
detection is really quite simple so that could be written it's own standalone
tool.

[1] sixel re-encodes images in character blocks of 6 pixels. Where as iTerm,
Kitty and Terminology send the image as is over the terminal via a base64
encoded string. All those solutions are inlined via ANSI escape sequences
though.

~~~
enriquto
> The terminal couldn't do that as it wouldn't know the difference between a
> user typing `cat lena.png` into Bash from typing the same sequence of
> characters into vim (for example).

This is not what I am talking about. I mean the binary headers inside png,
jpg, tiff files, etc. These binary sequences can be easily interpreted as
terminal control sequences, and they are very unlikely to appear otherwise.
For pnm files I agree that the situation is a bit more delicate, as these
sequences are likely to appear in the wild (e.g., in the pnm man page for
example).

~~~
laumars
Ahhh. That's an interesting idea. I like it

~~~
enriquto
This is an inevitable feature of the perfect terminal. The alternative is
showing the binary contents of the image file in ASCII, which is always
undesired.

~~~
laumars
Not just undesired; it can sometimes play havoc with your terminal session.
I've had tmux status bars break; bash prompts go "weird" and all sorts of
other glitches before when I've accidentally piped binary data to the STDOUT.

I'm very tempted to fork Aminal and have a play with your idea.

~~~
enriquto
That would be lovely! I do a lot of image processing using unix pipes, and
when I forget the "|display" at the end it breaks everything.

Notice that you do not even need to use sixels in your case. Since you control
the rendering, you can simply put the pixels of the image on a rectangle (that
allows paning and zooming, for example), and move the cursor below it.

~~~
laumars
It wouldn't be until I'm off for Christmas holidays (at the earliest) though.
I don't have a whole lot of time left between work and family; and have a few
projects on the go as it is already.

------
bigdubs
This is neat, and it's important to iterate on things we take for granted like
what terminal emulator we use.

But a larger question, at what point do we focus on the novelty of the
project, not that it was written in a specific language?

~~~
w323898
Once we've rewritten everything in go. More realistically, once the language
is stable and known enough that these things become uninteresting.

~~~
danaur
Could you elaborate? I don't understand what you are implying

------
reificator
It's great that there's a hotkey to web search for the current selection, but
I'd not be surprised to see people requesting that it not be google. Know your
audience and all that.

~~~
yjftsjthsd-h
Seems like a config option would be easy enough.

------
marsrover
Looks very cool. What’s the timeline for it being released for Windows?

~~~
bpye
It would be great to see this working with the new ConPty API.

Note: I work for Microsoft but I have never touched anything to do with
ConPty.

------
utam0k
> Retina display support

I want to know what is difficult to support this.

~~~
maddyboo
This may be referring to running under Linux with a high DPI monitor - a lot
of programs which are naïve about this don't scale properly and are teeny-
tiny.

------
kthartic
Isn't OpenGL deprecated now? iTerm recently switched to Metal.

~~~
nolok
Since it's Linux compatible it's much simpler to support a global standard
like open gl and mostly work everywhere rather than use whatever apple is
pushing now and also support open gl anyway for Linux.

I assume they're open to contribution if someone wants to add Metal support
for mac osx.

------
sys_64738
ETA on tmux -CC support?

------
dsamarin
I knew this would be created eventually but I was thinking it would just be a
shell. This looks impressive at first glance, implementing everything with
OpenGL.

~~~
jeromenerf
I would have loved to see someone with a plan9-golang background creating a
modern 9term-like "dumb" terminal. One that is mostly an editable text buffer
with mouse plumbing capabilities.

Nowadays, terminals within vim/emacs is what's closer, feature wise. Not quite
dumb though.

------
vtesucks
Does it not use VTE? If so that would be great.

Also, to the other commmentator- be glad its not written in "modern web
technology". I keep 20 terminals open usually.

~~~
paavoova
Edit: it's GTK that provides multithreading functionality, not VTE itself.

VTE based terminals are actually multithreaded globally, so you only ever have
one process regardless of number of tabs/windows open.

But I agree, VTE is something I avoid ever since the scrollback fiasco. (For
the uninitiated: the library wrote all scrollback to disk, which is not
something end-users might expect security wise. Scrollback is encrypted now,
but it appears you still cannot disable writing to disk, as e.g. the output of
dmesg, consisting of 62210 bytes of output on my machine, causes 5-digits of
bytes to be written each time on any VTE-based terminal I've tried even with
"infinite" scrollback disabled. And none appear to honor TMPDIR).

~~~
voltagex_
I wish I understood it enough to throw it into GDB - it looks like it uses
O_TMPFILE, but I don't think that quite gives you what you want.

[https://github.com/GNOME/vte/blob/65d67f6f814df4f4ab800898bb...](https://github.com/GNOME/vte/blob/65d67f6f814df4f4ab800898bb7f4b1bc9f135b0/src/vteutils.cc#L50)

~~~
paavoova
The O_TMPFILE flag is just an anonymous file as far as I understand. From that
source file, VTE uses glib, particularly g_get_tmp_dir() and g_file_open_tmp()
(which uses the latter), which claims to honor TMPDIR according to the docs:
[https://developer.gnome.org/glib/stable/glib-
Miscellaneous-U...](https://developer.gnome.org/glib/stable/glib-
Miscellaneous-Utility-Functions.html#g-get-tmp-dir)

Perhaps a terminal emulator is unable to read variables exported in .bashrc,
as the terminal is started prior to executing the shell.

------
vtesucks
Cannot edit previous comment so adding new-

Can you please add some details on Unicode support? Most terminals claim to
have it but fail miserably on Asian (Asia continent) fonts.

1) RTL for west Asia

2) Indic fonts and dependent vowels

3) Double width cjk.

I genuinely believe that without all 3, no terminal emulator deserves to claim
Unicode support.

~~~
malkarouri
And I am not sure how many of them support Arabic right to left either..

~~~
vtesucks
Arabia is west Asia :)

~~~
coldtea
Or rather, Middle East.

