Nice start, looks like a nice bridge to Vim for textmate users.
It's missing a few of the basic vim movement commands (which I have on a wallpaper I put together http://naleid.com/blog/2010/10/04/vim-movement-shortcuts-wal...), but has most of the big ones. The ones I use quite a bit that don't seem implemented are:
C-d - half page down
C-u - half page up
ge/gE - go to the end of the previous word (you do have e/E for next word)
So apparently they are planned, just not yet implemented. I haven't messed with the file much to see what else you can do with it, but I imagine there's a way to override it in .vimrc style and customize it.
:q in a split should close that split, not kill the whole app. I can't use this app until he fixes that, because that shortcut is hardwired into my brain.
There's definitely some neat stuff in there, though.
I think this neatly illustrates the problems with other software have Vi or Emacs key bindings. Everyone has a slightly different set of bindings they use to do things and if you have even slightly different behaviour then it's just more a hindrance than a help. I can cope with learning new key bindings but I can't cope with something that activates my Emacs muscle memory then doesn't quite do what I tell it :)
Also, with the left pane, some way to navigate between files like NERDTree allows would be useful.
vi' and similar should be supported. It means visual select inside quotes.
If you use command-w to kill the last open tab, so that nothing is open, you can't use the command-line ':', which is useful when changing directories to work on another project
Am I the only person who thinks that tabs don't scale in editors used for programming? I tend to have a lot of files opened at the same time (currently at 143 in Emacs) and I can quickly switch to any of these with a couple of keystrokes. Most of the Textmate users I've seen don't even care about the tabs in the editor, they just press Cmd-T and type the name of the file.
Is people doing something else with tabs that I'm missing here?
* the editor keeps a max of N tabs open using least-recently-used
* browser-like navigation by clicking into symbols combined with forward/back history
The autosave part was weird at first, but it makes so much sense. Why bother with explicit saving, prompting "do you want to save", manually closing tabs, etc. Combined with the navigation features, you never care which tabs are open. Edit history plus version control are much better than a simple save/discard model.
Tabs are nice if you are programming just a couple files, or several files from different locations. Any more than that, and I agree that they're far too unwieldy. Vico also has an open files dropdown, and, of course, a folder explorer, as well as Cmd-T.
I think it's a similar phenomenon to people closing windows to free up space on the taskbar (for GUIs that have such a thing like Gnome and Windows). If you remove the list of "open" things people are free to just do what they want and let the OS worry about paging if memory fills up and all that sort of thing. It's a pleasant experience if the abstraction doesn't leak, e.g. Win98 crashing if you opened "too many" programs.
Once you free yourself from this list of things that are "open" (whatever that means) you simply stop caring about the number of items in what is effectively just a "recently visited" list. What value is there in killing those buffers if there's no list for them to clutter? (yes there are lists of buffers in Emacs but you only see them if you want to)
In that light here's my answer to your question: Because he hasn't exited his editor and the number of "open files" has no significance or impact on workflow. While you're deciding whether or not to close a file and trying to anticipate when you may edit it next he's already moved on to editing the next thing.
Good answer. Is there no cost whatsoever to having many buffers open? I like the simplicity of just cycling through rather than searching for whats-its-name-again - seems to be easier to remember for my fingers as well.
A couple of years ago I used to keep 100s of tabs open in FF. Then I went mobile and started caring about watts. Not the same situation, but I think it influenced my few-files-open habits.
For me there is no cost, but I rarely do the cycle-through-all-tabs thing (not never but rarely). For your workflow it sounds like there is a cost. If you work on multiple projects in the same editor instance then there is a significant cost as well, e.g. you may have 5 index.html files open and when you type the desired filename you then have to choose carefully. I have encountered this when leaving Emacs open for days or weeks at a time, switching between personal and work projects.
These days I use TextMate more than Emacs and for small personal projects I like quickly switching between say the readme, makefile, code, and test with Cmd-[1-9]. If there are few files to edit tabs can be advantageous. This stuff is highly personal and dependent on workflow.
I remember with positions of tabs, rather than the names of files. To each their own, but there is still a need for some sort of tab behaviour for some of us.
I've found that it's usually as fast to use the Vim Command-T plugin to switch files even once they're opened than it is to switch back to that buffer directly.
Main exception being the alternate buffer for which I have a quick shortcut - (<leader>, - <leader> being set to ,) The consequence is I usually have piles of buffers open at once.
Edit: sjs puts it better above. Having to think 'is this file already opened or not' and then using that information to determine the command you use to switch to it is rather annoying.
My editor has been opened for 2-3 weeks now so I just keep piling the files from all the different projects. I prefer typing 'C-x b [strat]' to opening '~/dev/projects/something_else/lib/strategy.rb' but it might just be the way I'm used to working.
Leaving emacs open makes it more IDE like, the stuff you were working on last is still loaded. Instead of having to quit and then find all those files again. I work the same way as you. Tabs for any large number of buffers would be a nightmare
I work with both tabs, and buffers in vim. Best of both worlds. Switching to another tab quickly is easy, and opening up files becomes even easier with NerdTree (never did like Command + T). I also have BufferExplorer that allows me to switch buffers easily, but I tend to just use NerdTree anyway.
But I agree with you, I hate quitting vim, it seems like I lose my place much easier when I no longer have those files open.
I've already made the switch to MacVim using Janus - https://github.com/carlhuda/janus but Vico could be interesting. The biggest win here, like with Sublime Text 2, is being able to split the window into panes, which is something I've wanted in TextMate for years. However, what I really want is to be able to open a different file in the other panes, not the same file I have open.
[edit] Okay just figured out how to open different files in split panes. It's a little non-intuitive (you have to select the pane and the use the Open Files drop down, and have that file open in another tab (?!)). Would be nice to be able to select that pane and then just click the file I want in there in the Explorer.
Would really like to have some integration with Git. I don't see the Git .tmbundle available in the list.
It would be nice to be able to bring over a lot of the features of Vim, or maybe you can and I don't see it.
This makes cmd-d open up a vertical split, and cmd-shift-d open up a horizontal one. Same keybindings as in iterm2 and I find them easier than the chording that you have to do normally (which makes my hand feel like it's using emacs).
This app looks great, and for those looking to dip their toes into vi-style editing this may be the best starting point.
As someone who's already gone up the Vim learning curve, though, I'd like a way to use all the customizations I've already collected. There doesn't seem to be a way to accomplish this now, but I'll be keeping an eye on it.
Another comment that this looks great! I've been using MacVim as my main editor and love it, but totally appreciate the polish of Vico -- looks wonderful.
My wishlist, right off the bat (note I know some of this might be unreasonable, but that's why it's a wishlist ;) Mostly centered around a quick transition from MavVim to Vico...
* Would be excellent if I could import a vim colorscheme
* Would be excellent if it could read/use my .vimrc
* Would be _excellent_ if it supported vim bundles/add-ons, but I know that's basically asking for vim :)
* In editing a Ruby file, I wrote 'def' it colored and indented my second line, but only colored my 'end' -- didn't outdent it properly. Small annoyance. Also would be great if I could configure it to auto-insert an 'end' for every 'def' or 'Class' or 'if' etc....
Keep up the great work and get an RSS feed up on your blog so we can keep track of updates...
Looks great. I try just about every one of these new options. Kodapp was my last one, but it didnt last (back on textmate). I'll give this a try as well. It looks like it has even greater potential.
TextMate is a joke. Nothing worse than missed opportunity. Such a huge community behind it and MacroMates seems completely incapable of providing a new release.
After several years of TextMate, I recently switched to Sublime Text (http://www.sublimetext.com/). It's more or less TextMate 2: same philosophy and aesthetic, same bundles, much better performance, split panes, lots of nice features. Sublime makes we want to write and code more.
MacroMates totally dropped the ball. What a shame. Everybody was suing TextMate, everyone was talking about it a few years ago, and they didn't capitalise on that.
"Intangibles are the most honest merchandise anyone can sell. They are always worth whatever you are willing to pay for them and they never wear out." -- Heinlein, "The Man Who Sold the Moon"
I like the editor, but I don't like the fact that it is time limited to just 5 days. Yes I understand that you want people to download the latest and greatest for testing, it just seems wrong.
Overall it looks fantastic, but I am pretty dead set on my MacVim ways with my various plugins that it is going to be hard to get me to switch.
Ok, so playing with this for a bit I just realized how much I miss TextMate's tab triggers. I hope this project goes forward, especially if it either a) gets open sourced, or b) gets other developers on board. I'd hate to see it go the TextMate route of getting popular and then taking forever for new releases to come out because the sole developer gets burnt out.
A few things that would be nice:
- Command line launching (like the "mate" or "mvim" commands)
- Ability to edit tmbundles within the app
- Downloading tmbundles seems to duplicate tab triggers
- Snippets still use hard tabs even if you've selected space-based indentation (soft tabs)
- Hitting backspace when you are using soft tabs and are in the "indentation part of the line" should go back that number of spaces instead of just one
Vico is like so close to becoming my main editor, if only these things are fixed. As others have said, a .vimrc-style config would be cool (as would a :retab command), but those aren't deal breakers for me like the above things are.
So sad that this is closed source. It looks very nice but I feel very uncomfortable knowing that if there are any issues which bug or annoy me or things I would like to have but which do not exist yet, I can do nothing about it.
I expect you're being funny and ironic, but I use my editor way more than I use my OS. Generally speaking, the OS is a platform and the editor is a tool.
* The Vico "blog" does not have an RSS feed, so it's not easy to track future announcements about Vico.
* Firefox's AdBlock seems to be blocking your hotlinked Twitter icon, so there is no obvious Twitter link to follow. The "Follow Vico on Twitter" text should probably be included in your <a href>.
> strong focus on keyboard control (vi key bindings)
> scriptable in nu
I'm sure nu is million times better than Vimscript, and it probably wouldn't be hard for me to port my half dozen custom key bindings to it, but vim has a lot of existing plugins...
It's definitely not as fun to implement, but I'd much prefer to see a custom GUI that's really vim under the hood.
Good start !
It seems a bit heavier than MacVim (bigger memory footprint), but the simplicity of configuration and the textmate bundles will surely make it very nice for users coming from mainstream text editors.
Focusing on a clear and usable OS X experience is definitely the way to go.
If you are capable of switching editors, what does it matter if it's closed source or not?
This adversity to switching editors is a common trait in programmers I can't quite understand. We programmers learn new things all the time, it's part of what makes us excel in our profession. And yet, adopting a new editor is apparently extremely hard.
Perhaps it feels extremely hard because a preferred programming environment is so deeply tied to muscle memory via key bindings (which, admittedly, Vico is trying to address for vi users), whereas learning other new things engages other more flexible parts of the brain.
Learning new tools to use, new techniques to employ, new languages to express yourself, new environments to deploy in, new projects to hack on ... and for devops, new daemons to configure, new setups to benchmark ... these are the vast majority of a working programmer's time so switching editors is trivial in comparison.
Arguing against something because it takes away coding time is a sign that you probably need to broaden your experience.
I am primarily a Textmate user as I do a lot of Ruby, Rails, and web work, but a while back when I started learning Lisp I felt compelled to use Emacs. I was some of the most fun I've ever had. And I would contend that extending, customizing Emacs with .el files is a form of coding.
TextMate 2's troubles aren't competitors, but rather that the author is apparently out there thrashing in the weeds. If it does get reeled in and actually released, I bet it will be good enough to consider.
I'm never quite sure if all these Vim commands people rave about are any better than judicious use of the alt/option, shift, command and arrow keys with the default Mac behaviour.
Although one essential change to the defaults is to remap CapsLock to be the same as Control --see System Prefs-- and then using Control-F to move the cursor forward one. Helps you get past automatically inserted closing brackets with minimal hand movement. I find that really tedious and annoying otherwise.
I really wish MacVim would somehow build the NERD_Tree plugin into the native chrome of the editor. Either as a drawer (like TextMate) or a source list like this one. That, combined with the Command-T and snippetsEmu plugin would complete MacVim as the perfect text editor on OSX for me.
With only one file open, and by pressing :q I want to go directly to the Explorer and not close the program. This is the behavior to NERDTree, and I'm used to it.
Really nice start! I've been enjoying modal editing in Vim. One of my pain points is that I feel like I don't have a lot of control over which buffer I'm closing when I :bd or what will happen when I open a new file when selecting it in Nerdtree. Sometimes it replaces a buffer, other times it splits the window. Im sure it's me not understanding how vim works, but I seem to get the mental model in Vico a little better. Bravo!
I've been debating peepopen but without a trial/demo of some sort I haven't really been willing to dive in. Would you say it's worth it for a vim user?
Very nice! I'm a vim novice, but I use it a lot to make quick changes to config files. Is there a good vim help resource that could be integrated in to this program for newbies like me? There are many things I like about vim, but I'm always forgetting keybindings.
Excellent program, though! I look forward to watching it as it develops further!
This looks nice. I've been trying to find a text editor that doesn't make me completely uncomfortable since I moved to mac but after years of EditPlus (editplus.com) everything's felt so awkward, especially since I can't even figure out how to get the file/folder navigation panes to show in anything lol.
So any word on if it'll be closed or open when it's done? I wouldn't mind paying (especially if that would speed delivery of a usable product), but I'd be worried about it becoming abandonware a couple years later (cough TextMate).
I just want to say that this is a fantastic app and fits a longing I didn't even know I had. While a lot of comments below note nitpicks, I want to just commend the author for a fantastic product. I hope it advances and is for sale soon!
This could be very good, I am still trying to find my perfect editor Vim's learning curve & interface means occasionally I just open up sublimeText2/TextMate.
Great to see split views are there from the start.
I don't want to take anything away from Vico (because so far it is pretty rad), but if you stick with MacVim you eventually start using TextMate less and less until you just stop altogether. For me, it took a good 3 months or so. The last holdout was using TextMate for formatting JSON output, but I found a Chrome plugin for that.
I love MacVim too, and have dropped Textmate completely. The only thing that I don't like about MacVim is that scrolling through text (vertically and especially horizontally) feels choppy compared to Textmate. When I see someone else scrolling through code in Textmate, it looks unbelievably smooth and fluid compared to what I'm used to in MacVim.
That's because scrolling with the mouse was a bit of an afterthough, I think. If you use motions, word objects and Ctrl+f/Ctrl+b you don't really notice this choppiness.
Actually I rarely use the mouse and was mainly referring to Ctrl-f/b and j/k, as well as w on long lines. I don't actively notice the choppiness until I use some other editer, but I wonder why it exists in the first place - is the rendering engine slow or something?
I suspect the reason is the same as on emacs: scrolling always occurs line by line (i.e., there is never a partial line visible at the top or bottom of the screen), whereas on most modern text editors it scrolls by pixel, so it's more of a continuous transition.
I love emacs, but this is one of the sticking points that's really been bothering me of late.
On a side note, it looks like with emacs's set-window-vscroll command, you can actually make it display a fraction of a line. Has anyone had any luck hacking this into a way to do smooth, continuous scrolling?
your right and I have seen my percentage time on vim get higher an higher over the months, but thats from persistance. Its slow progress because I mainly work in eclipse and the vim plugins aren't 100% great for me.
Vim is just hard work getting going, e.g. in HTML I like to have the closing tag automatically done for me which im sure vim can do but i've just not had chance to look into. There are 100 other small things like this which I solve one at a time but often I just go 'cock it' and open it up in another editor. But then I want to split the window and open vim again....
It took me one month and a half to stop using TextMate. Once you are accustomed to oOaAiI, rR, wWeEbB or ci( or all the rest it's very hard to open TextMate and take it seriously.
That has never happened to me - I only use MacVim when I need the power features. I'd love to have vim-style modal editing, but my eyes overrule my hands. MacVim is simply too ugly.
Love it! I was seriously considering wrapping MacVim in some sort of Cocoa app with a file drawer, and I'm glad I didn't have to go down that rabbit hole. Very excited to watch this develop :)
First impressions are extremely positive. Is there a mailing list or anything yet? I would love to provide feedback and in return be able to follow the development progress.
several comments, i'm certain someone already mentioned this but you really need to have screenshots on your webpage. anyway, i downloaded the app and my first impression is that this is quite utilitarian though it has a nice cocoa frame. i like the color schemes that you have for default, the page margin and line numbering is essential.
Vico is a Mac OS X text editor with Vim-like keybindings.
If you want to try tiling window managers + Vim, your best bet is to use MacPort to install gvim and either wmii, awesome or ion3. Other WMs worth trying are wmfs, dwm, xmonad… you'll need manual compiling though.
I experimented with an Archbang + wmii setup on my netbook for a few months. I don't see how this app comes close to emulating that experience. I suggest a VM setup.
I think I am going to setup a VM with this. I really want to try the real thing. If it runs well enough in the VM I might just do all my development in and use the host OSX for everyday tasks.
I am looking into getting into Android development. Is it worth doing it without using Eclipse?
Here's the basic problem: you're writing a text editor. Stop doing that. It's 2007. Saying to yourself "I'm gonna build my own text editor" is as silly as saying "I'm gonna build my own build system" or "I'm gonna build my own amusement park."
While you are right at some point I don't think that it would all good if people would stop creating better software.
It's what makes the human being stupid and at the same time a genius: Always trying to make something better (even if you know you can't). Otherwise we wouldn't have lower consumption cars, color TVs and so on, right?
Personally, I tend to think that an overly dogmatic commitment to backwards compatibility does more harm than the benefit produced by supporting a tiny minority of users with five year old hardware. Backward compatibility is the enemy of elegance. Just look at C++ or the x86 instruction set to see examples of that.
I do agree to some extent. On the other hand, I've been using Apple hardware off-and-on again since the MC68030; I already went through this with the 68k->PPC transition, then again with the introduction of the PPC750 series processors, then again with the PPC->Intel transition.
At this point, I fully expect that if I were to buy an Intel series Apple system in the next couple of years, shortly afterward Apple would switch everything over to their new A-series hardware.
I have certain investments in my current development system, too, like the early-model SSD that has made it possible for me to haul this thing around in the car to client appointments every day for the last couple of years.
I'm just sick of having perfectly good hardware that gets aged out of being able to run text editors. Yesterday, I discovered I can't run pianobar (easily) anymore because the Pandora protocol changed, MacPorts appears to be dead, and homebrew is Intel-only. (There is a PPC fork of the Intel version of homebrew, but the documentation for it is all pulled directly from the Intel fork, and I'm completely stumped at how to actually get it to work.)
On top of all that, I get to enjoy the economics of owning a device whose secondary market is falling off a cliff.
Anybody's welcome to point out all the benefits of this kind of situation -- the longevity of Apple hardware, the supposed lower TCO -- or the fact that I should be budgeting a certain amount every year towards new hardware anyway, but it's not likely to change the fact that I've been through this one too many times now and it's just not something that, to me, is worth continuing to hassle with.
I have a 2004 G5 with only one of the two processors working and I've had to replace my burned 512Mb ATI 9600 with the original 64 Mb GeForce FX 5200. I won't put this thing to the trash until its last breath.
On its left, there is a low end Dell PC running an up to date Ubuntu that cost me 350 € two years ago waiting for this day to come.
That said, MacPorts is still alive and kicking, the latest update was a few months ago.
Sweet! I'm completely unfamiliar with Ruby, which I think is half the problem (edit: and git/github, which is probably the other half). If there's a different file(s) to download for that fork, I can't find them -- everything in the github project seems to link back to https://gist.github.com/323731, which is the Intel build (edit: e.g., the Readme.md file). I tried replacing my copy of brew with https://github.com/sceaga/homebrew/blob/powerpc/bin/brew, but that complained that it can't find brew.h ("no such file to load -- brew.h" on line 77) ... at that point, I decided that I'd spent too much time trying to get pianobar upgraded and moved on to other things.
First, get the latest version of Xcode that's compatible with your OS. You can find older versions of Xcode by clicking on "Developer Tools" on the right side of this page: http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/w... (you may need a free Apple developer account).
sceaga has a branch for Tiger and another branch for PPC, I happened to be using Tiger on PPC, so I picked the Tiger branch. From https://github.com/sceaga/homebrew , you want to click "Switch Branches" on the left, choose your branch, then click "Download on the right. Or, just click one of these:
I opted to install into my home directory, rather than /usr/local, so to get it into place, all I had to do was extract the tarball, put the resulting directory where I wanted it (I called it "brew"), and then add $HOME/brew/bin and $HOME/brew/sbin to my $PATH.
You should now be able to type "brew" and see its usage message.
At this point, "brew install" worked for me, except that it wasn't chmodding binaries as executable. At the end of installations, it was giving a bunch of messages like "file: invalid option -- h". This appears to be because my 10.4 PPC version of "file" doesn't support "-h". To fix this, I installed the gnu version instead:
brew install libmagic
chmod +x ~/brew/Cellar/libmagic/5.04/bin/file
brew link libmagic #libmagic doesn't add gnu "file" to your PATH without this command, because it doesn't want to override the OS-provided "file"
After that, homebrew seems to work, with the following caveats:
1. "brew update" (which updates the package manager
itself) will try to update from the non-PPC, upstream
version of homebrew. I just don't use this command.
2. "brew doctor" complains that my gcc is too old
(because I can't use the latest Xcode) and can't
seem to detect that I have X11 installed, even
though I do.
I've also found the people in #machomebrew on irc.freenode.net to be a helpful bunch, although not many have experience with homebrew on PPC.
You were my favorite non-girlfriend-or-business-partner person today!
I had a busy day so I didn't get to try this out until just now. Somehow, despite staring at the github project page and clicking on everything that I thought was clickable and grinding my teeth in frustration, I never noticed the "Downloads" button. So now I feel like an idiot, but I'm an idiot with a working homebrew. Thank you. :-)
Whoops; for the record, "file" is not written by GNU. It was originally written by Ian Darwin and is currently maintained by Christos Zoulas, see http://www.darwinsys.com/file/
It's understandable that you wouldn't want to buy a new Mac just before they do a hardware refresh or something, but come on. At some point you need a new computer. Somehow I doubt that Apple is going to do some kind of crazy Intel -> Atom transition anytime soon, and even if they do they'll support Intel for at least a few years.
You sound like my friend who won't upgrade to an HDTV "because the price keeps dropping." :D
Like I said, it's not necessarily a rational decision, it's just that the pain of being invested into a platform only to have it become completely unsupported way before I'm ready to spend money on the Next! Great! New! Thing! has been burned into my brain. It's just not a hassle I need to deal with, not when I'm equally comfortable in Windows, Debian, or Mac.
It might be understandable if this was some kind of resource-hungry multimedia application, but a text editor? Like you say, "come on".
Also, Apple is notorious for wanting to own as much of their vertical as possible. They hate dealing with other companies for critical components, especially processors. They've become quite good at the processor transition at this point, and now that they own their own microprocessor and are using it in all of their mobile devices -- and touting the superior benefits of their processor every chance they get -- I'd be willing to make a pretty big bet that moving at least their entire laptop line over to the A series processors is already on their development roadmap.
I think the writing's on the proverbial wall and, like I said, I'm just tired of getting caught by it every time it happens.
But there is no notion of "Apple hardware" anymore. Apple has been using the "PC architecture" for quite a few years. You can run Mac OS on "PC" hardware just fine if you wish. Many people have done / are doing this; see www.hackint0sh.org for more information.
It's missing a few of the basic vim movement commands (which I have on a wallpaper I put together http://naleid.com/blog/2010/10/04/vim-movement-shortcuts-wal...), but has most of the big ones. The ones I use quite a bit that don't seem implemented are:
C-d - half page down
C-u - half page up
ge/gE - go to the end of the previous word (you do have e/E for next word)
( - previous sentence
) - next sentence