News for hackers. Stuff that matters.
Re:GitHub's new text editor leaked on Twitter by jordwalke on Wednesday February 26, 2014 @12:21AM (#7303073)
I really can't wait for this to be released. I am a little pessimistic about the Vim mode. There are countless 80 or 90% complete Vim modes in various modern editors. But the absence of a truly native feeling Vim (that last 10%) is a deal breaker for many. I'd rather see more editor developers spend time finding a solution that provides a truly authentic Vim mode instead of spending countless hours merely approaching 90% compatibility. For the people who you're selling on that Vim mode (the people who would care that your editor provides it) 90% isn't good enough. There are other ways to integrate Vim modes in your editor such as using the (inappropriately named) "Netbeans interface" which actually allows Vim to run in the background while you integrate your UI on top of it across a serializable bridge. This allows a perfect recreation of Vim while letting you customize the application experience on top of it.

Aside from that approach, there are a few faithful Vim recreations that I've discovered out of the dozens that I've tried.

https://github.com/vicoapp/vico (Excellent project) http://www.viemu.com/ (Solid experience in Visual Studio) https://github.com/guillermooo/Vintageous (fairly close and getting better every day)

But I don't mean to sound like such a pessimist. The progress so far looks excellent and I can't wait to try it out. Keep it up!

Edit: I also notice that the logo looks like an iOS7 version of React's logo: http://facebook.github.io/react/

Re:GitHub's new text editor leaked on Twitter by msutherl on Wednesday February 26, 2014 @01:14AM (#7303266)
What really bugs me are Vim modes that don't allow you to easily add new keybindings that abstract combinations of keystrokes, i.e. map <key> <keys>. For instance, I love to bind "s" to "go into insert mode, insert one character, exit insert mode". I feel crippled without this binding, but making it happen in Sublime 3 with Vintageous is daunting. It involves understanding the Sublime API and constructing some complex block of configuration code with way too many commas and brackets (JSON sucks). In Vim, configuration is a bunch of one-liners and I love that.
Re:GitHub's new text editor leaked on Twitter by JoshTriplett on Wednesday February 26, 2014 @05:05AM (#7303975)
> For instance, I love to bind "s" to "go into insert mode, insert one character, exit insert mode".

Doesn't that already exist, by hitting 'r'?

Re:GitHub's new text editor leaked on Twitter by lucian1900 on Wednesday February 26, 2014 @05:41AM (#7304078)
That replaces the character under the cursor, it doesn't insert a new one.
Re:GitHub's new text editor leaked on Twitter by JoshTriplett on Wednesday February 26, 2014 @09:55AM (#7305236)
Ah, thanks for the clarification.
Re:GitHub's new text editor leaked on Twitter by benaiah on Wednesday February 26, 2014 @12:48AM (#7303173)
Curious as to your opinion on Evil from Emacs - I've been learning Evil without knowing Vim first, so I don't know what I might be missing.
Re:GitHub's new text editor leaked on Twitter by roryokane on Wednesday February 26, 2014 @01:18AM (#7303280)
I’ve used Evil in Emacs with http://orgmode.org/, after having learned Vim. I’d say Evil is another great, thorough emulation of Vim. It includes even relatively-obscure features like visual block mode, R, K, v_o, :%!sort, ^W window split/switch/close commands, and Vim’s tree undo model.

My only problems with Evil are where Emacs or Emacs plugins’ bindings conflict with Vim bindings, such as v_^G (that is, Ctrl-G in Visual mode) meaning “Quit” instead of “Switch to Select Mode”. Those conflicts aren’t really Evil’s fault – they’re inevitable when combining third-party plugins that don’t explicitly support Evil – but they can be annoying.

