Also of Hotwire Shell/Term and KliNG from a few years back.
This one look nicer. At least it doesn't make the error of the previously mentioned attempts like trying to create a custom shell instead of using regular ones. Nor it does screw up existing workflow. As for trying to understand the terminal content, it is a "challenge" and I don't think it is a good idea as it will remain command specific and it has been proven to be a problem in the past, and it still is.
Poor Steven. He took so much heat then, for a concept that was way ahead of its time.
These kinds of extra-helpful term emulators seem like the natural progression of auto-completion and all the other goodies people love about oh-my-zsh. Once someone gets this right, it will seem silly to use a 'dumb' terminal in a graphical environment.
There is a right way and a wrong way to add advanced features to the whole command line experience.
The separation between shells and terminals is a good thing and should not be ignored. New features should be added to shells, and only if necessary, we can add new features to terminal emulators to support those shell features. Many, if not most, of those supporting features are already in terminal emulators. For example, every single modern terminal emulator supports mouse input (pretty much by definition): this could be used by shells if they were so inclined. If you want to add some sort of menu-based completion that supports mouse selection, great! The shell is the correct place to do it. Want to display some images or vector graphics? Some terminal emulators will have your back even in those situations, though support for those things would need to be more widespread before that stuff could really be used properly.
Great point. I wonder though if some of the more advanced UI features that people want as part of their terminal+shell are being held back by relatively ancient paradigms for how terminals do complex interactive stuff. In-band signalling, ReGIS, Sixel, and Tektronix 4014 all feel like old-fashioned tech that won't be getting more popular, even if they are technically capable of getting the job done.
I totally agree that in Computer Science there are established paradigms, but I think sometimes these paradigms keep people from exploring different ways of thinking.
Talking specifically about TermKit: If I'm on a Mac using Terminal to access the local shell, why would I care if the features are coming from the shell itself or the Terminal app?
Of course it would be 'better' or more 'proper' if all the functions were built into the shell, but like you say, it takes widespread adoption. I don't see what the problem is with starting to add features to your terminal and then let the good ones trickle back down into the shell as they become widely adopted.
Seems like a confusing nightmare, but I'm not fundamentally against it.
The current version will reflow. When I use it through byobu I sometimes have to initiate reflow with ctrl-a, shift-F.
It may not reflow as expected if you have more than one client connected to the same session - since it limits itself to the smallest attached client. If you leave your ssh session connected to the session and then connect again locally it is not obvious why reflow won't work, but you may need to just disconnect the other client.
Please support panes, tabs and scripting for them. I tried tmux, worked in it for 6 months, but what annoyed me is the lack of support for properly styling what's on the screen. For instance, I wanted panes to be of various background colors and font sizes, which was not really possible at all in tmux.
I'm currently using Terminator, but it's rather ugly in terms of scripting for panes and tabs. If you could implement those two features out of the box, I'd pay for this software.
What are you calling a 'terminal emulator'? I think most support multiple fonts at different sizes. Apple's Terminal does, as do all the terminal emulators on my Centos systems.
In tmux, you can have multiple panes inside of the same terminal window. Apple's Terminal lets you change the font, but as far as I know, there isn't support for multiple font sizes inside of the same terminal window.
Really? I thought most terminal emulator only let you use one font at a time. If the one I use let's you have text in multiple fonts displayed at once, I certainly don't know how to do it. Or by "multiple fonts" did you just mean that you can change the font on the entire window (and that you have multiple options for doing so)?
rxvt-unicode allows you to have multiple fonts at the same time for falling back when a character is not present in the default font. For example my terminal uses a different korean font for hangul and a specific japanese font for kana and kanji in addition to my default font for european script.
xterm can support double-height characters, but that is largely academic. There isn't much it can be used for; I've never seen it used at all except to demonstrate that it can do it.
I couldn't see any GUI elements but drop down menus, which only seem to augment the textual interface by giving a contextual interpretation of certain elements. Oh yeah, and the progress bar, which seems nice!
But sometimes seeing what's possible is good. I believe there are hundreds of commands I would be interested in, but that I don't know exists or have thought about. Right click and get a context menu with the proper command will make me learn something new. And I'll probably end up using the command in the future now that I know it exists and what it does.
It's not just you. It is wrong. A terminal is the most keyboard-driven experience you can imagine. Whenever there's a context menu it should be driven by key combination so you can move through without having to change to the mouse. When you change to the mouse you hit a context switch in the way you interact, that's why it feels disorienting to some people.
If you look at the video you'll see the mouse being used. I haven't tried the software so I don't know if that's the only way it can be used (the site seems to imply otherwise), so I'd reserve judgement.
the real crime here is that the gui elements don't have the same style as the cli elements - they stand out like a sore thumb
but it would be sweet (more for my folks than for me, but still) if you could click on a filename in a terminal to open it, or drag from one directory listing to another to move it
The point is if the "gui" can be keyboard operated, then it can be displayed as text, by the shell, with no need to augment/modify the terminal emulator to do it. In fact, even if it is only mouse operated, you can do that - most terminal emulators support mouse interaction. The only thing you achieve by adding this to terminal emulator is guarantee that it will be unavailable to you whenever you need to log into any of the systems you work on from someone elses machine.
>The point is if the "gui" can be keyboard operated, then it can be displayed as text, by the shell, with no need to augment/modify the terminal emulator to do it.
Maybe it's just me, but I care about functionality first, an beauty second for my terminals. I do like a pretty terminal, but I care more about being able to get things done.
Terminal emulator is, in fact, a GUI application, it's just that it mostly consists of a single text matrix widget. I believe many people use mouse to select text, so I don't think there's anything wrong if the text is somehow more interactive, as long as this is non-obtrusive.
no it's not only you, but don't count me in.
You are conservative, sir. Now downvote, hate and burn me for saying this. Many Linux people hate GUIs, it's a reflex to hate GUI applications, I don't want to generalize, but you probably know quite a lot of experts in their field who simply hate GUI stuff and every single one has his "own" interpretation of why GUI is wrong.
The thing is, GUIs aren't wrong, it's just that the GUI applications have no uniform interoperability like their CLI counterparts. Whose fault is that? Certainly NOT the authors! The fault is much deeper in the OS.
"Now downvote, hate", etc.. always reminds me of young girls who would always post photos with captions like "Ugly" and "Gross" phishing for compliments.
P.S. It doesn't have to do with hating GUIs for most people, it has to do with using a terminal efficiently, which often times means avoiding the mouse when possible.
yes, but that's exactly the argument I expected. Not using the mouse on GUIs is entirely possible, but your argument let's GUIs look as if they are antiquated technology not able to handle hotkeys or vim motions or anything else you want to improve efficiency.
You refer to efficiency as driving point, which I'm a big fan of, although you probably know quite well that you wouldn't use an OS if it had no GUI. The cost of entry into the IT community isn't just time, but capability and intelligence. These are the reasons why still many people are digitally divided and can't use computers efficiently. The GUIs aren't easy enough for them, forget about the terminal efficiency.. You only reach efficiency when you have the possibility to collect enough routine. How will your Grandfather get that routine, when the "cost of entry" is too high for him to master in his age.
We're not on facebook, don't expect anyone to go phishing for upvotes. We care to improve the knowledge, efficiency, health and productivity of startup people on HN.
Terminology: http://www.enlightenment.org/p.php?p=about/terminology looks a bit similar and it's build with e17 libraries... which means it will reach a 1.0 version in twenty years? Just joking, but as a terminal emulator it's worth taking a look at.
Terminology is certainly nice, but only does inline linking and display of inline media content; no smart interpretation of the terminal content as Final Term does.
Also, if this is free software, you should put Bitcoin donations address somewhere on the site. I would gladly donate a bit because I like the idea and I like that it's for Linux.
Check that you have all the required packages installed on your system. Your terminal output indicates it cannot find pkg_config. There could be other missing requirements, as well. Once you have all the reqs installed, try again. Then, if issues persist, file an issue on the project's Github page. :)
If it's not added yet, please consider adding a quick menu to change character encoding (like in Gnome Terminal). It's my only main requirement for a terminal editor, and most editors seem to lack it.
because GPL tries to reinvent the definition of "free" (I recommend consulting a dictionary, and than reading what GPL considers free/freedom, you are in for a mean suprise).
Because viral licenses get real terrible when you want to get features from two that are mutually incompatible. When two projects have different ideas on imposing "freedom" on users, it makes it harder to cooperate and make a better end product for the users. As such, I much prefer free as in free licenses like BSD over restrictive licenses like the GPL.
Terminal emulators should be expected to deal with a lot of untrusted data, such as when you ssh to another machine. With all the context parsing in this, there is a large attack surface. I hope thought has been put into how to handle this.
Untrusted data in a terminal emulator??? I don't believe that I've ever used a terminal to connect to an untrusted system. Ie. local login, or ssh to a system that I trust enough to compile my programs or run my servers.
If the terminal receives untrusted data back then I've got bigger problems than a security hole in my terminal emulator.
Untrusted data being sent to a terminal emulator does not imply you are logged into an untrusted system with it. Users should be able to view arbitrary files through their terminal emulator safely, should be able to use IRC safely, should be able to use finger safely, etc.
There are enough people here reporting errors (having it hang with certain output, crashing X.org, etc) to cause me to be very wary of this. I am not confident it would stand up to a security review.
The entire concept of exploiting a terminal by supplying hostile input has been around for over 10 years now. Unix veterans and BBS users have been exposed to this type of problem since the very beginning, a newsgroup search can turn up all sorts of exploits, from the ever-popular "flash" program to the abuse of logging features in xterm which were disabled in R5
You've never displayed content in your terminal that you didn't generate yourself? Never ran curl against a URL to check out the headers? Never popped open an editor containing source code downloaded from the internet?
I think this looks great, but it does strike me a bit of re-inventing the wheel, i.e. if we take this to its logical conclusion, we'll have just reinvented the GUI ;)
I really like this, although a lot of features (not GUI) are already supported by ZSH. But why is this missing configuration documentation? Or at least I couldn't find it. Keep up the awesome work!
Does everything FinalTerm does, and probably more (and can be driver with the keyboard only).
Funny thing, I don't like e-shell. I rarely, if ever, have to interact with the output of the previous command.
For command re-editing, most shells (zsh, bash) offer very powerful completition/editing capabilities that probably FinalTerm cannot match.
Admittedly, I sometimes (but rarely) have to use the output of the previous command. The problem is, if it's an url, you probably just want to click it/copy it, and then pretty much all terminals can do this already.
If I want to process the output of the command, I just re-execute it in a pipeline. Just compare the number of keystrokes to go up ~10 lines and the time to type !! (or up-arrow) | grep 'something'. Heck, even copying the output to the clipboard is faster by using a pipe: cmd | xsel
Reflowing is also something many terminals do nowdays. I personally use urxvt because it's the fastest terminal I could test, and actually supports fallback fontsets. VTE-based terminals (even the ones that pretend to be small and fast) are 5-6 orders of magnitude slower at redrawing. e-shell, by comparison, is a dog due to the much more complex display.
Lots of negativity and one-uppery in these comments. I just wanted to say great job, keep up the good work. You're making everybody's lives easier, either directly or indirectly, by pushing the envelope here :)
I agree, this looks really cool! These are the kinds of articles I really like seeing on here, but I feel like people may be discouraged to post these types of things because the top comments are always "Well this sucks because I use X" or "This will never work because Y", or "Didn't Z already do this!?"
Lots of people here are making really cool stuff, and I love hearing about it! Keep it up!
I see like 90% of positive comments...
10% of criticism is too much? without it, its easy to get lost into the "everything's great" and 6 month later everyone complains about their new kde4/gnome3/unity etc fiasco.
For example, personally, I believe the completion belongs to the shell not the terminal, and i'd rather not use the mouse on a terminal's displayed text except for copy/paste.
Doesn't mean its not cool.
It shouldn't be forced, but some of us do use the mouse on a terminal window. I have more of a keyboard 'nipple' but it's conveniently right there when I'm typing and I don't have to move out of a standard typing position to use it.
Really great work, I'm all for it. I've been wanting terminals / shells to move forward with usability for decades now, but have never had time to do it myself. I'm 100% behind any effort in this regard at all. I'll be happy to contribute time an money to a project like this. Thanks for picking up the ball!
I can see myself using a regular terminal emulator for vim on one half of my screen, and something like Final Term for running tests and doing other stuff on the other half.
Since one uses terminals for several different things, it kind of makes sense the idea to use ones specialized for each purpose. I think it's an interesting idea.
Does anyone know why we can't have nice terminal emulators on Windows? I would kill for something that was a fraction as good as the default terms in OSX or Ubuntu.
Oh, and if the NSA is listening, I wouldn't actually kill, that's just an expression. Please don't arrest me.
Checkout cygwin [1]. I think the main problem with a good terminal on Windows is that terminals depend heavily on having programs to run on them, and Windows, because of its lack of good terminal, doesn't have the programs to run with it. From what I have heard, PowerShell looks promising.
Powershell (and cygwin as well IIRC) still have lousy terminal emulators. The issue isn't the lack of good programs nor the shell, it's the Windows GUI "wrapper" around the CLI shell. In Windows neither cmd.exe nor Powershell allow you to alter the width of the terminal in real time. Nor have sane copy/paste options, region highlighting and so on. There's no tabbed grouping, clickable URLs, etc. Sure, some of the aforementioned can be tweaking in the preferences. But on the whole, the Windows terminal emulators are pretty poor when compared to (for example) Konsole.
Cygwin is pretty awful as well. I hear a lot of people suggest it but I really couldn't get on with Cygwin. I found MinGW to be a much better solution (which also ships some pretty cool terminal emulators as well)
I've used Cygwin (with mintty and bash), and it's not terrible. Not as nice as on other platforms, but definitely better than the other things I've seen on Windows.
Before mintty, I used Putty and connected to a local SSH server. Putty is pretty nice too.
If you have cygwin, you can install gnome-terminal. I use it daily and it is awesome. Way better than console2 or any other windows based emulator I've tried. You may need to install it using Cygwin Ports though.
To be honest, I wiped windows and installed Linux in the end. Since I was trying to make windows behave like Linux, it made more sense just to run Linux.
Have you tried setting Quick-Edit for your command line? The right-click copy/paste works well enough (though not nearly as good as a linux terminal). But the highlighting is still garbage.
I always have Cygwin around on my Windows installs. I highly recommend changing the terminal for it to RXVT, though, which works a lot better than the various things they've had by default the past few years. It's just takes a minute or two of tweaking things to setup - usually I don't even edit the main start script anymore since I always launch from the folder context menu setup by the chere program in Cygwin.
I use tera term when on Windows, it requires an install but I like it more than others. The installer does include some other weird programs that I don't like, but if you only choose to install tera term itself it is good.
From my past experience on HN, humor is not well received. I've been scolded numerous times for cracking a joke or two. Personally, I appreciate humor on HN, but I can understand how people don't want HN comments to turn into redit comment threads.
I have a theory as to why. Discourse on serious discussion on such topics, which are scientifically unsolvable (design, business, entrepreneurship) are often deferred to those who have 'been there, done that', which of course is a logical bias.
So to the humour. The issue is HN can't tell the difference between satire of itself and real advice. Each of which is probably equally valuable. Nobody wants to hear this. They all want to feel good. And get rich! And have authority!
Version 20050409-21. Ouch. Maybe rxvt-uncode and an X server would be a better option. 256 colour terms, unicode, proper bitmap font support, and not been dead for 8 years.
The short answer: CSRSS isn't very good. Compare and contrast with the *nix model of how the terminal works and you'll have a pretty good idea of why Windows terminal programs are as limited as they are.
Try mintty[1], comes default with Cygwin these days. Not perfect, but a lot better than the alternatives I've tried. It supports select-to-copy and middle-mouse-to-paste, which is something that's very deeply embedded in my muscle memory.
Yuck yuck yuck. And yuck to ctrl-Insert / shift-Insert too, though that's better. I very much like the fact that on OS X the default copy-paste keys are command-c / command-v which don't conflict with UNIX's use of ctrl. If I can bind Windows-C / Windows-V to copy/paste in a terminal emulator I'd be happier.
Select-to-copy is yuck for two reasons:
1: After you select, it copies and then deselects. This is annoying if you want to see that you selected the right thing, and it doesn't allow you to change your selection if you see you were off by a character.
2: I like to select to mark my place sometimes, but I don't want that to change what's on my system clipboard.
ctrl/shift Insert is yuck because it's a two-hand keystroke and doesn't have an easy way to remember whether shift or ctrl is the copy. (I don't often make mistakes between the two, but it leaves me unsure of myself which is a half second lost to hesitation each time.)
I have the same problem with ctrl/shift Insert, but I'm very happy with select-to-copy, which on Linux doesn't conflict with the ctrl-c/ctrl-v content (they're separate clipboards).
I miss middle-click to paste and select-to-copy where ever I can't use them.
I'm assuming by terminal you don't just mean CLI, which I think PowerShell has been a great step forward (but I wish I didn't have to keep dropping back to the default command prompt to get certain commands working.)
+1 for Console2, back when I had to use Windows at a previous job I used Console2 as it was the closest thing I could find to the linux terminal emulators I'm used to.
Yeah, good luck with that. I spent like a damn week trying to run gnome-terminal under Cygwin, and never did get it right. I'd love to hear any tips, though.
I've been using Console2 for a while and really like it. Last week a colleague pointed out an alternative called ConEmu. It's actively developed and has a bunch of extra features. I'm trying it out but haven't made up my mind which I prefer yet. The decision seems like it will largely be a tradeoff between configuartion complexity and flexibility. https://code.google.com/p/conemu-maximus5/.
I like the tabbed interface and the way it does select/copy/paste (close to the Windows way) in the CMD console. And, it has some pretty cool support for the FAR Manager.
PowerShell is ok until you actually have to use it for something non-trivial, at which point it's the usual "layers-of-pain" that you get with anything Microsoft these days.
I use ConEmu + Powershell/Mintty for Vim/Rails development. I don't notice a difference with it vs my OSX or Linux machines. I also use it for working on my linux VPS and have 0 problems
I don't know if you could use Chrome's SSH extension -- it's actually a super good terminal emulator -- if you check out the source they wrote some code to run tricky sequences through xterm and figure out what it does.
I used this (I think) briefly for about a day on ChromeOS and was very unimpressed. Is there at least a way to turn off the weird character fade effect, or whatever it's called? I didn't look long but I couldn't find one.
I am working on package for windows that can do just that. Totally portable and extensible. Based on ConEmu. But I am looking for beta testers. if anybody is interested drop me an email.
I recently switched to MobaXterm [1] and liked it so much that I paid for the Pro edition. I also love how I can launch X apps on my Fedora dev VM and forward them to my Win7 desktop - I know should be able to do that with CygWin but I could never get it to work properly.
I too switched to Moba recently after trying just about everything else. Some of the things I really like about it over the competitors:
* single binary installer
* X server
* Tabs
* Automatic SFTP sidebar when connecting via SSH
* painless SSH-tunneling (I can never remember the order of arguments on the command line)
* dancing Tuxes
There's probably more things I haven't even discovered yet (which may be too much for some people, who just want a simple terminal emulator). It's not all roses, it has locked up a couple times on me, but thanks to tmux it doesn't bother me much.
170 comments
[ 5.0 ms ] story [ 213 ms ] threadThis one look nicer. At least it doesn't make the error of the previously mentioned attempts like trying to create a custom shell instead of using regular ones. Nor it does screw up existing workflow. As for trying to understand the terminal content, it is a "challenge" and I don't think it is a good idea as it will remain command specific and it has been proven to be a problem in the past, and it still is.
These kinds of extra-helpful term emulators seem like the natural progression of auto-completion and all the other goodies people love about oh-my-zsh. Once someone gets this right, it will seem silly to use a 'dumb' terminal in a graphical environment.
The separation between shells and terminals is a good thing and should not be ignored. New features should be added to shells, and only if necessary, we can add new features to terminal emulators to support those shell features. Many, if not most, of those supporting features are already in terminal emulators. For example, every single modern terminal emulator supports mouse input (pretty much by definition): this could be used by shells if they were so inclined. If you want to add some sort of menu-based completion that supports mouse selection, great! The shell is the correct place to do it. Want to display some images or vector graphics? Some terminal emulators will have your back even in those situations, though support for those things would need to be more widespread before that stuff could really be used properly.
Talking specifically about TermKit: If I'm on a Mac using Terminal to access the local shell, why would I care if the features are coming from the shell itself or the Terminal app?
Of course it would be 'better' or more 'proper' if all the functions were built into the shell, but like you say, it takes widespread adoption. I don't see what the problem is with starting to add features to your terminal and then let the good ones trickle back down into the shell as they become widely adopted.
Seems like a confusing nightmare, but I'm not fundamentally against it.
https://code.google.com/p/hotwire-shell/wiki/GettingStarted0...
No mention of unicode support on the page?
1.8 Changelog: http://sourceforge.net/p/tmux/tmux-code/ci/master/tree/CHANG...
It may not reflow as expected if you have more than one client connected to the same session - since it limits itself to the smallest attached client. If you leave your ssh session connected to the session and then connect again locally it is not obvious why reflow won't work, but you may need to just disconnect the other client.
I'm currently using Terminator, but it's rather ugly in terms of scripting for panes and tabs. If you could implement those two features out of the box, I'd pay for this software.
but it would be sweet (more for my folks than for me, but still) if you could click on a filename in a terminal to open it, or drag from one directory listing to another to move it
You don't have to use the GUI I'd imagine.
I would love to have FinalTerm's features in some sane terminal (no gtk, no super slow libraries etc)
Who is "you"? Different people have different needs and preferences.
Maybe, but that makes the GUI look worse.
Terminal emulator is, in fact, a GUI application, it's just that it mostly consists of a single text matrix widget. I believe many people use mouse to select text, so I don't think there's anything wrong if the text is somehow more interactive, as long as this is non-obtrusive.
The thing is, GUIs aren't wrong, it's just that the GUI applications have no uniform interoperability like their CLI counterparts. Whose fault is that? Certainly NOT the authors! The fault is much deeper in the OS.
P.S. It doesn't have to do with hating GUIs for most people, it has to do with using a terminal efficiently, which often times means avoiding the mouse when possible.
yes, but that's exactly the argument I expected. Not using the mouse on GUIs is entirely possible, but your argument let's GUIs look as if they are antiquated technology not able to handle hotkeys or vim motions or anything else you want to improve efficiency.
You refer to efficiency as driving point, which I'm a big fan of, although you probably know quite well that you wouldn't use an OS if it had no GUI. The cost of entry into the IT community isn't just time, but capability and intelligence. These are the reasons why still many people are digitally divided and can't use computers efficiently. The GUIs aren't easy enough for them, forget about the terminal efficiency.. You only reach efficiency when you have the possibility to collect enough routine. How will your Grandfather get that routine, when the "cost of entry" is too high for him to master in his age.
We're not on facebook, don't expect anyone to go phishing for upvotes. We care to improve the knowledge, efficiency, health and productivity of startup people on HN.
should be typed in terminal, as above? or ".." should be, what? sort of a newbie with terminal...
is ".." a location ...? can anyone provide a reasonable example (to put in place of "..")?
I tried the install commands, as listed in the README (on the Final Term Github Source page)... and the install failed.
If the terminal receives untrusted data back then I've got bigger problems than a security hole in my terminal emulator.
Untrusted data being sent to a terminal emulator does not imply you are logged into an untrusted system with it. Users should be able to view arbitrary files through their terminal emulator safely, should be able to use IRC safely, should be able to use finger safely, etc.
There are enough people here reporting errors (having it hang with certain output, crashing X.org, etc) to cause me to be very wary of this. I am not confident it would stand up to a security review.
http://www.shmoo.com/mail/bugtraq/sep99/msg00145.html
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2003-00...
Also here is an overview of some of the possible ways things can go wrong: http://lists.kde.org/?l=konsole-devel&m=104617524910254&w=2
The entire concept of exploiting a terminal by supplying hostile input has been around for over 10 years now. Unix veterans and BBS users have been exposed to this type of problem since the very beginning, a newsgroup search can turn up all sorts of exploits, from the ever-popular "flash" program to the abuse of logging features in xterm which were disabled in R5
Does everything FinalTerm does, and probably more (and can be driver with the keyboard only).
Funny thing, I don't like e-shell. I rarely, if ever, have to interact with the output of the previous command.
For command re-editing, most shells (zsh, bash) offer very powerful completition/editing capabilities that probably FinalTerm cannot match.
Admittedly, I sometimes (but rarely) have to use the output of the previous command. The problem is, if it's an url, you probably just want to click it/copy it, and then pretty much all terminals can do this already.
If I want to process the output of the command, I just re-execute it in a pipeline. Just compare the number of keystrokes to go up ~10 lines and the time to type !! (or up-arrow) | grep 'something'. Heck, even copying the output to the clipboard is faster by using a pipe: cmd | xsel
Reflowing is also something many terminals do nowdays. I personally use urxvt because it's the fastest terminal I could test, and actually supports fallback fontsets. VTE-based terminals (even the ones that pretend to be small and fast) are 5-6 orders of magnitude slower at redrawing. e-shell, by comparison, is a dog due to the much more complex display.
Pull request is from less than 12 hours ago, so I'm not sure how long it'll take to get into a release.
We'll have to see of this Terminal Emulator goes terminal or can break out into a fulfilling life.
Lots of people here are making really cool stuff, and I love hearing about it! Keep it up!
For example, personally, I believe the completion belongs to the shell not the terminal, and i'd rather not use the mouse on a terminal's displayed text except for copy/paste. Doesn't mean its not cool.
Since one uses terminals for several different things, it kind of makes sense the idea to use ones specialized for each purpose. I think it's an interesting idea.
Oh, and if the NSA is listening, I wouldn't actually kill, that's just an expression. Please don't arrest me.
[1]http://www.cygwin.com/
Cygwin is pretty awful as well. I hear a lot of people suggest it but I really couldn't get on with Cygwin. I found MinGW to be a much better solution (which also ships some pretty cool terminal emulators as well)
Before mintty, I used Putty and connected to a local SSH server. Putty is pretty nice too.
Have you tried MinGW? It's a fork of Cygwin and (in my opinion at least) fixes a lot of problems with Cygwin's install process.
Clink (https://code.google.com/p/clink/) is also something I have found useful.
I like the FuTTY fork of it at the moment.
http://ttssh2.sourceforge.jp/
So to the humour. The issue is HN can't tell the difference between satire of itself and real advice. Each of which is probably equally valuable. Nobody wants to hear this. They all want to feel good. And get rich! And have authority!
Humour has no place here...
[1] https://code.google.com/p/mintty/
Select-to-copy is yuck for two reasons: 1: After you select, it copies and then deselects. This is annoying if you want to see that you selected the right thing, and it doesn't allow you to change your selection if you see you were off by a character. 2: I like to select to mark my place sometimes, but I don't want that to change what's on my system clipboard.
ctrl/shift Insert is yuck because it's a two-hand keystroke and doesn't have an easy way to remember whether shift or ctrl is the copy. (I don't often make mistakes between the two, but it leaves me unsure of myself which is a half second lost to hesitation each time.)
I miss middle-click to paste and select-to-copy where ever I can't use them.
If my assumption holds, I did find this article recommending Console2. http://lifehacker.com/5857540/the-best-terminal-emulator-for...
I like the tabbed interface and the way it does select/copy/paste (close to the Windows way) in the CMD console. And, it has some pretty cool support for the FAR Manager.
Here's a nice writeup by Scott Hanselman: http://www.hanselman.com/blog/ConEmuTheWindowsTerminalConsol...
I'm not a bash scripting poweruser though.
Currently it looks like this. https://dl.dropboxusercontent.com/u/52646091/cmder.png
Should work for you if you are using anything. But works out of the box with cmd + msys-git + some other godness.
Also spit window support, aliases, fullscreen, history search. Sublime Text like shortcuts.
[1]: http://mobaxterm.mobatek.net/
* single binary installer
* X server
* Tabs
* Automatic SFTP sidebar when connecting via SSH
* painless SSH-tunneling (I can never remember the order of arguments on the command line)
* dancing Tuxes
There's probably more things I haven't even discovered yet (which may be too much for some people, who just want a simple terminal emulator). It's not all roses, it has locked up a couple times on me, but thanks to tmux it doesn't bother me much.