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