Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Neovim

github.com

Post reply on HN
Print view View original

41–50 of 372 posts

Re: Neovim

#41

Post by riffraff »

tinco wrote: post #35
fournm wrote: post #31

Earlier quoted context omitted.

I agree with almost everything--except for backwards compatibility when it comes to throwing stuff out. There is definite value in it, especially when we're talking about something as old and widely used as vim! The thing about compatibility is that it doesn't matter how great your new and shiny is if it can't talk to old things at all. Imagine the best new text editor in the world, but it's completely incompatible w…

I agree with almost everything--except for backwards compatibility when it comes to throwing stuff out. There is definite value in it, especially when we're talking about something as old and widely used as vim! This is the part where people are surprised, but I am an extremist. I definitely think backwards compatibility should be among the lowest priorities when making decisions on improving software, especially and…

The problem is you broke compatibility now. Will you do it again next year, and fix 100 plugins once more?

I am also not a big fun of extreme forms of compatibility, but plenty of projects try to break it only to have people which stick around with old versions for years.

Re: Neovim

#42

Post by euoia »

I think this is a great project. The author appears to be extremely competent. I pledged $20.

Re: Neovim

#43

Post by justinmk »

tinco wrote: post #29

Thanks for trying to do what many of us secretly wished we could do but can't because of time/skill constraints. I will definitely move to NeoVim the second it's packaged (is it yet?), regardless if you've changed anything yet. I hate the ideas many programmers have about backwards compatibility, that it's more important than development speed and modern concepts. There is nothing holy about Unix era software, chance…

This should not be the top comment, it is a rant that misses the point. Neovim maintains backward compatibility where it makes sense to do so. Neovim is NOT a rewrite, it is a thoughtful refactoring that aims to achieve one of Vim's _original_ goals: first class support for embedding. And better interoperability.

Re: Neovim

#44

Post by jamesgeck0 »

grannyg00se wrote: post #36
tinco wrote: post #29

Thanks for trying to do what many of us secretly wished we could do but can't because of time/skill constraints. I will definitely move to NeoVim the second it's packaged (is it yet?), regardless if you've changed anything yet. I hate the ideas many programmers have about backwards compatibility, that it's more important than development speed and modern concepts. There is nothing holy about Unix era software, chance…

So Sublime text provides a 99% feature loss but a great usability gain? Can you explain that a bit?

I don't think anyone would argue that Sublime Text has a much nicer GUI than anything Vim has. It's just lots of little things, like how scrolling is smooth and quick, not entire lines popping into/out of view. The zoomed out source map is also nice.

It's also ever so slightly snappier. Vim seems to be ever so slightly less responsive when I have several panes open.

Re: Neovim

#45

Post by riffraff »

swdunlop wrote: post #6
krick wrote: post #3

I'm not sure how I feel about this. On the one hand I've been thinking on it for quite a long time already, newer shinier Vim is something I secretly wish for. On the other hand I found it quite problematic. The main problem of Vim is Vimscript. So "newer shinier Vim" is Vim with real programming language instead of vimscript. But it's impossible to remove Vimscript: it won't be Vim anymore. It affects not only scrip…

"Hm, maybe better to write an open-source version of Sublime Text?" You mean, like Lime? https://github.com/limetext/lime

redcar has been around for a few years, with compatibility with textmate bundles

https://github.com/redcar/redcar

Re: Neovim

#46

Post by justinmk »

krick wrote: post #3

I'm not sure how I feel about this. On the one hand I've been thinking on it for quite a long time already, newer shinier Vim is something I secretly wish for. On the other hand I found it quite problematic. The main problem of Vim is Vimscript. So "newer shinier Vim" is Vim with real programming language instead of vimscript. But it's impossible to remove Vimscript: it won't be Vim anymore. It affects not only scrip…

Neovim fully supports vimscript and almost all existing vim plugins.

Re: Neovim

#47

Post by tinco »

glesica wrote: post #40
tinco wrote: post #29

Thanks for trying to do what many of us secretly wished we could do but can't because of time/skill constraints. I will definitely move to NeoVim the second it's packaged (is it yet?), regardless if you've changed anything yet. I hate the ideas many programmers have about backwards compatibility, that it's more important than development speed and modern concepts. There is nothing holy about Unix era software, chance…

