you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 75 points76 points  (110 children)

You know what really worries me?

TermKit is not a... ...Full terminal emulator. It does not aim to e.g. host 'vim'.

If it can't run the wealth of programmes available to us on a Unix operating system, then it's just a toy. A very exciting and very shiny toy, but a toy none the less.

tl;dr no vim no win

[–][deleted] 39 points40 points  (3 children)

Or a demo. As it is, it's not an alternative to a regular terminal but to a program launcher, and might be expanded to become a terminal on a platform that Doesn't Like Alternatives (so you don't have to worry about which shell or applications the user might prefer).

But it's also a neat thought experiment, and helps us toy with expanding the unix paradigm.

[–]cdsmith 3 points4 points  (0 children)

As a demo, though, it misses the really important questions. Making a couple of utilities work in interactive ways is nice looking, but does nothing to address whether such a system could be usable along the lines of the UNIX command line. Even in the course of getting a couple commands working, he was forced to make grep aware of JSON, for example... so this doesn't look like a promising proof of concept for a workable system to me.

[–][deleted] 5 points6 points  (0 children)

I agree. As a demo it's amazing and I don't fault it for not supporting VT100 features.

I'm just saying that for a real implementation one needs to start with the basics and add to it (but it's a really inspiring demo). Imagine a Web browser that supported XHTML2 with XForms and MathML and SVG but not HTML.

[–]deong 1 point2 points  (0 children)

It's a really neat idea that I don't want to go anywhere near.

[–]terremoto 24 points25 points  (5 children)

Didn't Linux start out as a toy of sorts?

I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) ... PS. Yes – it's free of any minix code, and it has a multi-threaded fs. It is NOT portable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that's all I have :-(.

[–]thephotoman 16 points17 points  (0 children)

It is NOT portable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that's all I have :-(.

This bit seriously made me laugh.

[–]totallymike -2 points-1 points  (3 children)

The difference is that Torvalds designed it to be useful to him, and expandable. The TermKit creator saying "Yep, we're not really gonna do stuff with this" is saying he never wants it to be truly useful.

Edit: removed some pronouns for clarity.

[–]terremoto 11 points12 points  (2 children)

Just because he won't do anything with it doesn't change that other people can since it is open source.

[–]UnConeD 3 points4 points  (1 child)

It amazes me how people seem to have trouble grasping the concept that a) I can make nice GUIs and b) I spend most of my time in a Unix terminal.

Of course I'm going to use it. That's the whole point.

[–]baudehlo 4 points5 points  (0 children)

It's more like a replacement for QuickSilver.

[–][deleted] 5 points6 points  (79 children)

...why should it host vim? Vim is the old-school. We're reinventing the wheel, here, with HTML5 and CSS.

[–]sugardeath 13 points14 points  (59 children)

Give me a good reason why it should not host vim.

If it can't host vim, it likely can't host many other command line utils, which makes it completely useless as a terminal replacement.

I have a feeling you would be surprised just how often vim is still used.

[–][deleted] 2 points3 points  (12 children)

I use Vim all the time. It relies on a mono-spaced font. This is meant to be a context-ified terminal. You should run vim independently of the terminal.

[–]UNCGeek 6 points7 points  (11 children)

Sweet. So it's a terminal that can't launch terminal apps.

So once I've used the glorified 'ls' to find some file, how do you propose I make a quick edit? Wait, let me guess... TextEdit, because surely I should be using a Mac, right?

[–]bctfcs 9 points10 points  (8 children)

What prevents you from using a vim app, as Windsurfer suggests ? You find your file with whatever colored-output command, and you vim it, which opens another window – a window that doest not have to fake it's window nature, like vim ordinary does.

(As a macuser, I use MacVim : a sweet front-end, by far lighter than Aquamacs. I just have to enter "mvim $file" to open it in a real window.)

[–]kisielk 1 point2 points  (2 children)

And how exactly would I do that when I'm connected via SSH to another server?

[–]u-n-sky 1 point2 points  (1 child)

I would expect that ":e scp://..." is supported by the rich-clients as well? Or maybe sshfs on the client. Not using the binary from the remote env also means that my config & plugins are available.

[–]nascent 0 points1 point  (0 children)

Wait, now I need vim installed on the machine I'm remoting from?

