- Monospace fonts for code is definitely in. Try catting a .js file, it will get syntax highlighted. Most likely, it doesn't recognize the mime type of your file. It's using the old mime.types DB + some custom additions... also, the highlighter I'm using only has so many languages defined. I looked for the most comprehensive / least fail one.
- Regarding vim... I admit I just don't like those tools. I can operate vim just fine, but I hate every second of it. I would much rather be able to type "edit file", have it open up the file in my local editor, and sync back saved changes.
- No scripting language... except the whole thing is built on Node.js... :) What's not discussed in the article is that the UI is not tied to the shell at all. You can just as easily make a back-end worker for SQL, for SFTP, for a scripting console, etc. I haven't worked out how this works in the UI, but the protocol supports it. Session types can be multiplexed freely over one socket. Basically, for scripting, I think the command line is a shitty place for it, and we should just switch to using a real language in its own little console when needed.
- Regarding habits... it's not my goal to break any without reason, just to reduce the number of keystrokes. Consider it a bug. Regarding quotes... the idea is WYSIWYG. If there is a visual divider, it's a separate argument. Otherwise, it gets passed as a single unit. This may sometimes be buggy, the Unix command support is 1 week old, and I hack on this very late at night.
It seems like TermKit could handle curses applications fairly straightforwardly and without modifying those applications. Just set TERM=xterm, and when you see the xterm initialization string, either open a new tab or define a region in the existing tab, and emulate an xterm within that region. (If you use a region in the existing tab, it could have a control attached to it that splits that region out into a new tab.) That would allow existing programs like vim, htop, powertop, and mutt to work perfectly within your terminal.
Personally, I'd like to use this like an enhanced standard terminal. So, for instance, I'd like to have the standard ls output rather than something graphical, but I'd like the filenames in the ls output to act as links, so I can click to open or hover for a preview. And while I want the standard cat command, I'd also like to have the command that displays something inline in the terminal (with the above-mentioned control to move it to a new tab).
Same here. Just adding a tiny little bit of enhancement without changing anything in the standard behavior could be a bettter idea. Examples:
- ls output is pure text but hoverable (parent's idea)
- add a way to see thumbnails of pics in ls
- drag and drop files in the pwd
Where I work, everybody has linux development machines, but use their machine of choice as their actual workstation. This either forces people to use vim/emacs through SSH, or set up some local file sharing so that they can use their bloated eclipse thing.
Personally, I've spent months each with a few of the popular editors around, and I fall back on vim just because my .vimrc has been tuned so much over the past few years that it's just painful to use anything else. I don't even care if the editors have more features.
Now, if I had a fancier terminal, where my mouse click picked the right vim split view instance, or highlighting text in a split view vim selected only text in that window, instead of the whole line of the terminal, I would use that. MacVim is pretty much the perfect tool for me, but it's local and not remote (and also not inside a terminal that I can split up with screen).
Try to control-select in the terminal. Works with my Gnome term 2.
> vim/emacs through SSH
We work like that too, and I see only advantages to this set-up, the least being forcing everyone to learn find, grep, vim. These powerful tools increase productivity but have a high barrier of entry, so best is to have no other choice.
All of the things you mentioned are supported and work with most terminal emulators (tested with xterm, gnome-terminal, iterm2 on OSX)
I've implemented over a dozen RFCs, can match regexps with the best of them and do know which end of a pipe does what ;).
For instance, I very rarely want more informations about the files from an "ls" command; and if I did, I'd probably use Finder instead. On the other hand, not having enough terminal real estate to display the entire directory at once is a very frequent problem. From that perspective, adding icons is a step in the wrong direction.
Thinking about it, if I were playing with making a better terminal, one of my first lines of thought would be things that made it quick and easy to break information out into other windows, because scrolling back and forth in the terminal's buffer is a PITA.
Of course, this new terminal might be exactly what the author needs, and more power to him if it is. There's no need for us all to use the same tools. (Thanks heavens -- I want nothing to do with Emacs or vi!)
The thing that strikes me as very, very cool about this project is that you might not need the Finder at all any more.
You know what would rock my world? A "lsf" command that emulated "ls" as much as possible, but launched a Finder window appropriately sized to display the results.
As for why? Because it will be optimized for keyboard interaction and rapid context switching.
It's very hard to make a product that essentially devalues things that your customers spent a lot of time learning. You're probably better off ignoring people who already happy with their shell experience, and going after people who have not yet invested in learning all that crap.
And yes, it's crap. And I say that not because I don't know it myself, but because in the end, much of it is not essential to the actual job we're trying to get done, it's the tools we use. And the tools are not the job.
I'm quite bad for upgrading for upgrading's sake but I can understand why, of all people, traders at Bloomberg didn't want any kind of learning curve on their terminals.
Yes, it's clearly better but users don't always want to change to something that does what they already do in a more modern way.
In my experience, programmers as a whole are actually more luddite and irrationally reactionary than the general populace.
Doctors and different drugs/treatments, Contractors and brands of power tools.
Programmers do seem to make the biggest deal about "all the fighting", everyone else seems to just accept that professionals are opinionated and arguing is how progress is made. But I'm on the inside with the programming stuff and on the outside looking in for the rest of these fields so maybe that's not true.
From what I've seen, smart Doctors and Contractors eventually get to discussing empirical data and costs. Far too often, I've seen programmers just make up crap and state it emphatically.
I actually built in anonymous usage logging into TermKit using Google Analytics over SSL. It logs the types of commands you execute (no data). It's my plan to release this data back to the community regularly. I don't think anyone has done a large-scale survey of command-line unix usage before. Should be interesting.
Edit: and you can easily turn it off if you wish.
I think the culture would be a vital part of an ecosystem of empirical observation. For the sciences generally, the culture predated the sources and gave rise to them. For medicine, I think a culture of empiricism was imported from other scientific fields. For contractors, they are very motivated to note what works, what breaks, and what enables them to make more money.
I've had similar ideas (based on Python) but never got around to executing them. Keep up the good work and don't let the angry bearded UNIX dinosaurs get to you :)
Who cares what people on the internet say, they're the ones wasting their time posting it.
Considering that when the interface for the terminal was created it was all about being able to do everything and anything without breaking a sweat. Simple things like automatic source code highlighting, animated progress bars, being able to view (now common) files like pdf and jpeg that were not common back in the old days. Popup tab complete, I can't believe that that isn't standard on all terminals already (especially since tab complete is all about being lazy, a popup makes a lot of sense).
I'll download the source and poke around it later this evening (right now I need to work on my exam of implementing the go-back-n protocol).
Cheers and keep up the good work.
PS: RDF support would be great (since you have json). RDF is the standard for sharing data (often statistics) openly online, check out http://data.gov.uk/linked-data
I thought the current minimalistic approach was ok, but it might be worth to add subtle quotes around the edges to reinforce the idea. That's why it's made out of HTML/CSS...
Sure, not everyone will like this, but for people that are visually oriented like me it will make things a lot of fun.
About caring enough, yeah, that depends, maybe the world is ready for this now :) At least it isn't some overengineered XML grotesquery this time.
Have you looked at some WebGL / Canvas based demos lately? There are now very efficient GPU offloaded rendering APIs that make rendering graphics a breeze, it is no longer a big-overhead thing. If you don't use fancy graphics you're underutilizing your GPU.
[also, TermKit is not just about fancy graphics, but also about user friendlyness/usefullness for some tasks that are not very well handled in terminals otherwise]
You built something great, made it open source, which is even more great, and you're here to answer people, which is amazing. Now, please don't act like "I implemented x RFCs, I can do y like the best...", it's simply useless here.
One reason is that people already know you can code well, and they can even read your source if they want to know better, there's no need to brag.
Another reason is that HN is the place of some very good developers, and I believe humility is appreciated here, at least until you build some life changing software (and I won't debate about what is or is not life changing).
Anyways, thanks for building this and releasing the source code as open, it's cool.
Again, the architecture supports it.
I think this is a cool idea. I think it needs to be cross platform. However, it must be fully backwards compatible with the full unix toolchain to be useful. If it isn't I can't use it, and a lot of other potential users will also be unable to use it.
I love the idea thanks for rethinking the terminal.
The benefits of having your vim settings whenever you type 'vim' rather than whatever's on the server is invaluable, too. It's not an easy task to satisfy everyone, and I wouldn't expect TermKit too; nevertheless I'm excited to see how it develops.
So maybe TermKit isn't the app for them.
> However, it must be fully backwards compatible with the full unix toolchain to be useful.
"Must"? If this app does something useful for you, great. If not, that's fine too. Every app doesn't need to be used by every person.
TermKit's author may dislike Vim, but I suspect that he's helped its users in the long run.
We can agree to disagree about Vim and shell scripting. I use those both, all day and every day. Tastes vary. That's fine.
I really wish you would reconsider the single quoting/WYSIWYG/visual divider business. It's extremely jarring to see awk (or sed, etc.) without those single quotes.
Doubting your credentials on the basis of this is silly, and will probably be the minority reaction in the long run. I would be surprised if you don't get offered a few jobs as the result of making TermKit.
I could see this being done well-- it's not hard to beat bash for syntax and functionality-- but I could also see it being done poorly or considered an ancillary feature.
Shell scripting sucks, but it's the only language I know that lets me write tiny little scripts in not minutes but seconds, inline, without breaking out of the flow. Just like dynamic versus static languages, the quantitative difference in writing speed is enough to make a qualitative difference in the types of programs that can be written; and the difference between a non-scriptable shell and a scriptable one is like the difference between a GUI and a good CLI.
A large part of that scriptability is just grep and sed and friends, which TermKit apparently does support, but sometimes bash's loop structures are also required...
Just my two cents.
Most of what TermKit is doing doesn't immediately appeal to me (as a longtime shell junkie of sorts), but one thing I would love to have in a terminal is tooltips, or popups of some sort. For example, say I get a 40 line stack trace, I'd like to just see one line (the exception, where it was thrown from) but have the option to learn more by clicking on a line in the terminal. Basically how exceptions are reported in the browser in Django or Rails, but in the terminal.