
Rich Tables in the Terminal - willm
https://github.com/willmcgugan/rich#tables
======
oblio
He he! Souped up IBM PC box drawing characters, circa 1981:
[https://en.m.wikipedia.org/wiki/Box-
drawing_character](https://en.m.wikipedia.org/wiki/Box-drawing_character)

~~~
lathiat
These terminal character boxes remind me of the DOS days.. lots of programs
such as the library access program used these and I used to use them in my
QBasic programs.

------
yjftsjthsd-h
So, it _is_ cool; let me say that much before I criticize. That said: live
resizing a table is a bit of a pain if you're trying to select something (to
copy or to highlight it to show someone else). It's like a webpage that moves
a link just as you click. Is there any way to fix the width and append only to
the end? (Just optionally; I understand why it resizes dynamically by default)

~~~
willm
The animation is purely for demonstration purposes. Generally you would use
this to render a formatted table as the result of a CLI.

~~~
1996
IF you want to add other things to the CLI, like graphics or unicode, check
this library:

[https://gitlab.com/klamonte/jexer](https://gitlab.com/klamonte/jexer)

------
Anthony-G
This looks really impressive: elegant and beautiful with an easy-to-use API. I
don't know if submission titles can be edited 9 hours after posting but this
would be an excellent addition to _Show HN_ and might get more attention as
such.

[https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)

------
kureikain
Can It detect non terminal output and render normal ascii such as when
pipe/redirect stdout/stderror to a file? or pipe to seed and avoid messing up
with color code.

I recently release a tool with a nice table but many hate the format, the
color and it even make `grep` impossible because color code make grep match
every line :-(

~~~
spudlyo
man 3 isatty

If you find yourself hard coding ANSI escape sequences in your program's
output, please, please check to see if STDOUT is a tty first. This will
prevent spewing escape sequences to a file.

For extra credit, please consider using tput() and friends to emit escape
sequences rather than hard coding them. This may seem stupid when nearly every
terminal in the world is now effectively an ANSI terminal, but sometimes
vision impaired folks (and others) are using intentionally limited terminals
with their type set to "dumb". Good programs respect this, and conditionally
output their escape sequences.

~~~
JdeBP
* [https://github.com/willmcgugan/rich/blob/837b6d7e85254f0047c...](https://github.com/willmcgugan/rich/blob/837b6d7e85254f0047cb41a4cbe0e4b00f54809d/rich/console.py#L435)

Note that it is possible to respect TERM=dumb without using termcap or
terminfo, although this library does not do that.

------
teddyh
This seems to only support rendering. If you also want interactive use,
another library which does things like this is Urwid:

[http://urwid.org/examples/](http://urwid.org/examples/)

~~~
cthonicthulu
I originally looked at Urwid for a side project I was working on, but it
seemed a bit heavyweight for the kind of prototyping I wanted to do.

I ended up settling on Visidata's vdtui [1]. It's pretty strongly opinionated
and there are a lot of batteries included, but on the plus side, you can get a
pretty functional tabular CLI app working with very little code, and start
focusing on your business logic rather than the scaffolding. I was pretty
satisfied with it.

[1]
[https://github.com/saulpw/visidata/blob/stable/visidata/vdtu...](https://github.com/saulpw/visidata/blob/stable/visidata/vdtui.py)

~~~
anjakefala
Do you have a link to the tool you built with vdtui? =)

------
easterncalculus
Rich is great. Have been using it for a couple of projects and the support is
great, even on terminals with less color support.

~~~
willm
I’m glad you find it useful!

~~~
danudey
I pushed for moving one of our internal tools to Python 3 only so that I could
start using Rich in it, it's that good.

------
mattatkeyboard
Naff tables (along with poor graphs) was one of my key motivations to create
WV Linweise, which spawns a tiny web renderer to make displays nicer... Love
the terminal, but some things it is just not great at...

This mini example app renders CSV data from STDIN into a HTML tables -
[https://github.com/forbesmyester/wv-
linewise/tree/master/exa...](https://github.com/forbesmyester/wv-
linewise/tree/master/examples/discover-types)

------
dang
Related from a few months ago:
[https://news.ycombinator.com/item?id=23070821](https://news.ycombinator.com/item?id=23070821)

------
bluedays
I started using this in a project of mine a few days ago and I highly
recommend this library. It is super intuitive and easy.

------
miguelmota
This is sweet. Is there an equivalent of this library for Go? Particularly
with scrolling support

~~~
omani
Im using
[https://github.com/olekukonko/tablewriter](https://github.com/olekukonko/tablewriter)
in Go.

------
enricozb
Those progress bars look delicious

~~~
reaperducer
I agree.

Also: My kingdom for rsync with progress bars.

~~~
yjftsjthsd-h
\--progress ?

------
xixixao
This makes me think how close this is to HTML output + DOM rendering, and what
would be the proc and cons of each, how could you get max pros of the CLI
approach into the HTML approach.

~~~
willm
My goal was to bring some of the capabilities of HTML to the console. The
browser is always going to win in terms of capabilities.

------
zemnmez
this is awesome! Terminal programs are so satisfying, but at the same time it
always feels like they miss so many primitives that I take for granted for
content display

~~~
willm
That was my main motivation in working in Rich. Whenever I move from the
frontend to the backend, I miss what the browser can do so effortlessly.

------
gonewb
Is this using ncurses?

~~~
sxp
[https://github.com/willmcgugan/rich/blob/master/rich/console...](https://github.com/willmcgugan/rich/blob/master/rich/console.py#L501)
shows that's it's directly using escape codes: [http://ascii-table.com/ansi-
escape-sequences-vt-100.php](http://ascii-table.com/ansi-escape-sequences-
vt-100.php)

~~~
JdeBP
It's not using ncurses nor terminfo, but it's very misleading to point to a
list of VT100 escape sequences when it most definitely is not doing things the
VT100 way _either_.

In contrast to the monochrome VT100 this is using colour quite significantly,
albeit not supporting the recent corrections of a widespread mistake; and it
even seems to support the rare framed and encircled attributes of later
ECMA-48. Also in contrast to the VT100 it nowhere seems to deal in double-
height or double-width, nor is it using ECMA-35 character set switching.

~~~
gonewb
THanks!, I ask because I am starting a new project to create a terminal based
gui and my research led me to think the ncurses was a solid choice, are you
experienced with the terminal gui ecosystem, what are your thoughts on
starting a new project with ncurses?

~~~
JdeBP
It's really a _Textual_ User Interface when one uses terminal I/O, not a
_Graphical_ UI.

Personally, I did start a new project with ncurses. I wrote console-ncurses-
realizer before I wrote console-termio-realizer in the nosh toolset. But I hit
the limitations of ncurses very quickly.

* [http://jdebp.uk./Softwares/nosh/guide/commands/console-ncurs...](http://jdebp.uk./Softwares/nosh/guide/commands/console-ncurses-realizer.xml#LIMITATIONS)

* [http://jdebp.uk./Softwares/nosh/guide/commands/console-termi...](http://jdebp.uk./Softwares/nosh/guide/commands/console-termio-realizer.xml#IOPROTOCOL)

There are lots of problems with ncurses, and the terminfo system that
underpins it. They include the model of BCE not matching how terminals
actually work, function key processing involving string matching instead of
proper parameter parsing, little to no distinction between calculator keypad
and editor/cursor keypad keys, "cursor addressing mode" not being what
terminals actually do, ECMA-48 processing being needed in both directions, the
"colour pair" system not really matching any terminal's handling of colour
since the 1970s, and the continued use of ECMA-35 7-bit/8-bit character set
switching (a cause of a vast amount of end user headaches down the decades)
rather than Unicode for things like block graphics and box drawing characters.

If one starts again from first principles and comes up with a terminal
capabilities system now, one comes up with a rather different set of
capabilities and an ECMA-48-plus-ITU-T.416-plus-UTF-8-plus-some-DEC-VT model.
One comes up with a far better model of the colour mechanisms, for starters.
The library at hand employs it, as does my library.

* [http://jdebp.uk./Softwares/nosh/guide/commands/TerminalCapab...](http://jdebp.uk./Softwares/nosh/guide/commands/TerminalCapabilities.xml)

And there are, as the headlined library shows, UI libraries that do this.
There _are_ problems with some of these libraries, as with the headlined
library here for example and lack of support for TERM=dumb, which is still a
mechanism that is very much in use. (My library allows for it.) But for
programming languages from C++ to Python one has been able for some years now
to find libraries that aim to replace terminfo with something better, and
build up to approximately the level of abstraction that one gets in ncurses
with panes and windows and suchlike.

Of course, those library implementors themselves also discover how bad some
terminal emulators are at even some of the 1976 basics such as reverse video;
that some terminal emulators are actively regressing from 1980s video terminal
semantics to 1960s paper terminal semantics; and that there are still parts of
the 1990s editions of ECMA-48 that no terminal emulator has implemented until
_this year_.

If you feel comfortable with the idea that you or your users will never in the
21st century encounter a terminal that doesn't understand ECMA-48 and ITU
T.416 and UTF-8, with varying degrees of DEC VT added in, then yes you
probably should consider libraries such as the headlined one and others like
it. Now that Unicode 13 is here, you can even ask their authors to allow using
MouseText for TUI window borders and gadgets, a bold step forward into the
1980s. (-:

On the other hand, if you are comfortable living within the constraints of a C
language API, limited keyboard and colour models, and the various mismatched
paradigms, because you won't be pushing any of their boundaries in your TUI,
then ncurses is there for you.

On the gripping hand, if you want WIMPs, there's always the option of _writing
a GUI application_.

------
the8472
This may be heresey, but does it support mouse interaction, e.g. sorting by
clicking on the column header like midnight commander does?

~~~
willm
No, the animation was for demo purposes. It’s not normally dynamic.

------
a_t48
That traceback handler is awesome. I wonder if there's a way to hook all my
python programs to use it.

~~~
chameleon_world
You can, the instructions are here:
[https://rich.readthedocs.io/en/latest/traceback.html](https://rich.readthedocs.io/en/latest/traceback.html)

But it is noticeably slower than the default python handler

~~~
a_t48
Slower in what way? Just on crash? I don't mind that. But I meant for programs
I _don't_ typically write source for - if Python has a way to run code before
every program start up it would do what I want.

~~~
willm
Its slower when it renders the traceback, all that reading of source and
syntax highlighting takes second or two. There is a way of importing something
automatically, see the sites module docs.

------
ishcheklein
This looks awesome! Gonna try to use it for DVC where we need to show tables
of experiments, metrics, etc.

------
2ion
kitty terminal has built-in extensions to xterm terminal protocol extensions
to make this kind of thing much easier, toda. Hacking the terminal is nice but
another way is moving forward in developing it.

------
cosmotic
This seems to be begging the question: At what point does one move to a GUI?
GUIs are well suited for these tasks.

~~~
makecheck
Terminal features work better across all platforms than most GUIs. They are
more likely to have efficient keyboard commands for everything. And if (say)
you wanted to Copy arbitrary text from anywhere in the terminal, you can (a
GUI would have to explicitly support Copy for the things it presents).

Clearly GUIs have a place but terminal UIs are really powerful.

~~~
cosmotic
GUIs are much more consistent across platforms than terminal features. Windows
look and behave consistently but DOS vs BASH are totally different.

I'm not sure what you mean by efficient keyboard commands. Command line
programs are extremely inconsistent with regard to command line parameters,
especially across platforms. They're inconsistent between common programs in
Linux and between common programs on Windows.

Copying arbitrary text from a terminal is more rigid than a GUI; it's
difficult to select with a keyboard, the text is unlikely to be formatted (
sometimes a good thing), and often what you want to copy isn't text but an
image, sound, video clip, or some sort of object.

Powerful depends on what you mean by power. There exist somewhat-interoperable
terminal programs, but there are lots of GUI programs that are as
interoperable or even more interoperable and both can be scripted. Often
requisite functionality is only exposed with a terminal program, but that has
nothing to do with the lack of power of a GUI.