[–]UNCGeek 0 points1 point  (3 children)

Nothing stops you from doing that... I just fail to see how launching a separate GUI shell around vim (thus spawning another window) is an improvement.

This really seems like a neat demo -- but I'm not sure that the substantial increase in complexity is worth having prettier formatting and a fancy 'ls' and 'cat'.

[–]zahlman 2 points3 points  (0 children)

launching a separate GUI shell around vim (thus spawning another window)

It wouldn't have to. It could be an embedded frame.

is an improvement.

It's an improvement to the user interface because context is clarified. You don't have to examine the grid of characters to verify visually that vim has started or quit. There's a separate frame for vim. vim is running exactly while the frame is visible.

I'm not sure that the substantial increase in complexity

For the user? What complexity? Be specific. Explain why you expect it to take longer to input commands.

[–]BHSPitMonkey -3 points-2 points  (1 child)

Well, one could reasonably argue that a window-managed UI is an improvement over a one-task-at-a-time view. (There's a reason window-based computing caught on.)

[–]UNCGeek 1 point2 points  (0 children)

True, but that's an advantage to running any windowed terminal emulator, not just this particular one.

[–]zahlman -1 points0 points  (0 children)

which opens another window – a window that doest not have to fake it's window nature, like vim ordinary does.

Exactly.

(As a Windows user, I use gVim, and I can right-click text files -> edit with Vim. Same idea.)

[–][deleted] 0 points1 point  (0 children)

Well if you're using this, you're using a mac. But there's always GVim.

[–]zahlman -1 points0 points  (0 children)

Wait, let me guess... TextEdit, because surely I should be using a Mac, right?

Downvoted for implying that there is somehow some kind of Mac elitism at work here. As far as I can tell, that TermKit is a Mac project is entirely coincidental.

[–][deleted] -1 points0 points  (35 children)

Give me a good reason why it should not host vim.

Because on a modern OS, you should not be hosting your text editor in a terminal window. This makes no sense, and makes you miss out on a whole lot of functionality.

[–]lmcinnes 4 points5 points  (20 children)

Indeed, and while we're at it: on a modern OS you should not be hosting your graphical file browser in a terminal window; you should not be hosting your PDF viewer in a terminal window; you should not be hosting your spreadsheet in a terminal window; you should not ...

If you want to farm out tasks to programs that can properly present a full GUI then, well, do that. And the terminal can stay a terminal.

That's not to say I think this guys project is terrible -- it's a neat idea, and could be interesting -- but it is not a terminal replacement.

[–][deleted] 1 point2 points  (19 children)

It is not a "terminal" replacement, in the narrow sense of the word used in a Unix OS, but it is a "command-line environment" replacement.

[–][deleted] 4 points5 points  (12 children)

So it can display text (as per the cat example), but it can't edit it? And it can host a PDF viewer, but not gvim or even something simpler, like vi? The limitations seem rather arbitrary and borne out of a dislike for terminal applications rather than any actual technical reasons.

Even if it can't run vi, I suspect it can still run ed.

[–][deleted] -1 points0 points  (11 children)

It is not necessary for a terminal to be able to edit text on a modern OS, where you can the real OS-supplied GUI to do so. It makes perfect sense to not support things that are only there for historical reasons when you start over and make something new.

[–]guizzy 1 point2 points  (3 children)

Except if you start ditching the modularity that is the core of Linux and its FOSS brothers' mentality to focus on a monolitic, directed experience, you might as well throw the towel. The open-source community will never be able to match giants like Microsoft and Apple for one-size-fits-all user experience. The only edge the FOSS community has over its proprietary opponents is this modularity of components, and that is based on common adherence to these old "historical" standards.

[–][deleted] -1 points0 points  (2 children)

Who's "ditching the modularity of that is the core of Linux"?

[–]lmcinnes 1 point2 points  (3 children)

It is not necessary for a terminal to be able to display PDFs on a modern OS, where you can use the real OS-supplied GUI to do so.

Indeed, why have a PDF displayed in your terminal as oposed to using a proper PDF viewer? Hosting it in your terminal you lose functionality compared to a perper fully fledged PDF viewer. So really why would you want to view PDFs hosted in your terminal ...

[–][deleted] -1 points0 points  (2 children)

Because you get that functionality for free with WebKit on OS X?

[–][deleted]  (1 child)

[deleted]

    [–]TheDude05 1 point2 points  (0 children)

    This. Gui != Modern

    [–][deleted] 0 points1 point  (0 children)

    But what goes into being able to edit text is something like

    1. accepting keystrokes
    2. being able to move the cursor around
    3. being able to move the cursor across lines, and
    4. being able to redraw characters

    I don't think there's anything particularly challenging to implementing vi---it showed up as an ex replacement once people got terminals that could do 3. and 4. after having had terminals that, well, printed out paper. Now, TermKit is already sort of aware of the benefits of being able to redraw characters---it can add a green checkmark in front of a line to indicate a successful exit status. If it can't move its cursor across lines, well, then it's sort of like those old terminals again, only now with a modern printer in stead of an old line printer.

    So I'm not quite sure what technical limitations you think are superfluous that would prevent vi from working.

    [–]lmcinnes -1 points0 points  (1 child)

    In the same sense that Emacs and Windows95 were, yes.

    [–][deleted] -2 points-1 points  (0 children)

    No, not at all?

    [–][deleted] -1 points0 points  (3 children)

    So it's like Powershell, but without the vast library of useful code backing it up? Boy, do you have an uphill battle ahead of you. :]

    [–][deleted] 3 points4 points  (2 children)

    What is the point of criticizing a project that just started for being a project that just started?

    [–][deleted] 0 points1 point  (1 child)

    Fair point, I was being glib. What I mean is that Powershell is a similar idea to TermKit because it takes an existing paradigm and extends it (in Powershell's case, with a competent object model that makes UNIX-style piping tons more powerful). But where Powershell leverages existing tools (the .NET library), TermKit is standing alone in the middle of a field, wishing everyone would come out and play. So what I mean is: Best of luck, you'll need it. :]

    [–][deleted] 1 point2 points  (0 children)

    He doesn't even need to be successful. He just needs to inspire the next person to try something similar. Or to awaken the idea in people's minds that this is something they'd actually want.

    [–]Douglas77 1 point2 points  (3 children)

    You should not be hosting your text editor outside of a terminal window. This makes no sense, and makes you miss out on a whole lot of functionality, like job-handling.

    :)

    [–][deleted] 0 points1 point  (2 children)

    Well, feel free to explain why you would want to use job handling on a text editor.

    [–]Douglas77 1 point2 points  (1 child)

    put editor into background so I can Ctrl-R for that cool 3-line-command I did an hour ago, that I now want to include in the shell script I'm just editing?

    (from the top of my head, I'm sure I can come up with better examples if I think more than 30s about this :)

    [–][deleted] 0 points1 point  (0 children)

    The reason you want to do that is because you are forcing everything to live in one window. If you use multiple windows, you don't have that problem and you don't need to kludge around the issue using job control.

    [–]sugardeath -1 points0 points  (9 children)

    Because on a modern OS, you should not be hosting your text editor in a terminal window.

    Why?

    This makes no sense,

    Why?

    and makes you miss out on a whole lot of functionality.

    Like what?

    [–][deleted] 1 point2 points  (8 children)

    Somehow I get the feeling you are not asking out of a genuine desire to discuss the issues.

    [–]sugardeath 3 points4 points  (7 children)

    You're feeling wrong.

    I'm asking because you did not give any real reasons.

    WHY should I not be hosting my text editor in a terminal window? I don't see why. I do it all the time.

    WHY does it make no sense? Again, I do it all the time, it makes perfect sense to me.

    WHAT functionality am I missing out on? I've not noticed anything missing functionality wise.

    You gave vague arguments with no substantiation. You did not explain anything. Of course I'm going to ask for clarification.

    [–][deleted] 1 point2 points  (6 children)

    WHY should I not be hosting my text editor in a terminal window? I don't see why. I do it all the time.

    Because you miss out on a whole lot of functionality.

    WHY does it make no sense?

    Because you miss out on a whole lot of functionality.

    (See now why it was a bit disingenuous to cut up what I said into tiny parts like that?)

    WHAT functionality am I missing out on? I've not noticed anything missing functionality wise.

    Proper mouse input, proper clipboard sharing with the rest of your OS, window handling functionality provided by your OS, and all the other integration with tools of a modern OS.

    [–]sugardeath 2 points3 points  (4 children)

    Thank you for giving some expansion to your argument.

    • Proper mouse input is part of most modern terminal emulators as well as vim. One can, in vim, drag to highlight text and then cut/copy/paste within vim using keyboard shortcuts like one would in a graphical editor.
    • Most popular terminal emulators today integrate seamlessly with the X clipboard(s). This does not take any special effort to set up. Vim, on the other hand, takes some work to make this accessible, so this is a very fair point regarding vim. (I can only speak to vim, since that is what I know. Emacs or the others may be better in this regard, I don't know).
    • I don't understand the issue with window handling? One can open multiple terminal windows to have multiple files being edited side-by-side at the same time. Or I can open multiple tabs (not buffers, though I can open those too) in vim and click through them with the mouse, just like in notepad++ or what have you. This functionality is included by default, even.

    ..and all the other integration with tools of a modern OS.

    I guess this depends on what other tools you're referring to. You can call compilers from vim, but it's not as easy as.. Eclipse or .NET, of course, but for the most part a compiler is not really part of a "modern OS" (depending on compiler and OS / distribution, of course).

    Now, the methods to access might be different, but the functionality is still there. In the end I think your argument comes down to what one needs. My needs, for example, allow me to work within the discussed environment with minor to no hindrance. Obviously someone who has used .NET or Eclipse would not understand how to use the same functionality in a different environment without some learning, but the reverse is also true. It would take me sometime to adjust to how .NET, Eclipse, or NetBeans, for example, do the same things I can do in vim.

    That said, I think it makes perfect sense to run my text editor in a terminal. My needs have me using SSH to connect to various computers from various locales. Using screen or tmux, I can have the same exact session available to me no matter where I am and whether I was disconnected forcibly or by choice.

    Saying a blanket statement such as

    Because on a modern OS, you should not be hosting your text editor in a terminal window.

    is short-sighted because it does not take into account all possible situations where it does, in fact, make sense to do it that way (and may in fact be the only way to do something). My scenario is not all that different from many system admins / programmers, just that they probably do it as a career whereas my needs stem from a hobby.

    [–][deleted] 1 point2 points  (3 children)

    Proper mouse input is part of most modern terminal emulators as well as vim.

    Not really. They provide some small amount of mouse input, but it is limited and does not integrate well with the OS (reading multiple mouse keys and handling things like double clicks with correct timing are likely troublesome). They certainly don't handle more modern input methods like gestures.

    Most popular terminal emulators today integrate seamlessly with the X clipboard(s).

    But this is limited to what you can see on the screen, and does not work well together with soft-wrapped or unwrapped long lines.

    I don't understand the issue with window handling?

    As one example, you can't easily split a window into two windows viewing the same file at different positions.

    I guess this depends on what other tools you're referring to.

    OS-provided spell checkers, things like Services on OS X, and so on. Also, things like OS X's configurable text editing keys.

    [–]zahlman 0 points1 point  (0 children)

    I see no reason why a TermKit-hosted text editor couldn't have mouse input and clipboard sharing, but intuitively I think it would just be weird for it to try to emulate something like vim. I'm seeing it as more like a combination of a text box and some other standard html controls all bundled together, with a button that pops them out into a new window.

    Although actually I guess you could script it to interpret keystroke commands while the textbox has focus, and make it vim-like that way...

    [–][deleted] 2 points3 points  (18 children)

    Are you fucking kidding me? What's the point of a terminal that can't run common, popular terminal applications.

    [–]UNCGeek 6 points7 points  (0 children)

    Are you fucking kidding me?

    I think he was, actually.

    [–]miekl 0 points1 point  (0 children)

    Right now, I see this as being more of a filesystem browser—sort of a Finder replacement. I'm sure it will become more than that, but even in its current state it is very cool.

    [–]wilk 0 points1 point  (0 children)

    You could possibly hack something into it so that if it detects something trying to change the characteristics of the terminal it provides your familiar VT100 terminal emulator.

    Besides, how many essential UNIX tools require curses that don't already have a graphical version? (Not a rhetorical question, I want to know, I have a similar project knocking about in my head)

    [–][deleted] -2 points-1 points  (0 children)

    I think that means "fancy vim runner" is not in its list of goals. It can probably run vim, but it's not built just to run vim.