> ...should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators. First, why? It works just fine. Second, is there anything better? I don't know of anything I would prefer to use. So until someone comes up with something, I'll stick to using Vim to write LaTeX in a Bash shell (might upgrade to zsh, we'll see).

No, it doesn't work fine. LateX is slow, inconsistent and needs to be ran multiple times to give a correct result, it has no API, is not extendable in a sane way, it's source code is so arcane there's books written about it, and if you've read the books the only thing you've learned is that trying to reimplement LateX is a fool's errand. And it's syntax is ugly.

Markdown is better. Microsoft Word is better. They just both lack certain things we need, and LaTeX has those things.

Could you not envision things could be better?

A LaTeX that parses to an in-memory tree so it could be transformed before compilation?

A shell that instead of working on character streams worked on structured and annotated data streams, so it could intelligently interpret what is going on?

An editor that does have at its core an expectation that its output is ASCII character commands controlling a 1970s terminal interface?

Of course you'll stick to using Vim to write LaTeX in a Bash shell, I do too. Doesn't mean I'm not mad about it..

Re: Neovim

#48

Post by tinco »

grannyg00se wrote: post #36
tinco wrote: post #29

Thanks for trying to do what many of us secretly wished we could do but can't because of time/skill constraints. I will definitely move to NeoVim the second it's packaged (is it yet?), regardless if you've changed anything yet. I hate the ideas many programmers have about backwards compatibility, that it's more important than development speed and modern concepts. There is nothing holy about Unix era software, chance…

So Sublime text provides a 99% feature loss but a great usability gain? Can you explain that a bit?

Well, I can explain how I use it. I have my Sublime in legacy mode, which enables some vim like controls. And I benefit from Sublimes super fast text rendering, it's nice fonts and colors, the way it integrates with my desktop environment, how fast it interacts with plugins that spawn popups and analyze my code.

And then every once in a while I need to do some cool text transformation, and it doesn't work, so I launch a terminal, edit the file in Vim and work my magic. Then I exit Vim and continue in Sublime. Ideal? No.. but it's the usability of Sublime with the features of Vim.. every once in a while..

Re: Neovim

#49

Post by Crito »

glesica wrote: post #40
tinco wrote: post #29

Thanks for trying to do what many of us secretly wished we could do but can't because of time/skill constraints. I will definitely move to NeoVim the second it's packaged (is it yet?), regardless if you've changed anything yet. I hate the ideas many programmers have about backwards compatibility, that it's more important than development speed and modern concepts. There is nothing holy about Unix era software, chance…

> ...should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators. First, why? It works just fine. Second, is there anything better? I don't know of anything I would prefer to use. So until someone comes up with something, I'll stick to using Vim to write LaTeX in a Bash shell (might upgrade to zsh, we'll see).

Yeah, I mean it's not like 'more modern' alternatives haven't been created... They just haven't caught on among this group of people because this group of people values functionality and does not give a damn how old something is.

People have made fancy new shells build around things other than bytes through pipes, people have created new replacements for terminal emulators, and people have created fancy GUI document creation systems with fancy instant visual feedback (a.k.a: word processors). Real shells, real terminal emulators, and LaTeX are all still used despite the creation of these meant-to-be replacements.

Re: Neovim

#50

Post by tinco »

justinmk wrote: post #43
tinco wrote: post #29

Thanks for trying to do what many of us secretly wished we could do but can't because of time/skill constraints. I will definitely move to NeoVim the second it's packaged (is it yet?), regardless if you've changed anything yet. I hate the ideas many programmers have about backwards compatibility, that it's more important than development speed and modern concepts. There is nothing holy about Unix era software, chance…

This should not be the top comment, it is a rant that misses the point. Neovim maintains backward compatibility where it makes sense to do so. Neovim is NOT a rewrite, it is a thoughtful refactoring that aims to achieve one of Vim's _original_ goals: first class support for embedding. And better interoperability.

I think you miss the point of my rant :P I'm not saying everything should be rewritten (though I do believe everything in C should be rewritten in C's successor which doesn't exist yet), but I'm saying Vim has gone too far in maintaining backwards compatibility, and if it would have improved interoperability, even at the expense of some backwards compatibility.
Post reply on HN