Finalterm - modern terminal done right
finalterm.org
finalterm.org
Much of what is being provided here could and should be implemented in the shell, not in the terminal emulator. Implemented in the shell, you could get many if not all of these features in any modern terminal emulator. If the terminal emulator genuinely does not provide the facilities that a shell needs to do something, then we can discuss extending the terminal emulator to provide generic facilities that the shell would then use.
The dropdowns in particular could and should be implemented in the shell. Look at what Vim does with its completion right now[0]; it doesn't need specialized terminal emulator support for that. Throwing in mouse support for those dropdowns would be nice, and could be done with existing terminal emulators.
Also, the last time this was discussed people raised concerns that additional parsing of terminal output presented an increased surface area for attack. xterm 'title' support has caused a vulnerability in the past, we should be careful to not repeat that.
[0] http://1.bp.blogspot.com/_ci2yBnqzJgM/TD1PfKTlwnI/AAAAAAAAAD...
And yet. I can't run your ideas on my computer, but I can run Finalterm. So Philipp Emanuel Weidmann wins the argument, by default. Sorry.
The author of this has some very good ideas and I don't doubt that they are technically proficient. Nevertheless, I believe they have executed their idea the wrong way.
This may seem like a complaint that the end user doesn't have any reason to care about, but I disagree. Downthread[0] there is somebody lamenting tab being used to activate the completion. I don't know what shell they use, but if they use zsh they already have a myriad of completion options available to them. Taking advantage of the features provided in this terminal emulator and zsh simultaneously would undoubtedly be problematic (actually, last I heard they seem to have somehow broken 'vi support', so whether or not arbitrary zsh configurations will even work on it is questionable). If we want Finalterminal to support the extensive range of completion that zsh already does, we are going to have a lot of duplicated effort. Completion features should therefore be implemented at the same level that they have always existed at, the shell and/or application (think vim) layer.
It seems unlikely that the author of finalterm, Philip, didn't consider doing this as a shell addition. But, if he pops in here and says, "Gosh, I never thought of that! You're right I should scrap this project and do it in the shell!" then I will humbly apologize. But, I don't think that's going to happen.
I think you are misunderstanding the nature of my complaint however. This isn't an issue of somebody using a tool that I don't prefer.. use Vim, or use Emacs, or use Nano for all I care. You want to use gnome-terminal? I can't stand it, but be my guest.
This is me saying that Philip has a good idea but has implemented it in a way that does not play nicely with existing tools. He knows this obviously, since he (or maybe other Finalterm authors, I haven't really been paying attention to that) have pointed that out himself. What I am pointing out that this incompatibility is unnecessary and unfortunate.
The crux of my complaint is that he has ideas that I would like to use, but solely because he has implemented them in an unorthodox way, there is simply no way that I can incorporate this into my workflow.
I'm not going to not say this simply because he may have also thought of this and disagrees with me. HN should not be an echo chamber of praise.
Of course mosh's design also has some implications I am not satisfied with... that's not really on topic here, though I do wonder if mosh would run under Finalterm. I suspect not, though I haven't tried.
- "Get it now" link
- Demonstrates why you want it above the fold
- Three major features right up front
- More detail below, if you care to read that far
I don't know if the project is any good, but hot damn I love that page.
As an aside, you would not believe how difficult it is to read completion data from readline. There is virtually no useful documentation on this matter; many readline settings make the task impossible; the --More-- menu requires your scraper to be interactive... you'd think there would be an escape to return the necessary data in a computer readable format, but you'd be wrong.
On top of that, some programs use mechanisms similar to but incompatible with readline, see Haskell's GHCi and haskeline.
Fortunately it appears to be a feature under active development, and they address splitting on their blog:
http://blog.finalterm.org/2013/10/multiple-terminals-final-t...
The landing page looks great, but I think mentioning screen splitting would be wise.
I also wonder why gnome shell never implemented one. I just don't understand why linux shell don't come with this by default. Think Ubuntu's terminal.
While the idea looks great, it seemed slow to react to my key presses. Maybe they can fix that in the near future. Otherwise I'm probably sticking to xterm.
I haven't evaluated it personally, but I don't think it's up my alley (I use a tiled WM); Vala and GTK make it seem like it's for the Gnome stack, and it also has mouse interactivity. Finalterm might be neat for an Ubuntu box, though.
Are there any comparable terminal emulators that support completion, 24-bit color, are hardware-accelerated, etc? I'd definitely like to replace mine if so.
Unfortunately it's totally unusable for Vim users...
How so?
99% of your work should be spent on non production hosts. Fire up your old XTerm or whatever when you need to manage a production machine.
I don't really see the problem.