9 ms·

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

• unconed 15y ago
  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 ;).
  • wladimir 15y ago
    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 you :)
    • unconed 15y ago
      I'm having a blast and interpreting all the flak as a sign I must be doing something right...
      • sudonim 15y ago
        Absolutely! Don't lose that attitude. You won't win over everyone and the fact that anyone cares enough about something you made to share their opinion with you is awesome.
      • maratd 15y ago
        Bingo. If you haven't pissed anyone off, it's because you're not doing anything important. There are people who invested DECADES of their life into a vanilla terminal ... and here you are, fucking with THAT.
        • l3vitat3 15y ago
          the only thing that pisses me off is the guy posting how many years he was administering UNIX systems and how this monster was an "obvious" step in the field, web designers are quite arrogant
      • mariuskempe 15y ago
        I'm so impressed with that. If I was getting that much criticism (for something so obviously excellent!) I'd be shaking in my boots. :-(
        • unconed 15y ago
          Well, a few years ago I made this Line Rider video, and then 10,000 people on YouTube told me to get a life. Who cares what people on the internet say, they're the ones wasting their time posting it.
    • unconed 15y ago
      Regarding your quote problem: the idea is that the highlighted token signifies "quoted string". I plan to add regexp tokens, user@host tokens, etc. each with appropriate autocomplete. 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...
  • roqetman 15y ago
    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.
    • colomon 15y ago
      Thing is, it's not about the tools being sacred. My problem with this is that he's not just solving problems I don't have -- he's solving them in a way that would make my problems worse! 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!)
      • bostonvaulter2 15y ago
        Regarding the too-small windows for ls output option I would love if his ls could display it's output full-screen temporarily rather than needing to make the terminal full-screen first and then running ls
      • 9999 15y ago
        "if I did, I'd probably use Finder instead." The thing that strikes me as very, very cool about this project is that you might not need the Finder at all any more.
        • colomon 15y ago
  • uniclaude 15y ago
    It's just my point of view, I don't really like the stance seem to take here. 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.
    • scott_s 15y ago
      He brought up his own credentials because he is amused that others have questioned them. I find that reasonable and not "bragging."
  • jessedhillon 15y ago
    I love the idea. But as someone who also loves vim, to hear that your vision of a new terminal excludes a tool as powerful and expressive as vim makes me sad, because it means that apparently I won't be able to benefit from this new terminal. I'll watch with interest, however.
    • unconed 15y ago
      If I can make TermKit deliver on its promise, then I'm pretty sure on of you vim guys will take a VT100 JS emulator and make it work in TermKit. Again, the architecture supports it.
• telemachos 15y ago
  The file I was trying to cat is group_add.sh. I understand if syntax highlighting isn't done for shell files, but I'm surprised that '.sh' doesn't trigger monospace fonts. That said, I'm glad to hear that in general monospace for code is the plan. 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.
• timtadh 15y ago
  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 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.
  • thasmin 15y ago
    There is potential for TermKit to send files to your client's Vim, which opens a lot of possibilities. For example, it would be easy to have files from two different servers open. It would also reduce the number of places you need your configuration files. TermKit's author may dislike Vim, but I suspect that he's helped its users in the long run.
    • Cloven 15y ago
      vim (and other editors) have lockfiles, recovery files in case of session crashes, and assume directory locality (e.g., oops I opened the wrong file; :r filename).
  • seabee 15y ago
    > 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.
    • ldh 15y ago
      If it's a server I plan on logging into more than once or twice, it's easy enough to pull down my git-managed dotfiles and have everything I come to expect.
• JoshTriplett 15y ago
  My local editor is vim in a terminal. :) 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).
  • mcs 15y ago
    I agree with this. 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).
    • grncdr 15y ago
      You might want to do :help mouse All of the things you mentioned are supported and work with most terminal emulators (tested with xterm, gnome-terminal, iterm2 on OSX)
    • gbog 15y ago
• tvon 15y ago
  Regarding liking vim, I have no issue with typing "edit foobar.txt" and having a local MacVim open up :) 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.
• comex 15y ago
  > - No scripting language... except the whole thing is built on Node.js... :) [...] 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. 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.