Rich Tables in the Terminal | Hacker News Reader

Rich Tables in the Terminal

github.com

298 pointswillm50 comments

He he! Souped up IBM PC box drawing characters, circa 1981: https://en.m.wikipedia.org/wiki/Box-drawing_character

With Unicode 13, one can even do Apple MouseText from the 1980s now.

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.

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)

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

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

https://gitlab.com/klamonte/jexer

Best suggestion I've seen is for the interface to respond to what was at the point of interaction ~300ms before the click or touch action.

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

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 :-(

Yes, Rich will remove escape sequences when not writing to a terminal.

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.

* https://github.com/willmcgugan/rich/blob/837b6d7e85254f0047c...

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

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/

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...

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

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

I’m glad you find it useful!

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.

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...

Related from a few months ago: https://news.ycombinator.com/item?id=23070821

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.

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

Im using https://github.com/olekukonko/tablewriter in Go.

Those progress bars look delicious

I agree.

Also: My kingdom for rsync with progress bars.

--progress ?

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.

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.

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

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.

Is this using ncurses?

doesnt seem so

https://github.com/willmcgugan/rich/blob/master/rich/console... shows that's it's directly using escape codes: http://ascii-table.com/ansi-escape-sequences-vt-100.php

looks like it hardcodes escape sequences with no regard to the current terminal.

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.

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?

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-termi...

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...

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.

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

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

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

You can, the instructions are here: https://rich.readthedocs.io/en/latest/traceback.html

But it is noticeably slower than the default python handler

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.

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.

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

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.

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

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.

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.

ssh, mosh

xwindows, rdp, vnc

Reply on news.ycombinator.com