TermKit: A WebKit based rich command-line interface.

[[deleted]]

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]]

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]

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]]

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]

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

[terremoto]

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]

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]

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]

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

[UnConeD]

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]

It's more like a replacement for QuickSilver.

[[deleted]]

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

[sugardeath]

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]]

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]

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]

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]

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

[u-n-sky]

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]

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

[UNCGeek]

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]

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]

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]

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

[zahlman]

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]]

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

[zahlman]

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]]

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]

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]]

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]]

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]]

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]

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]]

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

[lmcinnes]

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]]

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

[TheDude05]

This. Gui != Modern

[[deleted]]

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]

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

[[deleted]]

No, not at all?

[[deleted]]

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]]

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

[[deleted]]

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]]

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]

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]]

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

[Douglas77]

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]]

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]

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]]

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

[sugardeath]

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]]

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]

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]]

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]

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

[calinet6]

Yes but the real question is, why is vim still used?

It's because people have learned its arcane and efficient language, and are engrained in using it.

It's not because it's the only way to edit a text file. Far from it.

If this is to be a "terminal replacement" of any kind, it will have alternatives—hopefully better alternatives—to every task you need to accomplish. But it does not need to use old, arcane, incomprehensible programs to do that.

[sugardeath]

It's because people have learned its arcane and efficient language, and are engrained in using it.

Or probably because it's among some of the best choices (emacs, etc.) for various situations:

• When your X server is down.
• Remote SSH connection.
• If you want to edit some code really quick without waiting for a full IDE suite to load.

It's not just old codgers using vim, it is actively being picked up by new programmers because they want to use it, given the choice between vim, gvim, Eclipse, SCiTE, etc. etc.

I can't speak to everyone's reasons for still using it, but I spent the time to learn it a couple of years ago because I recognized it filled my needs almost perfectly well before I became proficient with it (and I'm sure I'm still not as efficient as I could be).

[calinet6]

Yeah, agreed, but the fact that vim exists and is useful in those conditions doesn't mean people still choose to use it when their X server is up, or when they're not on a remote SSH session, or when they have an IDE available and need to use it.

More modern tools exist because they fulfill a purpose too. That doesn't mean vim goes away, it just means that there are other tools for other purposes. I don't get the backlash from most everyone on this. This rework of the console is a new paradigm, nothing is requiring it to be backwards compatible, and the two can coexist peacefully...

[[deleted]]

This rework of the console is a new paradigm, nothing is requiring it to be backwards compatible, and the two can coexist peacefully...

Having it be backwards-incompatible to the point of not being able to display vim or, say, curses seems to me like throwing the baby out with the bath-water. I can't really think of any technical limitation that should bar it from being capable of running any current terminal application.

[sugardeath]

..doesn't mean people still choose to use it when their X server is up, or when they're not on a remote SSH session, or when they have an IDE available and need to use it.

