My god, this looks terrible. There's a reason we're still using text terminals from the 70s-- they work!
I sincerely hope i won't ever have to work with this.
TermKit - a graphical terminal replacement
81–90 of 208 posts
Re: TermKit - a graphical terminal replacement
#82it's curious this is on the front page at the same time as oh (or was that on reddit? - can't seem to find it now). https://github.com/michaelmacinnis/oh both allow the shell to use structured data. i like the idea of using json myself (not that keen on the gui parts of the implementation, but moving pipes to something with more structure seems like a good idea). did plan 9 do anything similar?
Here's the link to the comments:
Re: TermKit - a graphical terminal replacement
#83Earlier quoted context omitted.
And on another note... it's been hilarious how people have been questioning my professional credentials just because I want to make something more usable. 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 ;).
I'm also a bit disappointed on how most people here react. I personally think your idea is great and pretty futuristic. I would certainly use a tool like this. Also it's open source so if a specific detail (such as the font) bugs them it can simply be changed. 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 yo…
It's not futuristic, it's retro. I've seen three or four of these be announced with great fanfare, and then dropped. No one cares enough, the backwards compatibility is never good enough, and it's almost certainly too slow.
Re: TermKit - a graphical terminal replacement
#84Earlier quoted context omitted.
And on another note... it's been hilarious how people have been questioning my professional credentials just because I want to make something more usable. 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 ;).
It is amusing how we hackers, who are supposed to embrace change, become as Luddite as anyone else when our sacred tools are questioned. Personally I see room for this and a whole lot more. I'd like to see an amalgam of this and the traditional terminal (easy way to pull up a traditional terminal if you need it). There is no need to "replace"; I think this makes a fine addition to a hackers workspace.
It is amusing how we hackers, who are supposed to embrace change, become as Luddite as anyone else when our sacred tools are questioned.
In my experience, programmers as a whole are actually more luddite and irrationally reactionary than the general populace.
Re: TermKit - a graphical terminal replacement
#85Earlier quoted context omitted.
To address some of your concerns: - 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 l…
While, I understand your dislike of Vim, Vi, Nano, Emacs, etc. (I can't work in them for extend periods of time either do to hand problems) They remain essential tools for many programmers and system administrators. Sometimes, you don't want to have the file pulled down and edited in a local edit and pushed back even if it is seamless. The benefits of inplace editing on remote machines is invaluable. I think this is…
> Sometimes, you don't want to have the file pulled down and edited in a local edit and pushed back even if it is seamless. The benefits of inplace editing on remote machines is invaluable.
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.
Re: TermKit - a graphical terminal replacement
#86I had a similar idea about 10 years ago, but never got around to implementing it. I'm amazed at the amount of hatred directed towards this - as if the terminal could in NO WAY be improved?!. But clearly it can. For example - wouldn't it be nice to have a terminal status bar with your CWD / git branch / etc in, without cluttering up space before $? Yep, you can use screen, and that destroys your ability to use the scr…
"I'm amazed at the amount of hatred directed towards this - as if the terminal could in NO WAY be improved?!"
Improve it all you want, I'm totally into that. The problem is that once your "terminal" ceases to be a terminal emulator then you lose so much it's pretty unrecoverable.
Most of the things that you suggest are very much technically possible for a shell (perhaps zsh with some extensions) running in xterm. You'd be left with some sort of unholy combination of a rather modernized `mc` and an otherwise modern shell, but it'd be a very interesting product.
tl;dr: We're not opposed to improving the 'terminal'. I'm opposed to 1) mistaking "improving the terminal" with "improving the shell" and 2) losing the terminal.
Re: TermKit - a graphical terminal replacement
#87This is interesting, but I have doubts. He wants to fix the terminal by 'separating the "data" part from the "human" part'; in practice, using separate visualizers for human display. This puts me another degree of separation away from my raw data and forces me to trust the accuracy of the visualizers.
Re: TermKit - a graphical terminal replacement
#88It's funny, his 'ls' by default prints out an information-sparse grid of icons (only showing 10 items with a horizontal scrollbar?), whereas when I use the command-line, I'm looking for exactly the opposite of a GUI - an information-dense table of text. I agree with the commenter that -r-xr-xr-x - or even 0555 - is far better than "you can't touch this" (which doesn't describe who can't touch it, and in what ways). H…
> 'His "rich display" is actually a display of poverty'
Presumably the "view" for `ls` will be configurable, so this is not an important issue. The worrying part for me is that it's another of layer of separation between me and my data.
Re: TermKit - a graphical terminal replacement
#89Earlier quoted context omitted.
It is amusing how we hackers, who are supposed to embrace change, become as Luddite as anyone else when our sacred tools are questioned. Personally I see room for this and a whole lot more. I'd like to see an amalgam of this and the traditional terminal (easy way to pull up a traditional terminal if you need it). There is no need to "replace"; I think this makes a fine addition to a hackers workspace.
It is amusing how we hackers, who are supposed to embrace change, become as Luddite as anyone else when our sacred tools are questioned. In my experience, programmers as a whole are actually more luddite and irrationally reactionary than the general populace.
Really? I see the same thing whenever you get a bunch of professionals together and start arguing about their tools.
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.
Re: TermKit - a graphical terminal replacement
#90Earlier quoted context omitted.
It is amusing how we hackers, who are supposed to embrace change, become as Luddite as anyone else when our sacred tools are questioned. In my experience, programmers as a whole are actually more luddite and irrationally reactionary than the general populace.
Really? I see the same thing whenever you get a bunch of professionals together and start arguing about their tools. 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 stu…
Doctors and different drugs/treatments, Contractors and brands of power tools.
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.