I wholly agree that splattering chrome over a terminal isn't the best way forward. Emacs shell mode gets me all?most? of the way to the interface posed as the solution (text editor as interface to terminal). Being emacs, I am sure I could finish up the proposed solution with "a few lines of elisp".
And I don't think it's the solution. These issues are spawned deeper in the design. Multiple streams of information are being spawned, and must be handled sanely: pipe redirection starts breaking down here because it's a line - what's needed is a graph of management that's able to handle different cases and join back for the next approach.
One approach might simply be to develop a higher-powered programming language environment that calls directly into the system.
Emacs shell mode was my first thought too. It doesn't try to implement a new standard for pipes, though. The idea of using invisible control characters as metadata is interesting.
(My biggest complain about shell mode is that it's impossible to send certain characters to the underlying process, TAB being the most important one, so you can't rely on built-in tab completion behavior.)
Windows Powershell attempts to do what you're describing. PowerShell doesn't manipulate text streams, it manipulates .Net CLR objects. That allows shell programs to expose data in a much more meaningful way. You don't have to have a parser in every program that interacts with the shell when you can send and receive typed data.
I haven't worked much with it lately, but I wouldn't be surprised if Powershell was the closest existing technology to what the author is thinking of.
I think he agrees, except for the textual display.
From the article:
Data structure. Windows PowerShell had a chance to
redesign the terminal from scratch, but defaulted to
the same old grid of ASCII. One innovative thing they did
do was add structure to their data, piping .NET objects
instead of raw text, allowing the user to select fields by
name instead of writing elaborate AWK scripts. The shell
for the research OS Famke does a similar thing for
higher-order functions
I didn't quite get where the author was going with that. Windows Powershell has access to the full Windows .Net API. If you want to spawn a window to display graphics or what have you, you're free to do so.
You can already side-chain data flows with file descriptors. You can solve more complex problems with temp files and tee. I can't really imagine that making me use a GUI to select where to pipe what would be more efficient. Most of the time, when people have problems that require complex data manipulation like this, they'll jut use their favorite scripting language.
There is also not much stopping you from using PHP, Python, Ruby, or anything else with a REPL as your daily shell, but bash is the most popular and works quite well for this problem domain.
Not to sound like an old dude stuck in his ways, but there is a reason that we're still all using VT 100 and 220 emulators from 30+ years ago -- they work great.
"Not to sound like an old dude stuck in his ways, but there is a reason that we're still all using VT 100 and 220 emulators from 30+ years ago -- they work great."
No, they don't. Really. Look at the source code to ncurses and see if the millisecond timing loop around select() is still there, to distinguish between a terminal sending ESC[1D in response to you pressing "left cursor" and a human pressing "ESC" "[" "1" "D" very quickly :-)
It sucks. Windows got this right a long time ago, to the extent that the left & right modifier keys are distinguishable. Try doing that on a VT100.
Of course, a REAL VT100 doesn't have half the keys ; F1-F4 (IIRC) aren't sent "over the wire" and have no standard encoding. Linus basically invented one for the "linux" console terminal type, and lo yet another "standard" was born.
And don't talk to me about shells. The lunacy that is never quite knowing what insane metaquoting scheme you'll need today based on which arcane shell some moron has configured as the default for THIS particular machine is EXACTLY what the top-voted Koan is about.
> There is also not much stopping you from using PHP, Python, Ruby, or anything else with a REPL as your daily shell, but bash is the most popular and works quite well for this problem domain.
You can already side-chain data flows with file descriptors. You can solve more complex problems with temp files and tee. I can't really imagine that making me use a GUI to select where to pipe what would be more efficient. Most of the time, when people have problems that require complex data manipulation like this, they'll jut use their favorite scripting language.
There is also not much stopping you from using PHP, Python, Ruby, or anything else with a REPL as your daily shell, but bash is the most popular and works quite well for this problem domain.
Not to sound like an old dude stuck in his ways, but there is a reason that we're still all using VT 100 and 220 emulators from 30+ years ago -- they work great.
The concept of a view and a controller are distinct, a terminal simply happens to be both, because it can do both. Commands are solely controllers, and you're right, a read-only terminal would be just a view.
Most unixy programs actually do have them divided. stdin, stdout (and a third for stderr). It would be very easy to separate the streams to different places.
ETA at the last place I worked, we actually had the touchscreen on one desk and the program running in a window on another computer. It was pretty nice to type something and make it show up across the room.
On this topic of stdin, stdout - wouldn't it be neat if - instead of signals - there was an input channel called stdctrl that you could send control messages in on.
Glad to read about the scenario at your last place - I've never seen this in action.
Well, it's not exactly what you describe (which does sound kind of intriguing), but Linux does offer the signalfd(2) syscall, which allows you to read signals from a file descriptor. Doesn't do much for the sender of said signals, however.
At AOL circa 2000, our application framework had a Tcl interpreter listening on a "control port", so that you could telnet to any app and get stats, change settings, etc.
Of course, nowadays that's more commonly done with REST endpoints, which I think would satisfy your stdctrl idea.
Well those are just the defaults, a program can open a lot more sockets if it wants to. IPC is an old problem with a lot of pretty good solutions by now.
The author confuses a terminal with a shell running in a terminal.
I'd like for my terminal to be able to open a stream of html in my web browser. Use case: running `man blahblah` in a ssh session opens a nicely formatted page in a local browser window.
I'd like for my terminal to be able to open a stream of text in my editor, and accept a stream of text back from my editor to save somewhere. Use case: running `sudo -e /etc/blahblah` in a ssh session allows me to edit the remote file /etc/blahblah in a local text editor, and save my changes back.
Sometimes when I have text files open I want to be able to run command line tools against them. I know I can go write a shell script but sometimes I want to write grep against my inbox or against all the windows I have open at the time. I want to be able to high lite some text (possibly in more than one window) and then have a transparent shell appear that lets me write expressions to work with that text, like sort it in place. Often I have to move things into and out of text files, spreadsheets,databases to be able to apply all the tricks that I like. I wish those tricks could just appear and work with what I'm looking at.
I have used emacs before and I did like having multiple shells open and the ability to copy many text fragments into the buffer. I use windows for my day to day work so I'm thinking about something more geared to that.
I want to be able to take the the best features from the command line, and the gui programs and package them up into something that just floats at the OS level. So that I use a keyboard shortcut to pull up a buffer that can grab text (or entire files) work on them and push the results back to whatever app/file I pulled it from.
That looks really interesting. I'm going to install it when I get home. If I'm able to be looking at a text file, launch DTerm with a keyboard shortcut, run something that modifies the file in place, and then have DTerm fade away then that will definitely be useful.
You also execute a selection with ":w !sh". For example, if I have a line that says 'echo "Hello, world!"' I can select the line with Shift-V and then ":w !sh" to execute the line in the shell. Works with other interpreters too so ":w !perl" would execute it in perl. The vim command should show "'<,'>" between the ':' and 'w'. Using it without selecting something first sends the whole buffer to the interpreter.
It's a motion command that means from the beginning of the selected area to the end. It's really two different commands ("'<" and "'>") and there is a good description of them in the vim help (":help '<" will bring you there).
"And we, the users, play along, pretending our machine is a video terminal presenting a grid of ASCII characters in all of 256 colours. This is ridiculous."
Not everybody uses their terminal to churn out HTML pages and add 'Nyan mode' to our 'newly discovered' emacs program. For those who do that, just buy a Macintosh or whatever is this week's hip flavor of Best Buy PC. Otherwise, use a language that doesn't require >256 different colors to be represented meaningfully.
"Typography is the future"? Thank goodness X.org/XFree86 has supported custom fonts since the 1990's.
"Opening a man page would scroll gently to the top of the page, letting you scroll down and read, or search through it as you would any text"
See: MANPAGER.
"We then add syntax highlighting and hyperlinks, so you can easily navigate between man pages"
Many terminals and shells support these features already.
"Finally we add visualisations so you can view plots of lines of code, etc., without having to context-switch."
Huh? I read that as 'code folding' and clang compilation.
I think the main takeaway here is that most of his "ideas" can be easily achieved within the current ecosystem of available programs, most of which are stock on modern UNIX-like OS distributions. I do think he misfiled this article under "Ideas"; it's more akin to a polite rant.
edit: colours/color killed due to conflict with reality (and irrelevance anyway).
You don't seem able to see the forest for the trees... Taking quotes out of context and dismissing them is not sufficient to dismiss the entire article.
All quotes save for one-liners are out of context. The points you make stand on their own.
I don't dismiss the entire article; I appreciate thought and innovation in the space of the terminal, but I disagree with your ideas. Thanks for putting them out there to begin with.
I see the context-switch as one between text and graphics.
If I'm working on the command line, then most times I have no need to have X11 running. I'm working exclusively with text.
I can boot to a command line and start working. No X11 is needed.
But when a need arises for graphics, e.g., to read a PDF composed of scanned images (not pure Postscript), then I have to "context-switch" to the X11 context.
I find that switching back and forth between these two contexts is not smooth and can easily lead to instability.
There is often a presumption, as in Plan9, that we will just switch once: to the graphical environment. And not return to the original console.
To me, neither an X11 terminal emulator nor the Plan9 environment is "the console". It's another layer of abstraction on top of the console.
That is a lot of overhead I do not need if I'm just working with text.
Sort of. But you have to keep X11 running on another vt. Stopping and restarting X many times in a session is a different story. At least for me.
And even in the case I keep X11 running on another vt, I've found that when using no wm, or a simple one like evilwm, switching back and forth from console (on one vt) to X11 (on another vt) many times does not work well. Eventually it fails.
This is on {Net,Free,Open}BSD.
I don't think that Plan9 has vt's as such. It's more like what the article envisions, with graphics capabilities seemingly woven into the terminal. But you're pretty much stuck in an X11 type environment. Plan9 experts correct me if I'm wrong.
I've always found this "context switch" from console to graphics is like a one-way street. You're not really expected to keep shutting down the graphics and going back to the console. At least I've never found anyone who does that.
I'm a NetBSD user that uses a tiling window manager (i3 - not ion3, it's different). ALT+1 and ALT+2 are where I keep my urxvts, ALT+3 my web browser, etc. The switch happens instantaneously.
Am I mistaken in my understanding of your issue, or is this helpful?
Yes, it works well enough if you keep X11 and your X11 apps running. But what I'm striving for is a little different. More lightweight. Graphics and graphical apps are only launched when they are needed. X11 is not running constantly.
I have not tried i3 and I'm going to give it a go.
Are you ever keen to chat with another NetBSD user off HN?
No downvote, but I believe its worth thinking about ways to advance power-user use beyond the emulation of teletype machines (first deployed in 1910). It may be that they are the optimal power-user text interface, but it may also be that they simply occupy a local optima and we need to keep searching.
Reading the introduction, I was really excited. I fully agree with the premise, but the proposed solution seems inadequate. Putting shell in an editor, adding hidden metadata, and making the output hyperlinked just don't feel radical enough.
Also, some parts of the proposal are very vague (description of MVC), while others are extremely specific (whole paragraph about an obscure Unicode delimiter), which makes it hard to get the big picture. That said, improving the terminal is a really challenging and important problem, so I'm glad there are people thinking about it.
> improving the terminal is a really challenging and important problem, so I'm glad there are people thinking about it.
People thought about it 20 years ago, not only about the terminal, but about improving UNIX in general. And not just any people, but the people that did UNIX and C in the first place. Their effort is called Plan9.
Very few people have heard of Plan9 and of those people even fewer used it to the point of understanding the novel ideas.
I use it. Even when I am forced to use UNIX I still use the Plan9 tools along with the Acme and Sam editors. Once you get used to the new Plan9 ideas, you feel crippled in UNIX and can never go back.
> Once you get used to the new Plan9 ideas, you feel crippled in UNIX and can never go back.
Would you care to expand on this? Any specific examples of things that Plan9 does for you that you feel crippled without? I ask out of genuine curiousity, as I've often heard Plan9 mentioned but have never given it enough research to understand its appeal.
For example, I'm a full time web developer and I spent a lot of time in zsh and vim. Would you recommend that someone like me checks out Plan9? Is it the type of thing you could possibly use as your general purpose OS?
I'm using Acme for web devel. Yields very well to scripting. Together with plumber and a few scripts, it provides pretty much a complete IDE. The ability to simply click on any text to 1) execute it or 2) search for it or 3) copy/paste/replace is something that I miss from other editors. Essentially, any text becomes hypertext. Output from compiler or debugger links you to source files etc.
Aside of that there's a big chunk of remote filesystem access ported from Plan 9, but I haven't used that yet.
Yes, I really liked that project and I think the design is fantastic (it leverages WebKit for rendering).
Both TermKit and this project will have an interesting dilemma with editing remote files though. The advantage of SSH is that you really aren't storing any remote files locally (only the currently visible characters are stored in memory). An editor that uses this new model and eliminates lag requires transfer of remote files to the local computer. There are a lot of situations where this is not a viable option.
A very good point. My prototype protocol, rwr, reads only the data in the file it has to know. Additionally, when one inserts a character it simply says "insert 'a' at byte 4", rather than having to stream the entire file. That's another benefit of running filesystem models as daemons on remote servers.
Kind of off topic, but this article just reminded me, I was thinking how nice it would be for a linux distro to be made for programmers. Bundled with every bit of programming language (from c to hakell and back), the standard editors with their syntax highlighting (the .vimrc already set up a little), cool special tools that maybe only serve a special purpose (stuff like gnu radio..) I was just thinking it'd be nice to have one big package, a here ya go, have at it, kinda linux. Maybe even with some alternative (but vetted) how-to documentation. For some reason I just can't get used to the flow and syntax of Man pages... And it can leave out lots of the fancy gui sidebars and stuff (not sayin get rid of the gui, just dumb it down, I'm here for the terminal, and maybe some IDEs.. maybe).
Read the koan in the above comment again. Your vision of a Linux distribution "for programmers" is very likely different from my vision, let alone that of Dennis Ritchie or Linus Torvalds. This approach is the fundamental mistake made by other operating systems: to assume you know what the user wants/needs, and give it to them in one nice shiny box with a bow on it. It would be so convenient... right?
The core philosophy of Unix is to build tools that do one job well. By combining those tools, it is then possible to build great things. Do not assume that means you can hide the tools away and just give people the great thing, and realize it is naive to believe that you can solve everyone's problem by creating the one true master editor/program/os that combines all the great things from previous attempts, but this time "gets it right".
I'll answer with a Koan, it's author long forgotten (if you know him, do tell me his name!):
A UNIX wizard hears cries of torment from his apprentice's computer room where the apprentice is studying, and goes to investigate.
He finds the apprentice in obvious distress, nearly on the verge of tears. "What's the problem?" he asks. "Why did you cry out?"
"It's terrible using this system. I must use four editors each day to get my studies done, because not one of them does everything."
The wizard nods sagely, and asks, "And what would you propose that will solve this obvious dilemma?"
The student thinks carefully for several minutes, and his face then lights up in delight. Excitedly, he says, "Well, it's obvious. I will write the best editor ever. It will do everything that the existing four editors do, but do their jobs better, and faster. And because of my new editor, the world will be a better place."
The wizard quickly raises his hand and smacks the apprentice on the side of his head. The wizard is old and frail, and the apprentice isn't physically hurt, but is shocked by what has happened. He turns his head to face the wizard. "What have I done wrong?" he asks.
"Fool!" says the wizard. "Do you think I want to learn yet another editor?"
I'm not feeling immediately enlightened. The existence of a program doesn't inconvenience anyone. No-one has to use it if they don't want to. That wizard needs to chill out and not get so upset about people kicking ideas around.
No one has to use it, but someone has to decide not to use it. A major concern with newcomers to many, many systems in a wide variety of markets is what option to pick. Most go with the default, which reinforces that default but doesn't necessarily fit their needs. They do this because the choice is overwhelming.
I trust users who know how to use the shell to be able to decide what suits them best and to not be paralyzed by indecision between their system's default terminal emulator and some guy's obscure hobby terminal system.
I was specifically calling out the text editor comment of your parent, but there are many different choices for shells.
Bourne, ash, bash, dash, ksh, mksh, zsh, csh, tcsh, rc, GNU Screen, etc, Each of them has a slightly different featureset. You can go with the default of bash and it could work out very well for you, but you'd be turning down potentially better alternatives. You seem pretty derisive towards hobbyist projects for a site called "Hacker News". That hobbyist project could be the best thing you've ever used, but you'll never know. That was the entire point of my original post.
I did not imply that the default thing is necessarily better than hobby thing, but that someone who knows enough to know what a shell is knows what they want and how to get it. And if they made a poor choice, so what? It's easy to change one's mind.
Scrutinizing an idea for a new method of programmer-computer interaction from the perspective of a newcomer makes little sense to me, as does the "competing standards" thing from a neighboring comment, scrutinizing OP's idea for being potentially unable to win a popularity contest. OP's terminal system isn't a standard struggling to gain widespread public acceptance. It's just some guy's program.
I think that an idea about programmer-computer interaction ought to be scrutinized for its merit in facilitating programmer-computer interaction, and that criticism from a perspective that isn't the programmer's and isn't the computer's is useless.
PS. You forgot one of the most interesting Unix shells, es. It could turn out to be the best shell you've ever used.
Standards compete on many levels on a give-and-take basis and have very strong incentives to have a minimal amount of complexity. Text editors don't suffer from that set of requirements. This hypothetical editor does everything the others do, cleanly. Almost everyone will agree that it's better. To my eyes the only real problem is that creating the program itself is infeasible.
I disagree. There are already many text editors that do everything each other do, but they all do it differently, some in GUI some in command line, some with different shortcuts, etc. You could argue that Eclipse does almost everything and has a very high level of extensibility and yet you won't get me or many people I know to use it for most tasks.
It's not just about some checklist of possible actions it can do. It's about workflow, ease of use, integration with the larger jobs.
It's more similar to the "standards" argument than you give it credit for.
Other wise everyone would use emacs or eclipse.
Hypothetical is the key here. Everyone can dream up a perfect system, but in the real world, it will have to make compromises, which means that it won't be perfect for everyone.
The joke is that those four text editors mentioned by the student are also the result of someone one day attempting the impossible goal of creating the perfect tool.
The stance it's pushing is "understand the reasons why the tools before you are limited, and give some thought into the deeper reasons why you would want to create a new tool. Don't just rush headlong into it"
Yeah, how dumb and harmful that is, asking people to think before acting.
That would be the stance it pushed if it actually had anything revelatory to say about that idea, or if it wasn't trotted out mindlessly every time someone started work on a new tool. As it is, it's just hidebound smugness.
The "UNIX way" isn't to write a better editor, it's to use an editor that interacts well with other tools (i.e., the tools we already have at the command line.)
Weak typing and implicit coercion are not the same thing. They're not even close to the same thing. Haskell does (things equivalent to) implicit coercion when it adds a floating-point Number to an integral Number and nobody (sane) says Haskell is weakly-typed.
Haskell uses type inference, but that's not the same as implicit coercion, which Haskell explicitly avoids. That is: if you type
4 + 4.2
Then the compiler will infer that you mean
(4::Fractional a=>a) + (4.2::Fractional a => a)
However, you cannot add an integer and a float:
(4::Int) + (4.2::Float)
Couldn't match expected type `Int' with actual type `Float'
In the second argument of `(+)', namely `(4.2 :: Float)'
In the expression: (4 :: Int) + (4.2 :: Float)
In an equation for `it': it = (4 :: Int) + (4.2 :: Float)
This follows from the type of (+) :: Num a => a -> a -> a
Haskell uses type classes to support ad hoc polymorphism, or overloading. Consider the statement:
(4.2::Fractional a=> a) + (4::Float)
Float is an instance of the type class Fractional. That is: methods which are defined for all fractional types must be defined for floats.
The compiler infers that (4.2::Fractional a=>a) must have type float, as it is being added to a float.
This is compatible with the original type of the expression, as Float is an instance of fractional, so it is valid to read 4.2 as a Float.
There are some interesting ideas here. One thing that occurred to me while reading it was using a message queue to implement the pipeline functionality. I've been interested in Apache ActiveMQ/Camel for a while now and excited about some of the things it can do. With that model, each 'line' could have it's own set of headers, allowing for transformation by aware tools, but transparent by default. This would also blur the line between running commands and having background filters. It would also work nicely over the network.
I did some experiments with clojure/camel at one point, and came up with stuff like this:
Which is basically a continuous file copy. I could see different flags for "do now and exit", "do at HH:MM:SS", "do until I tell you to stop", "do when system is idle", etc.
I'm not sure what you'd really gain from using a message queue. Pipes with streams seems to be lower overhead and could be extended pretty trivially to get most of the functionality you'd want.
I am skeptical about total reimaginations, and when I read this I started to take it as one of those airy "Dude, someone totally revolutionize this for me..." posts, but then I hit:
I’m working on this in my spare time, starting with...
and now I'm curious to see what the author comes up with.
There's just something about an actual tool, no matter how prototypical, that improves the discussion of new tools.
Here's my six-year-old rant about how crufty terminal technology is. It's not a visionary re-imagining of terminals like this article is, but personally I think that one of the biggest barriers to innovation in terminal technology is that the current stack is so incredibly baroque and difficult to program or extend elegantly.
This made Unix so reliable. If you want to write a beautiful terminal as _addon_ I have no problem with that. But I would not accept a _replacement_ of the old fashioned terminals. Because they are so simple, they just work.
Meanwhile, it took Unix forever before the PC's backspace key 'just worked'.
The terminal guts are unbelievably gnarly, and it's kinda surprising it hasn't been replaced with a simpler approach designed for virtual terminals by now.
Please don't forget that the terminal should be useful to just get work done without programming. It's also all designed to have a human interface - all the output can be grok'd by a human and not some complex tool or parser. This is what prevents things from just magically working and forces us to come up with hacks to pipe and grep and cut pieces of data to do what we want.
If you really want to "reimagine" it, throw out the box and make a new one. If you redesigned all the standard unix tools to have a universal API and added hooks for each function they contain you could just specify a workflow to execute and the tools would figure out how to transmogrify the data internally. So for example:
Not the greatest example but you get the idea. If this seems more complex than traditional one-liner scripting it's because you're trying to do a lot of little things on a single line. It may be better to shove all this into a little file in easy to understand non-programmer language and save it for later. (Also, the long GNU options could be replaced by short options for quicker use, depending on the API/module being used)
This is obviously not getting away from the 'old school dynamic' of a fake terminal, but it does remove some of the need for it when we have tools robust enough that the terminal doesn't have to be as user-friendly as it is. You could combine a tool/framework like the above with a text editor to write multi-liners, sample the output and execute them on the fly. Build in hooks to execute commands over an ssh connection - or even gather output from various hosts at a time - and you could automate sampling your whole network from a one-liner.
For a "friendly interface" I think a simple tree view file browser would work nicely. So basically an "explorer"-type app with an embedded text editor and output window to let you explore a system rapidly and also automate tasks on the fly. Hell, you could build an IDE or other friendly GUI to build your query tool's arguments using quick mouse clicks.
The idea of using an obscure unicode code point to indicate the start of metadata, in the expectation that nobody will use it, is probably self-defeating. As soon as that's is use, there will be a reason to use that obscure code point (in documentation, in code, etc), so you will still have to deal with escaping it.
You'll have to deal with escaping it, but you won't need to escape as often, and may never need to escape if you aren't writing code/documentation dealing with the system itself.
This is one of the rare delightful articles. I came to understand, after 6 years of non-programming work, and now back in front of the console, that what I like the most is the freedom that the shell provides and the room for creativity when accomplishing a task in a readable composition of tools in one line.
Certainly the provided successors of the Bourne shell might be more elegant. Certainly when piping data through several tools needs often transformation of the data representation to match the required input format. Sometimes the transformation uses different principles (regular expressions, shell wildcards, awk, sed, ..) which pollutes the logical flow of problem resolution. But I came to the conclusion that despite not being optimal, this data transformation noise holds information that, when reading or when needing to explain to others, helps to understand, or maybe remember the data model from the source to the sinks. However I believe, more uniform but more universal data transformation techniques would be a progress.
Until now this comment is more about shell than terminals, but for me, these are the biggest advantages of working on a command line - freedom and creativity in the usage of available tools.
Now, to come closer to the terminal aspect.
I am a typing fan. I went through hell when moving from Germany to France and having to re-learn a new keyboard layout - none of the both layouts are good, but if you are used to one it is very annoying to get to used to another. After having had some missions in other countries with different keyboard layouts, I found a solution, that is in line with my philosophy of using typing tools: Learn US keyboard layout, to the point to use it blindly without needing letters on the keys - it is installed on all OSes in all countries. At home use the extension US International with AltGr dead keys - I can now write all German, French, Turk and many other Latin based accents with a single layout. When in mission at a customer I ask if in the open session I can switch to US layout (if needed) - until now there were only some raised eyebrows, but no objections. And at least for ThinkPads you can order them with US layout, even with the € sign. So for keyboard I tackled the problem.
For text editors I resolved the problem already 10 years ago. I use VIM. VI is on all UNIXes, VIM is on Windows (I did not yet have to work on Macs).
On the UNIX shell the first thing I type is: set -o vi
Like this many VI shortcuts and commands are at the command line.
One quote in the article made me smile the most:
"... However, it’s worth noting that we don’t avoid the mouse because it is slow — if one wants to move the cursor to an arbitrary location elsewhere on the screen, one can often do so faster with a mouse than a keyboard. The problem is the transition from the keyboard to the mouse. It’s an expensive context switch, which should not be done lightly. ..."
Yeah, this is the reason I use a track point instead of a mouse. Nothing to care with you, takes no space and you don't have to lift your hands from the keyboard. The only problem is the craving when having to sit at a customer at a keyboard that has not track point - I find myself sometimes searching for it with the fingers until I realize that I am not on my ThinkPad. It is a shame this device is disappearing on most computers.
At last: I think what unites the aficionados of the command line is the choice to spend more effort and time in learning tools which are more difficult than their alternatives (mouse vs. track point, command line vs. GUI, ten finger typing vs. two finger typing) at the beginning but pay big times off in efficiency in the long run and as a plus give the pleasure of creativity and freedom.
I encourage the author of the article to progress with his ideas! We absolutely need innovation in this space. It is just that the bar is huge because of all the tools we became used to.
> Yeah, this is the reason I use a track point instead of a mouse.
VIM + touchpad beneath space bar on a standard laptop works well too. I can left\right click with my left thumb and move the cursor with my right thumb without my primary digits leaving the home keys.
(a) a good track point is ways more precise than a touch pad
(b) to cross the screen from one corner to another on a touch pad you have to make several strokes, whereas with a track point you don't have to leave the device a single time
I agree that there is too much focus on "intuitiveness," but I'm neither a programmer (I'm working on it) nor a sysadmin, and I'd like a more robust user interface too! I have a lot of work to get done, and I'm willing to learn a different set of interface axioms than the ones we've been working with for the last few decades.
158 comments
[ 4.6 ms ] story [ 171 ms ] threadFun fact: Acme was Dennis Ritchie's editor of choice.
And I don't think it's the solution. These issues are spawned deeper in the design. Multiple streams of information are being spawned, and must be handled sanely: pipe redirection starts breaking down here because it's a line - what's needed is a graph of management that's able to handle different cases and join back for the next approach.
One approach might simply be to develop a higher-powered programming language environment that calls directly into the system.
(My biggest complain about shell mode is that it's impossible to send certain characters to the underlying process, TAB being the most important one, so you can't rely on built-in tab completion behavior.)
I haven't worked much with it lately, but I wouldn't be surprised if Powershell was the closest existing technology to what the author is thinking of.
From the article:
There is also not much stopping you from using PHP, Python, Ruby, or anything else with a REPL as your daily shell, but bash is the most popular and works quite well for this problem domain.
Not to sound like an old dude stuck in his ways, but there is a reason that we're still all using VT 100 and 220 emulators from 30+ years ago -- they work great.
That's a fascinating idea. Know of anyone who does that?
No, they don't. Really. Look at the source code to ncurses and see if the millisecond timing loop around select() is still there, to distinguish between a terminal sending ESC[1D in response to you pressing "left cursor" and a human pressing "ESC" "[" "1" "D" very quickly :-)
It sucks. Windows got this right a long time ago, to the extent that the left & right modifier keys are distinguishable. Try doing that on a VT100.
Of course, a REAL VT100 doesn't have half the keys ; F1-F4 (IIRC) aren't sent "over the wire" and have no standard encoding. Linus basically invented one for the "linux" console terminal type, and lo yet another "standard" was born.
And don't talk to me about shells. The lunacy that is never quite knowing what insane metaquoting scheme you'll need today based on which arcane shell some moron has configured as the default for THIS particular machine is EXACTLY what the top-voted Koan is about.
This is relevant: http://stackoverflow.com/q/3637668/336455 In short, there are some objective reasons, not just popularity.
There is also not much stopping you from using PHP, Python, Ruby, or anything else with a REPL as your daily shell, but bash is the most popular and works quite well for this problem domain.
Not to sound like an old dude stuck in his ways, but there is a reason that we're still all using VT 100 and 220 emulators from 30+ years ago -- they work great.
Edit: or for a gui, something like Enso (for the whole OS) http://humanized.com/enso or Ubiquity https://wiki.mozilla.org/Labs/Ubiquity/Latest_Ubiquity_User_... (for the browser) Both are abandoned open-source projects with a lot of the hard work already done (the internationalized parser in Ubiquity is very nice).
You might type into a tiny window on one monitor that never loses focus, but sends graphs and text and streams to these windows.
There's no reason that the place you enter text should correspond to the output display, and a lot of value to be had by separating them.
Imagine being able to plug display consumers into a port so that you could do visual demos.
ETA at the last place I worked, we actually had the touchscreen on one desk and the program running in a window on another computer. It was pretty nice to type something and make it show up across the room.
Glad to read about the scenario at your last place - I've never seen this in action.
Of course, nowadays that's more commonly done with REST endpoints, which I think would satisfy your stdctrl idea.
I'd like for my terminal to be able to open a stream of html in my web browser. Use case: running `man blahblah` in a ssh session opens a nicely formatted page in a local browser window.
I'd like for my terminal to be able to open a stream of text in my editor, and accept a stream of text back from my editor to save somewhere. Use case: running `sudo -e /etc/blahblah` in a ssh session allows me to edit the remote file /etc/blahblah in a local text editor, and save my changes back.
http://www.sublimetext.com/
http://www.masteringemacs.org/articles/2011/10/19/executing-...
I want to be able to take the the best features from the command line, and the gui programs and package them up into something that just floats at the OS level. So that I use a keyboard shortcut to pull up a buffer that can grab text (or entire files) work on them and push the results back to whatever app/file I pulled it from.
Yup, via `!` and `r!`. See, for example, http://www.oualline.com/vim-cook.html#format_para.
I've always wondered about this; I sometimes get it (but don't know how to reproduce it) when trying to navigate. What does it mean?
https://en.wikipedia.org/wiki/Services_menu
Not everybody uses their terminal to churn out HTML pages and add 'Nyan mode' to our 'newly discovered' emacs program. For those who do that, just buy a Macintosh or whatever is this week's hip flavor of Best Buy PC. Otherwise, use a language that doesn't require >256 different colors to be represented meaningfully.
"Typography is the future"? Thank goodness X.org/XFree86 has supported custom fonts since the 1990's.
"Opening a man page would scroll gently to the top of the page, letting you scroll down and read, or search through it as you would any text"
See: MANPAGER.
"We then add syntax highlighting and hyperlinks, so you can easily navigate between man pages"
Many terminals and shells support these features already.
"Finally we add visualisations so you can view plots of lines of code, etc., without having to context-switch."
Huh? I read that as 'code folding' and clang compilation.
I think the main takeaway here is that most of his "ideas" can be easily achieved within the current ecosystem of available programs, most of which are stock on modern UNIX-like OS distributions. I do think he misfiled this article under "Ideas"; it's more akin to a polite rant.
edit: colours/color killed due to conflict with reality (and irrelevance anyway).
Also, I'm British.
I don't dismiss the entire article; I appreciate thought and innovation in the space of the terminal, but I disagree with your ideas. Thanks for putting them out there to begin with.
I see the context-switch as one between text and graphics.
If I'm working on the command line, then most times I have no need to have X11 running. I'm working exclusively with text. I can boot to a command line and start working. No X11 is needed.
But when a need arises for graphics, e.g., to read a PDF composed of scanned images (not pure Postscript), then I have to "context-switch" to the X11 context.
I find that switching back and forth between these two contexts is not smooth and can easily lead to instability.
There is often a presumption, as in Plan9, that we will just switch once: to the graphical environment. And not return to the original console.
To me, neither an X11 terminal emulator nor the Plan9 environment is "the console". It's another layer of abstraction on top of the console.
That is a lot of overhead I do not need if I'm just working with text.
And even in the case I keep X11 running on another vt, I've found that when using no wm, or a simple one like evilwm, switching back and forth from console (on one vt) to X11 (on another vt) many times does not work well. Eventually it fails.
This is on {Net,Free,Open}BSD.
I don't think that Plan9 has vt's as such. It's more like what the article envisions, with graphics capabilities seemingly woven into the terminal. But you're pretty much stuck in an X11 type environment. Plan9 experts correct me if I'm wrong.
I've always found this "context switch" from console to graphics is like a one-way street. You're not really expected to keep shutting down the graphics and going back to the console. At least I've never found anyone who does that.
I'm a NetBSD user that uses a tiling window manager (i3 - not ion3, it's different). ALT+1 and ALT+2 are where I keep my urxvts, ALT+3 my web browser, etc. The switch happens instantaneously.
Am I mistaken in my understanding of your issue, or is this helpful?
I have not tried i3 and I'm going to give it a go.
Are you ever keen to chat with another NetBSD user off HN?
Also, some parts of the proposal are very vague (description of MVC), while others are extremely specific (whole paragraph about an obscure Unicode delimiter), which makes it hard to get the big picture. That said, improving the terminal is a really challenging and important problem, so I'm glad there are people thinking about it.
People thought about it 20 years ago, not only about the terminal, but about improving UNIX in general. And not just any people, but the people that did UNIX and C in the first place. Their effort is called Plan9.
Very few people have heard of Plan9 and of those people even fewer used it to the point of understanding the novel ideas.
I use it. Even when I am forced to use UNIX I still use the Plan9 tools along with the Acme and Sam editors. Once you get used to the new Plan9 ideas, you feel crippled in UNIX and can never go back.
Would you care to expand on this? Any specific examples of things that Plan9 does for you that you feel crippled without? I ask out of genuine curiousity, as I've often heard Plan9 mentioned but have never given it enough research to understand its appeal.
For example, I'm a full time web developer and I spent a lot of time in zsh and vim. Would you recommend that someone like me checks out Plan9? Is it the type of thing you could possibly use as your general purpose OS?
Aside of that there's a big chunk of remote filesystem access ported from Plan 9, but I haven't used that yet.
Acme is, in fact, a modern, windowing terminal -- it lets you view, edit, execute and navigate. No surprise given that it comes from Rob Pike -- one of the guys behind an earlier windowing terminal: http://en.wikipedia.org/wiki/Blit_(computer_terminal) http://doc.cat-v.org/bell_labs/blit/
http://swtch.com/plan9port/ is quite easy to start with on any POSIX system.
I still think the idea is great. This guys should work together instead of making yet another competing project.
Both TermKit and this project will have an interesting dilemma with editing remote files though. The advantage of SSH is that you really aren't storing any remote files locally (only the currently visible characters are stored in memory). An editor that uses this new model and eliminates lag requires transfer of remote files to the local computer. There are a lot of situations where this is not a viable option.
The core philosophy of Unix is to build tools that do one job well. By combining those tools, it is then possible to build great things. Do not assume that means you can hide the tools away and just give people the great thing, and realize it is naive to believe that you can solve everyone's problem by creating the one true master editor/program/os that combines all the great things from previous attempts, but this time "gets it right".
Best Ivo
A UNIX wizard hears cries of torment from his apprentice's computer room where the apprentice is studying, and goes to investigate.
He finds the apprentice in obvious distress, nearly on the verge of tears. "What's the problem?" he asks. "Why did you cry out?"
"It's terrible using this system. I must use four editors each day to get my studies done, because not one of them does everything."
The wizard nods sagely, and asks, "And what would you propose that will solve this obvious dilemma?"
The student thinks carefully for several minutes, and his face then lights up in delight. Excitedly, he says, "Well, it's obvious. I will write the best editor ever. It will do everything that the existing four editors do, but do their jobs better, and faster. And because of my new editor, the world will be a better place."
The wizard quickly raises his hand and smacks the apprentice on the side of his head. The wizard is old and frail, and the apprentice isn't physically hurt, but is shocked by what has happened. He turns his head to face the wizard. "What have I done wrong?" he asks.
"Fool!" says the wizard. "Do you think I want to learn yet another editor?"
Immediately, the apprentice is enlightened.
Bourne, ash, bash, dash, ksh, mksh, zsh, csh, tcsh, rc, GNU Screen, etc, Each of them has a slightly different featureset. You can go with the default of bash and it could work out very well for you, but you'd be turning down potentially better alternatives. You seem pretty derisive towards hobbyist projects for a site called "Hacker News". That hobbyist project could be the best thing you've ever used, but you'll never know. That was the entire point of my original post.
Scrutinizing an idea for a new method of programmer-computer interaction from the perspective of a newcomer makes little sense to me, as does the "competing standards" thing from a neighboring comment, scrutinizing OP's idea for being potentially unable to win a popularity contest. OP's terminal system isn't a standard struggling to gain widespread public acceptance. It's just some guy's program.
I think that an idea about programmer-computer interaction ought to be scrutinized for its merit in facilitating programmer-computer interaction, and that criticism from a perspective that isn't the programmer's and isn't the computer's is useless.
PS. You forgot one of the most interesting Unix shells, es. It could turn out to be the best shell you've ever used.
Citation needed :)
Hacker News certainly wouldn't exist. The web wouldn't exist.
Hell, Unix wouldn't have ever existed.
Yeah, how dumb and harmful that is, asking people to think before acting.
Then the compiler will infer that you mean (4::Fractional a=>a) + (4.2::Fractional a => a)
However, you cannot add an integer and a float: (4::Int) + (4.2::Float)
This follows from the type of (+) :: Num a => a -> a -> a(4.2::Fractional a=> a) + (4::Float)
Float is an instance of the type class Fractional. That is: methods which are defined for all fractional types must be defined for floats.
The compiler infers that (4.2::Fractional a=>a) must have type float, as it is being added to a float. This is compatible with the original type of the expression, as Float is an instance of fractional, so it is valid to read 4.2 as a Float.
This diagram might help: http://www.haskell.org/onlinereport/basic.html#sect6.3
I did some experiments with clojure/camel at one point, and came up with stuff like this:
(defroute context (from "file:/home/jw/scratch/inbox?noop=true") (to "file:/home/jw/scratch/outbox")) ; from http://codeabout.blogspot.com/2010/06/using-apache-camel-fro...
Which is basically a continuous file copy. I could see different flags for "do now and exit", "do at HH:MM:SS", "do until I tell you to stop", "do when system is idle", etc.
Could you perhaps explain a bit better?
I’m working on this in my spare time, starting with...
and now I'm curious to see what the author comes up with.
There's just something about an actual tool, no matter how prototypical, that improves the discussion of new tools.
http://www.advogato.org/person/habes/diary/6.html
This made Unix so reliable. If you want to write a beautiful terminal as _addon_ I have no problem with that. But I would not accept a _replacement_ of the old fashioned terminals. Because they are so simple, they just work.
The terminal guts are unbelievably gnarly, and it's kinda surprising it hasn't been replaced with a simpler approach designed for virtual terminals by now.
Because they ... just work? :-)
If you really want to "reimagine" it, throw out the box and make a new one. If you redesigned all the standard unix tools to have a universal API and added hooks for each function they contain you could just specify a workflow to execute and the tools would figure out how to transmogrify the data internally. So for example:
Not the greatest example but you get the idea. If this seems more complex than traditional one-liner scripting it's because you're trying to do a lot of little things on a single line. It may be better to shove all this into a little file in easy to understand non-programmer language and save it for later. (Also, the long GNU options could be replaced by short options for quicker use, depending on the API/module being used)This is obviously not getting away from the 'old school dynamic' of a fake terminal, but it does remove some of the need for it when we have tools robust enough that the terminal doesn't have to be as user-friendly as it is. You could combine a tool/framework like the above with a text editor to write multi-liners, sample the output and execute them on the fly. Build in hooks to execute commands over an ssh connection - or even gather output from various hosts at a time - and you could automate sampling your whole network from a one-liner.
For a "friendly interface" I think a simple tree view file browser would work nicely. So basically an "explorer"-type app with an embedded text editor and output window to let you explore a system rapidly and also automate tasks on the fly. Hell, you could build an IDE or other friendly GUI to build your query tool's arguments using quick mouse clicks.
Let's just replace escape codes with some kind of markup language (or s-expressions or whatever).
GNU info?
Certainly the provided successors of the Bourne shell might be more elegant. Certainly when piping data through several tools needs often transformation of the data representation to match the required input format. Sometimes the transformation uses different principles (regular expressions, shell wildcards, awk, sed, ..) which pollutes the logical flow of problem resolution. But I came to the conclusion that despite not being optimal, this data transformation noise holds information that, when reading or when needing to explain to others, helps to understand, or maybe remember the data model from the source to the sinks. However I believe, more uniform but more universal data transformation techniques would be a progress.
Until now this comment is more about shell than terminals, but for me, these are the biggest advantages of working on a command line - freedom and creativity in the usage of available tools.
Now, to come closer to the terminal aspect.
I am a typing fan. I went through hell when moving from Germany to France and having to re-learn a new keyboard layout - none of the both layouts are good, but if you are used to one it is very annoying to get to used to another. After having had some missions in other countries with different keyboard layouts, I found a solution, that is in line with my philosophy of using typing tools: Learn US keyboard layout, to the point to use it blindly without needing letters on the keys - it is installed on all OSes in all countries. At home use the extension US International with AltGr dead keys - I can now write all German, French, Turk and many other Latin based accents with a single layout. When in mission at a customer I ask if in the open session I can switch to US layout (if needed) - until now there were only some raised eyebrows, but no objections. And at least for ThinkPads you can order them with US layout, even with the € sign. So for keyboard I tackled the problem.
For text editors I resolved the problem already 10 years ago. I use VIM. VI is on all UNIXes, VIM is on Windows (I did not yet have to work on Macs).
On the UNIX shell the first thing I type is: set -o vi Like this many VI shortcuts and commands are at the command line.
One quote in the article made me smile the most:
"... However, it’s worth noting that we don’t avoid the mouse because it is slow — if one wants to move the cursor to an arbitrary location elsewhere on the screen, one can often do so faster with a mouse than a keyboard. The problem is the transition from the keyboard to the mouse. It’s an expensive context switch, which should not be done lightly. ..."
Yeah, this is the reason I use a track point instead of a mouse. Nothing to care with you, takes no space and you don't have to lift your hands from the keyboard. The only problem is the craving when having to sit at a customer at a keyboard that has not track point - I find myself sometimes searching for it with the fingers until I realize that I am not on my ThinkPad. It is a shame this device is disappearing on most computers.
At last: I think what unites the aficionados of the command line is the choice to spend more effort and time in learning tools which are more difficult than their alternatives (mouse vs. track point, command line vs. GUI, ten finger typing vs. two finger typing) at the beginning but pay big times off in efficiency in the long run and as a plus give the pleasure of creativity and freedom.
I encourage the author of the article to progress with his ideas! We absolutely need innovation in this space. It is just that the bar is huge because of all the tools we became used to.
VIM + touchpad beneath space bar on a standard laptop works well too. I can left\right click with my left thumb and move the cursor with my right thumb without my primary digits leaving the home keys.
(a) a good track point is ways more precise than a touch pad
(b) to cross the screen from one corner to another on a touch pad you have to make several strokes, whereas with a track point you don't have to leave the device a single time
Here's the beginning of my thinking on the subject: http://blog.byjoemoon.com/post/9325300749/a-different-kind-o...
It's great to hear other voices in this discussion, though!