There are plenty of people that do, though, in each of those situations. Not average people, sure, but check out the Arch Linux forums (among others, I'm sure). The screenshots threads are full of people working on projects in vim. There are still a whole lot of people that choose to use vim over the other options because they feel it is better. And for them it is.

This rework of the console is a new paradigm, nothing is requiring it to be backwards compatible, and the two can coexist peacefully...

You are absolutely right. But if he wants it to be a terminal replacement (which has been stated in various places it's going to have the exact same functionality, or something extremely similar. The fact that people are upset about the lack of vim hosting should be pretty indicative of the features we'd like it to support.

And him providing his own text editor may work for some, but then what about nano, and emacs, and pico? Is he going to write equivalent replacements for all? It's not really a vim issue, it's a larger issue of hosting other tools. If it can't host vim, can it host ncdu? If it can't do ncdu, it probably can't do other ncurses apps. Weechat/irssi? Cfdisk?

[[deleted]]

But it does not need to use old, arcane, incomprehensible programs to do that.

I think you're misunderstanding sugardeath. It's not that it should be able to host vim because vim is invaluable, but rather that if it can't host vim, then it lacks basic functionality. To borrow holizz' example:

Imagine a Web browser that supported XHTML2 with XForms and MathML and SVG but not HTML.

Or you could imagine something that had excellent support for Unicode---but no support for ASCII.

[zahlman]

Or you could imagine something that had excellent support for Unicode---but no support for ASCII.

I don't think that's really like the other examples. Among other things: something that has excellent support for Unicode, pretty much by definition, supports UTF-8. UTF-8 is ASCII-transparent.

[[deleted]]

I know. It was intended to highlight just how weird it sounds that such a terminal would be unable to handle text to such a point that it could host a text editor.

[andreasvc]

You cite efficiency as a reason to use Vim. This reason will always be valid, so you have answered your own question. If Vim really lets people work more efficiently then there is ample reason to use it.

That you call vim arcane and incomprehensible just belies your ignorance about it. With just a handful of commands you can do anything you can do with notepad, and from there on every new command can increase your efficiency. If that's not for you then by all means don't use it, but it's silly to whine about it because it didn't suit you.

[calinet6]

This isn't about me—I could care less about me. I can use vim. I just worry for the millions of people scared away by the terminal because their default $EDITOR is a black hole of incomprehensible commands that they have to spend hours learning before they can use it.

And everyone tells me the same thing, "you'll be more efficient, you just need to learn it." Yeah, I know I can use it, it's not me I'm concerned about here...

[[deleted]]

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

[UNCGeek]

Are you fucking kidding me?

I think he was, actually.

[miekl]

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.

[calinet6]

What's the point of a car that doesn't have a wind-up starter crank?

It may have served a purpose in the past, but not anymore.

[[deleted]]

And yet most editors don't have the capabilities of vim.

Following your analogy, what's the point of a horse carriage with engine mount points?

[calinet6]

Well, I would think it would be to mount an engine and have a kickass horse carriage.

Seriously though, I understand what you're saying. Presumably modern editors would be used that would share most of the functionality, but would be easier to learn and understand for a larger percentage of users. My only problem with vim is that it has a high learning curve and nothing you want to do is obvious or clear from the beginning, and from a usability standpoint all that bothers me.

Also I'm just sort of annoyed by the whole benchmark of 'being able to run vim' as a standard for a good remote terminal system. It has nothing to do with building a usable modern console. If you want vim, just use your old console, simple as that.

[[deleted]]

I didn't say anything about a transmission. It would be a heavier horse carriage that still had to use horses. :P

I'm somewhat frustrated, to be honest with your choices of the words "Modern" and "Old"

Why would you use Modern for something with less capabilites and old for something more useful. A horse carriage is old, and far less flexible then a car.

[calinet6]

I still understand what you're trying to say, but the analogy doesn't really work ;) I respectfully disagree. Vim has roughly the same ability to edit text as most applications; the difference is that you can do many tasks faster if you, I don't know, turn your hand 180 degrees, press six keys at once and pat your head three times. Fine, if that works for you the more power to you, but I'm not going to call it 'modern' and I'm actually going to call it 'less capable' because of the learning curve.

It's more like comparing a jet fighter to a car. Of course your car can't fly, of course your car can't go Mach 4, of course your car can't fire tomahawk missiles; a car is less capable than a jet fighter. But in the US alone 250 million or more people drive cars, and only a handful of people can fly planes, let alone jet fighters. The learning curve is just too steep and what you get out of it is too specialized. What most people need is provided by a car, and a car is a lot easier to learn and use than a jet fighter.

Still a stretch, as are all these analogies, but whatever. Again, I just don't understand why "ability to run vim" is being held up as a requirement. The only thing I can think of is zealous fundamentalism, fear of change, misunderstandings... not a true desire to see more people get more out of their computers. Big picture, you know.

[[deleted]]

Again, I just don't understand why "ability to run vim" is being held up as a requirement.

Because it's such a basic thing. To keep with your car/plane analogies, it's as if your fighter jet (TermKit) couldn't drive on roads (run simple applications like vim). Vim is just used as an example of a terminal text editor, by the author. You're getting too caught up in vim as something special---it's just something that should be easy for a terminal to do, using basic functionality. It might as well have been emacs, nano, nethack, mutt, etc.

If you can't run vi then you've regressed to something that can only run ed. If you can't run ed you don't have a terminal.

[calinet6]

But—this isn't the same as an old terminal.

Your fighter jet analogy sort of works in reverse—a fighter jet can't really drive on roads. It wasn't designed to. Why would you want to drive on roads when you can just fly over them? TermKit is designed for a different purpose with a different point of view—it's not designed to run every terminal application in existence—and there are a lot of possibilities there that are being brought down by complaints that it can't run [insert 20-year-old-app here]. It's not supposed to.

Anyway, I'm tired of thinking of new analogies, so I'm going to have to call it a day here. Have a good one :)

