
Finalterm - modern terminal done right - pjvds
http://finalterm.org
======
jlgreco
I'll say what I said the last time Finalterm was discussed here (and what I
often say when 'improved' terminal emulators are thrown around):

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...](http://1.bp.blogspot.com/_ci2yBnqzJgM/TD1PfKTlwnI/AAAAAAAAADs/nOGWTRLuae8/s1600/vim_complete.png)

~~~
javajosh
Nice. I mean, is there anything more satisfying than comparing someone's
concrete implementation with our perfect ideal of what they _should_ have
written? Ah, the software in our imagination is so wonderful! It is elegant!
Bug-free! Conceptually unified! All of the abstractions match up nicely from
hardware to application! Compared to our imagination, real software is a
horrible, steaming, pile of shit.

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.

~~~
jlgreco
If HN isn't the place to have an honest discussion about the merits of a
project's architecture, then I don't know where is.

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.

[0]:
[https://news.ycombinator.com/item?id=6574405](https://news.ycombinator.com/item?id=6574405)

~~~
javajosh
But yours is not a criticism that Philip can really use. He's clearly decided
on an approach: adding capability to a terminal. It's as if someone posted a
Ruby framework and you criticized them for the fact that they _should_ be
using Python, because it's just better for web stuff. Or someone posts a Vim
plugin and you criticize them for not using Emacs, etc. Or someone writing an
IDE plugin and you say they should run it from the command line anyway. Etc.

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.

~~~
jlgreco
I don't know what Philip did or did not think of.

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.

------
Domenic_S
This is exactly how a product page should look.

\- "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.

~~~
Numberwang
I don't know. For me it didn't really live up to the high standards of what is
submitted to HN. Way too much information, and no where to sign up. No one
will be interested in this.

~~~
mbillie1
It's a FOSS terminal emulator, what is there to sign up for? And there's an
obvious and prominent link to the Github repo. For the record, I think it's
highly interesting.

~~~
icebraining
I think it was a sarcastic post :)

------
chrismonsanto
If you like the completion dropdown, and use Emacs, you may like term-mode
extended with my readline-complete.el [0] and auto-complete-mode. Screenshots
on the 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.

[0]: [https://github.com/monsanto/readline-
complete.el](https://github.com/monsanto/readline-complete.el)

~~~
hablahaha
For a few seconds there I thought _the_ Monsanto had a Github account. I was
kind of excited to see what OSS they had.

~~~
chrismonsanto
My great great great (however many greats) aunt was the namesake for the
company. I don't necessarily approve of their practices, and unfortunately I
don't get any money out of the deal :(

------
mgraczyk
It really kills me to see an otherwise promising terminal with no screen
splitting capability, and I did not see splitting mentioned anywhere on their
product page.

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...](http://blog.finalterm.org/2013/10/multiple-terminals-final-term-
style.html)

The landing page looks great, but I think mentioning screen splitting would be
wise.

~~~
nilved
Why not use screen or tmux? I don't think that should be handled by the
terminal emulator. Then again, neither should a lot of these features.

~~~
mgraczyk
While trying to think of a reply to this comment I realized that I have no
answer, and I should probably just use screen or tmux. Thanks for that.

------
robinhoode
I remember seeing this here: [http://n0where.net/final-
term/](http://n0where.net/final-term/)

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.

------
possibilistic
This is really cool.

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.

------
uolot
Last time I checked it, it was very buggy and unstable, but current version
look much much better.

Unfortunately it's totally unusable for Vim users...

~~~
pestaa
> Unfortunately it's totally unusable for Vim users...

How so?

~~~
uolot
It gets totally messed up - I can attach a screenshot if you wish. Maybe it's
fault of my vim's config.

------
kcbanner
I'm not sure why people find the need to create these things when they already
exist in shells such as zsh.

------
davidjhamp
This looks like a cool project but lately I've been really enjoying a Guake
terminal([http://guake.org](http://guake.org)) + fish
shell([http://fishshell.com](http://fishshell.com)) combo.

------
casca
Been watching Finalterm for a few months - it looks interesting but it's still
too unstable to use for production. The risk of it doing the wrong thing when
running on a production host is just not worth the potential efficiency gains.

~~~
scbrg
Not that I know anything about the software in question but... don't run it on
a production host. Or when you're connected to a production host.

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.

------
yeukhon
suggestion by tabbing in shell is annoying to me. Some commands have popular
prefix. It would be better if suggestion is made like the one you did in
finalterm (and list most frequent one at the top).

------
electic
Too bad it's not for mac.

~~~
wandermatt
Keep an eye on this pull request:
[https://github.com/p-e-w/finalterm/pull/130](https://github.com/p-e-w/finalterm/pull/130)

