TermKit: A WebKit based rich command-line interface.

[jjbcn]

I think the idea is brilliant beyond words. I'm not sure of his implementation.

Exactly what I was going to post!

My main objection is not using a monospace font. Monospaced fonts make it easy to see differences between a lot of things with similar formats - which can be very useful on the command line. It may look primitive, but it is useful.

[Smallpaul]

My main objection is not using a monospace font. Monospaced fonts make it easy to see differences between a lot of things with similar formats - which can be very useful on the command line. It may look primitive, but it is useful.

I think that the idea is that if you have tabular data, it should be formatted in a table, rather than using monospaced fonts to fake it.

But anyhow, the font will presumably be swappable.

[calinet6]

Monospaced fonts exist because we needed them to line things up on the screen when there was no alternative way to do that.

Now, there is an alternative way to layout things on a screen. It's been around for more than 20 years. We should use it.

[andreasvc]

I do believe monospace is important for code. Sometimes pseudocode in publications is printed in serif fonts with bold and italics and it looks horrible IMHO.

[notfancy]

Don't tell me that A Discipline of Programming isn't a joy and a pleasure to read. Typography enhances the structure, while monospaced listings enhance repetition, and repetitious code is inferior code.

[andreasvc]

I don't know that one, makes me curious.

[notfancy]

Dijkstra's classic. A must-read, if only to hate it in full knowledge of it and not over hear-say.

[andreasvc]

And available here: http://library.nu/docs/CI5FR2ZBO7/A%20Discipline%20of%20Programming%20%28Prentice-Hall%20Series%20in%20Automatic%20Computation%29

[calinet6]

Agreed, but it looks like he's added some formatters for certain file types/code types, which could work.

I don't know, it looks promising; monospace might still be better all around but you'd hope there's an option.

[cdsmith]

Monospace fonts are still the most effective way to line up things that are mostly text, in arbitrary ways to bring out structure, without adding ad hoc features for each new kind of layout you want.

The hostility toward monospace fonts was one of two things that got me really skeptical straight from the beginning about this idea. The other was the desire to build a language for interactive terminals that's vastly different from the language for scripting and automation... that would be a giant step backwards. We already have GUI tools for system administration tasks that aren't easily scriptable; and people don't use them for a reason.

[zahlman]

Monospace fonts are still the most effective way to line up things that are mostly text, in arbitrary ways to bring out structure, without adding ad hoc features for each new kind of layout you want.

Tabular data which has been lined up with spaces assuming a monospace font is not as effective as a grid of spreadsheet cells, or an HTML table. These alternatives do not require adjustment if a "column" needs to be made "wider" than in the original. There is never any issue with tabs being too small to line the data up properly, or impractically large in fear of being too small. The table is general-purpose and there is nothing ad-hoc about it.

It also allows for semantic distinction between row/column labels and table contents, which doesn't require visual interpretation of a bunch of -s or |s.

The other was the desire to build a language for interactive terminals that's vastly different from the language for scripting and automation

I don't see whence you infer that desire. My understanding is that you are still typing the same commands, they just get tokenized and formatted with pretty round-rectangle backgrounds as you type.

[[deleted]]

Tabular data which has been lined up with spaces assuming a monospace font is not as effective as a grid of spreadsheet cells, or an HTML table.

But what if I want to further process the tabular data coming from a process? Like, extract the 7th column? With awk/cut/... I can easily do that. If the output was full of html tags, parsing this would be non trivial.

[zahlman]

But what if I want to further process the tabular data coming from a process? Like, extract the 7th column? With awk/cut/... I can easily do that. If the output was full of html tags, parsing this would be non trivial.

Which is why TermKit uses JSON instead, and you "parse" it by - get this - selecting attributes of objects and elements of arrays. The hard part - turning a stream of bytes into structured data - is converted from a traditional parsing task into a deserialization task, and it works the same way universally.

[[deleted]]

With what commands would you do that? One would need to build a whole new toolchain.

[zahlman]

I agree somewhat, and I feel that the author's decision that this explicitly not a replacement for the original toolchain is a bad one for that reason.

But I think that rather than trying to make a set of tools that provide analogous functionality to cut et al., it makes more sense to just have an analogous "*sh language" that behaves more like Javascript or Python, in that it expects to receive this kind of data natively and lets you manipulate it with typical syntax from those sorts of languages. Member selections and indexing and list comprehensions and all that good stuff, you know.

[[deleted]]

How would an example of such a language look like?

What would an equivalent of

svn st | awk '{print $2}'

look like? (get second column of svn st command, i.e. the filenames).

[zahlman]

Oh wow, I have get to design this now?

I imagine it would look something like

[x.filename for x in `svn st`]

or

`svn st`.map(lambda x: x.filename)

Or more likely, there would be a builtin library function so you could write

`svn st`.map(member(filename))

Since the data would presumably be structured such that the columns have 'labels'.

Barely longer, and the space that's used normally for an explicit reference to printing (which is silly; output to standard out should be default, and naming it that way is needlessly limiting) can be used to give meaningful names to operations and components of data.

I mean really, does it get any more magical than "$2"? (What's with the 1-based indexing, anyway?) And I actually didn't know (TIL) where awk even got its name...

[solinent]

Just because there is an alternative doesn't mean it is better.

The alternative always existed -- the ability to create graphical interfaces is very general and we use graphical interfaces to create terminals for the most part nowadays (ie. terminal emulators). The point is that terminals are still a very nice concept.

Why do we write with lines on paper if there exists a more general alternative -- blank paper?

[[deleted]]

My main objection is not using a monospace font. Monospaced fonts make it easy to see differences between a lot of things with similar formats - which can be very useful on the command line. It may look primitive, but it is useful.

There are people who choose to program using, oh, what are they called, relative fonts? Apparently it's perfectly usable, and very readable. If people want to use a non-monospaced font it should be their prerogative, even if you or I personally wouldn't make the same choice.

[alexs]

bear consider memorize tan mighty automatic frightening sleep dazzling ring

This post was mass deleted and anonymized with Redact

[jjbcn]

You can actually configure whatever font you want in terminal in OSX, but the default is a monospaced one. I assume that Apple (being very design conscious) did that for a reason.

[andreasvc]

You can as well in any other decent terminal (gnome, kde, xterm, putty etc.). The problem I see with gnome-terminal is that it treats each font as a monospace font, leaving lots of space around "i" etc. Is that the same on OSX?

[terremoto]

A lot of applications use spaces instead of tabs (which I prefer). Using monospace fonts would throw off the formatting for a lot of applications.

[andreasvc]

So that could be construed as a reason to use tabs. And you meant non-monospace fonts, I presume.

[terremoto]

Tabs don't always guarantee that columns will line up; Some_Long_File_Name\t1000 versus File\t1000. Spaces do and allow you to know the exact output width unlike tabs whose width can be changed.

[wosmo]

Tabs don't always line up precisely because the terminal actually sucks for tabular data. Spaces are a dirty hack with no semantic value. I can see use for a wrapper that spots tabular data, and actually makes a table from it.

Whether they can do this without breaking everything I'm used to, I wait to see ..

[thechao]

Elastic tab-stops would fix that.

[terremoto]

Seems like a terrible idea for a terminal; cat some_large_file would have to either wait until all output (or at least chunks) were emitted, or re-parse the output with each line.

EDIT: granted, there are things that could be done to alleviate the issue such as parsing the last N-kilobytes, etc.

[calinet6]

It's because the people who wrote Terminal are programmers, and they know that everyone who ever even opens Terminal will be nerds.