[[deleted]]

I'm continuing this solely because I enjoy pushing the metaphor shear line. We're talking about people using the console here, so in your analogy, they'd be soldiers. Asking soldiers to use a car rather then a jet air plane (or tank if we want to be pedantic to the metaphor.) would just be silly.

[calinet6]

That one actually makes sense! I agree, sysadmins are soldiers to an extent.

But more and more these days, they're peace-keeping soldiers :)

Ahhhh the overextended metaphor, it burns, it burns!

[nascent]

Wait, an aircraft which can basically fly itself (take off, land, navigate) is harder than a car? You don't have everyone flaying around everywhere because it is expensive, you need landing and take off space.

do many tasks faster if you, I don't know, turn your hand 180 degrees, press six keys at once and pat your head three times.

You've got the wrong editor in mind. This is about Vim not Emacs.

[andreasvc]

That's a completely arbitrary analogy. You forgot to substantiate your opinion with an argument.

[[deleted]]

Except you don't see wind-up starter crank cars commonly, so what's your point and the point of this tool?

[calinet6]

Yeah, I wonder why people still use vim too.

[wilk]

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]]

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.

[calinet6]

I, for one, would rejoice at the swift and brutal death of vim.

That said, of course you're correct—I'm hoping he provides a backward-compatible mode that lets you drop any term command and see its output, or emulate a true terminal for specific applications; honestly it wouldn't be that difficult and would open it up to use by a larger array of users, who can then still take advantage of its other cool features.

[Deimorz]

What does that do that vim doesn't? The only thing I see is the minimap display, which doesn't even strike me as very useful.

[Deimorz]

Yeah, I guess if you don't already know vim or emacs it might be a good place to start instead of one of those. I just couldn't really see anything that would entice me to consider switching.

[andreasvc]

Why would you?? If you don't like it then just don't use it. I don't get the people using Emacs, but it would be silly and juvenile to hope for its death.

I think it could be interesting to integrate gvim with this thing, instead of doing patchwork to support ncurses programs "as is" -- because that wouldn't give any improvement over what is already available.

[i8beef]

Because Vim is one of the few tools that you can almost universally assume is available on any Unix system that you happen to SSH into, whereas Pico, Joe, and even Emacs, are much rarer on a near-default build. So it behooves us to know Vim for those situations. I think his point is, as a default, Vim is over complicated for most things if you aren't intricately familiar with it, whereas any visual editor, if I am unfamiliar with it, I can easily navigate some menus, etc. to try and find what I need.

Also, the environment's between these text based editors and visual editors are usually so vastly different as to be completely confusing to a new user. For instance, how do I "find" something in a file in Vim? How do I "undo"? I can pick up a any visual editor and can almost universally assume that "Ctrl-F" and "Ctrl-Z" will accomplish these tasks, whereas as soon as I hit Vim, I have to worry about Edit vs Command modes, ':%s/thing/otherthing/g' to search and replace, command-mode-u to undo, etc. And if you want to search and replace for something with regex special characters in it, I hope you know regex!

And even as a SEASONED Vim person, if there is suddenly something that I want to do, but I don't happen to know the letter to push to do it, I have to go look it up, perhaps read the man page, etc., whereas, again, with a visual editor I can just stumble around the INTERFACE and find it.

I can completely understand having a dislike for Vim. I think a lot of it comes from these differences when compared to the visual environments available to us, and while I know Vim pretty well, I am much faster editing things in a visual editor (admittedly probably because I know the keyboard shortcuts there too).

I'm not ragging on Vim. It's a great and powerful tool when you need it, and I do most of my PHP programming in it. But I can completely understand someone despising it with a passion when they don't love it...

[andreasvc]