I’d say you’re not missing much with Evil that would be in Vim. I suppose you’re mainly missing Vim’s large ecosystem of plugins that are made to work with Vim keybindings and Vim’s editing model – though I see that surround.vim has been ported (https://github.com/timcharper/evil-surround). Plus Vim wouldn’t have Evil’s and Emacs’ keyboard conflicts, of course.

Re:GitHub's new text editor leaked on Twitter by jordwalke on Wednesday February 26, 2014 @02:02AM (#7303442)
I recall this most recent emacs effort the best of all the previous attempts (Viper etc). I believe there was one thing I couldn't fix:

When in command mode (such as when you type :e etc), hitting back space stops at the last deletion. In Vim, if you continue pressing backspace, the editor cursor starts moving back (as if you're pressing `h` in normal mode). (Did you figure out how to fix this?)

It's the little things like this that have become ingrained in our muscle memory over the course of more than a decade.

I do agree that emacs' scripting environment is better than Vim Script.

Re:GitHub's new text editor leaked on Twitter by roryokane on Wednesday February 26, 2014 @02:09PM (#7306877)
I don’t understand your backspace problem. In all of the following cases, Vim 7.3 and Emacs 24 with Evil act the same:

In Command-line mode (by typing `:`), when there is text after ‘:’ and before the cursor, typing Backspace deletes one character behind the cursor. In Command-line mode, if there is no text left but ‘:’, it exits Command-line mode, changing to Normal mode. Emacs displays Quit in this case, while Vim just exits silently. If I press Backspace in Normal mode while the cursor in the middle of a line, the cursor moves back one character as if you pressed `h`.

My full Evil config is here: https://github.com/roryokane/emacs.d/blob/master/init.el#L12.... But I don’t see anything in it that would change the behavior of Backspace.

I did just notice an inconsistency with Backspace, but it doesn’t sound like what you’re talking about: if you press Backspace in Normal mode while the cursor is at the leftmost column, the cursor wraps to the previous line in Vim, but stays in the same place in Emacs. The cause of that behavior in Vim is the 'whichwrap' option’s value containing “b”. Evil has a rough equivalent to that option in evil-cross-lines (a boolean), but I don’t know if it has an equivalent that lets you selectively enable wrapping only for Backspace and Space. https://bitbucket.org/lyro/evil/issue/247/evil-invert-char-s... implies that there was no exact equivalent as of Febraury 2013.

Re:GitHub's new text editor leaked on Twitter by platz on Wednesday February 26, 2014 @12:57AM (#7303205)
I'm not an Evil expert, but my experience were that the conflicts with existing Emacs keybindings made things more frustrating. As a vim user interested in Emacs I'm trying to avoid Evil and other "90%" vim emulations from now on as well.
Re:GitHub's new text editor leaked on Twitter by ChickeNES on Wednesday February 26, 2014 @12:32AM (#7303121)
Why not just use Vim?
Re:GitHub's new text editor leaked on Twitter by roryokane on Wednesday February 26, 2014 @01:34AM (#7303345)
Vim does not support graphical user elements, and is built around the unfamiliar language Vimscript. Those drawbacks are pretty baked into Vim and would be hard to change (though someone is trying to: https://www.bountysource.com/fundraisers/539-neovim-first-it...). Many other editors don’t have these drawbacks, allowing them to support features such as these:

• a graphical file tree browser (with icons, not restricted to ASCII art like NERDTree)

• proportional-width fonts

• a zoomed-out-code mini-map scroll bar

• Plugins written in more mainstream, cleaner languages than Vimscript. Vim does have a plugin interface for some other languages such as Python, but some OSs’ provided Vim installations don’t support those languages, and it’s hard to get a version of Vim with support.

Re:GitHub's new text editor leaked on Twitter by comex on Wednesday February 26, 2014 @01:56AM (#7303417)
It's also apparently a pain to integrate into anything else...

http://www.freehackers.org/VimIntegration

...and plugins can't update things in the background...

https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%...

etc. I haven't looked at the code myself, but it sounds like a rewrite or major refactor would be very useful.

Re:GitHub's new text editor leaked on Twitter by aktau on Wednesday February 26, 2014 @06:35AM (#7304239)
It's happening as we speak (since a few days, based on the crowdfunding campaign). It seems like there's quite a bit of people (volunteers and would-be volunteers) participating already. Voting about the preferred voting style is about to end:

https://github.com/neovim/neovim

Re:GitHub's new text editor leaked on Twitter by folago on Wednesday February 26, 2014 @08:14AM (#7304671)
Yeah but this is happening https://github.com/neovim/neovim. And the potential for all you asked for is there, see the long term plan https://www.bountysource.com/fundraisers/539-neovim-first-it....
Re:GitHub's new text editor leaked on Twitter by alxndr on Wednesday February 26, 2014 @01:13AM (#7303263)
If it's not vimmy enough, I bet people will.
Re:GitHub's new text editor leaked on Twitter by lucian1900 on Wednesday February 26, 2014 @05:40AM (#7304076)
I may be an outlier, but I'm perfectly fine with 90%.
Re:GitHub's new text editor leaked on Twitter by namuol on Wednesday February 26, 2014 @04:29PM (#7308006)
Maybe just use vim?