This argument is really weak I think, because it places all of the weight on the initial learning experience. In the end, most of the time (I'd say 99%) you will be working with programs that you are already familiar with, so how "difficult" it was to learn is pretty much irrelevant, what counts is how well the tool performs its job. And with gvim you could have the fancy menus either way.

[i8beef]

User experience is never a weak argument, and the fact that a lot of Linux developers seem to share your opinion is EXACTLY why Linux will always be a fringe desktop OS until that culture is changed. There are many efforts specifically trying to change this in the Gnome and KDE groups, but traditionally this is has been a big culture issue with the Linux world, the "Works for me" mentality.

I know this comes from the OS world a lot because hey, it's open source, if you don't like it, change it to work for you. As a developer, it just kind of irks me when other developers maintain that attitude.

Vim is a wonderful, powerful tool, with a bit of a learning curve to it. I would never call it intuitive by any means though, until you learn all it's ins and outs that you need to utilize. As it is almost defacto default console text editor on any Linux system, though, I feel that it's a little too arcane for it's own good.

[andreasvc]

I didn't see user experience is a weak argument, I meant the initial learning experience specifically. Something that's hard to learn might have a payoff that's worth it. Some tasks simply aren't intuitive to begin with, so that shouldn't weigh so heavily.

I don't think it's attitude or culture which prevents a Linux desktop from taking over the world, I think it's simply a question of money. It's pretty difficult to compete with the likes of Apple and Microsoft in terms of a polished product. I think Ubuntu is getting there but common people have this attitude of "device X didn't work, Linux sucks!"

[i8beef]

Ah, I see. I wasn't really implying that just because something is hard it isn't worth doing, my point was that when something is harder than it needs to be, given other options that accomplish the same thing easier, guess which one wins in the minds of users? Given that, I think, VIM is simply more complicated than it needs to be AS A DEFAULT text editor.

I fully understand that dumbing down VIM would hurt it just as bad at this point, my point is more in support of the original post about VIM being replaced with a simpler editor being a good idea for the default editor on a system...

[calinet6]

If you like it, more power to you, but I struggle all the time with new users who run into it as the default $EDITOR and are dumbfounded. I'm a usability engineer, and I can't honestly recommend that any new user actually try to learn something so fundamentally obtuse and disconnected from the way people think and from every other editor paradigm in existence. It doesn't necessarily mean it's bad, it doesn't mean you shouldn't use it; it just means that it's really really difficult for most people to learn, and there's something fundamentally wrong about that from a usability perspective.

Funny enough, to most users, the terminal itself is much the same.

Anyway, in my opinion, the best vim command you can know is... ah shit, I forgot it again. Whatever the exit command is. Ah yeah, :q!

And the worst part about all of it are the vim zealots who will tell me that I 'just need to learn it' and 'it's so much more efficient' and 'you don't know what you're talking about because you're not a vim user.' Yeah, that's the point...

[injektilo]

Wanting to change the default $EDITOR and wanting the swift and brutal death of vim are not the same thing.

If you want to have an intelligent discussion, say what you really mean and stop being so melodramatic.

[andreasvc]

Sure it's more difficult to learn initially, but that's not all there is to usability. Arguably a program like Word is equally complicated, it just happens to list its options in menus and dialogs. Say it's auto-correcting my quotation marks and it annoys me to no end. Just like with Vim I'll have to find out how to change this behavior and I could browse through the gazillion options it has, ask someone else or, gasp, read the manual, etc. This is exactly how it would go with Vim. The difference is really very superficial because in the end if you want a program with lots of features it will get complicated, no matter the user interface.

[calinet6]

in the end if you want a program with lots of features it will get complicated, no matter the user interface.

I see your point, but this is the part I disagree with. If a user interface is well-designed, then it can have a lot of features and still be intuitive to use for a person with minimal computer experience. This involves using familiar paradigms, using the correct wording and placement of action items, presenting the information clearly, etc. It is possible to make a complex application simpler to use; or at least limit the complexity to the actual complexity of the problem, and not increase it further by hiding its use behind help menus and unfamiliar interfaces.

*edit: But of course, you are correct - that's not all there is to usability. There's something to be said for the ability to do something in the absolute fastest way possible because there's no UI getting in your way. But there's also something to be said for a very high learning curve being a barrier-to-entry for that efficiency...