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

Bram Moolenaar responds to Neovim

groups.google.com

Post reply on HN
Print view View original

41–50 of 151 posts

Re: Bram Moolenaar responds to Neovim

#41

Post by mst »

perlgeek wrote: post #5
bachback wrote: post #3

well of course. Vi was specifically written by Bill Joy to optimize for every character, see http://www.theregister.co.uk/2003/09/11/bill_joys_greatest_g... And there is no reason we could ever improve on that 35 years later. we need those optimizations... "It took a long time. It was really hard to do because you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you…

Whenever I use vim through a lagging SSH connection, I'm very happy that it's still usable (at least more so than other editors).

If you can stand the fact that it's only got the original feature set, ex-vi.sf.net provides a version of the original vi that runs on modern unices.

I use it on a daily basis and have found that it copes with conference wireless far better than vim does.

Re: Bram Moolenaar responds to Neovim

#42

Post by haberman »

raverbashing wrote: post #36
haberman wrote: post #32

Earlier quoted context omitted.

With that thinking we never get Linux (NeoMinix), tmux (NeoScreen), Clang (NeoGCC), WebKit (NeoGecko), Subversion (NeoCVS), or Vim itself (NeoVi/Elvis/Stevie/etc).

Huummmmm no Neovim is being sold as a VIM refactor, but apparently with no new functionality Very different from Linux (had an aim of being a playground for new features), tmux is different from screen as Clang is different from GCC, Subversion is a totally different beast from CVS

> Neovim is being sold as a VIM refactor, but apparently with no new functionality

Where did you get that idea? When I read the project page (https://github.com/neovim/neovim), two of the explicit goals are:

"Enable the implementation of new/modern user interfaces without any modifications to the core source.

"Improve the extensibility power with a new plugin architecture based on coprocesses. Plugins will be written in any programming language without any explicit support from the editor. "

It is exactly designed to be a playground for new features, but with the goal of them not having to be in the core.

Re: Bram Moolenaar responds to Neovim

#43

Post by TazeTSchnitzel »

mjn wrote: post #37
sramsay wrote: post #2

Perhaps this was mentioned the other day, but Neovim did make me think of this old chestnut from Joel Spolsky: http://www.joelonsoftware.com/articles/fog0000000069.html I realize Neovim is being characterized as an "aggressive refactor," but I'm sure that's the way Netscape thought of it as well. tl;dr Things you should never do: rewrite the code from scratch.

> tl;dr Things you should never do: rewrite the code from scratch. Considering vim itself is a from-scratch 'vi' clone, that's interesting advice. :) But in any case, I see this as more of a fork than a rewrite. It's more akin to the XEmacs/GNU Emacs situation, where someone submits significant patches upstream which aren't accepted, and then forks their own version to continue that line of development.

Clones and rewrites aren't really comparable, though.

Re: Bram Moolenaar responds to Neovim

#44

Post by Jare »

middleclick wrote: post #38
Jare wrote: post #28

Earlier quoted context omitted.

When we started work on Commandos 2, we threw away everything from Commandos 1, and started from scratch. 15 years down the road, all the coders still agree that was the best decision ever.

Were you on the Commandos team? Mad respect to you. Probably my most favourite game of all times. Thanks for working on it.

Thanks! I was technology/tools lead on 2, and while my role in 1 was... hard to explain, yeah my contribution was important. :)

Re: Bram Moolenaar responds to Neovim

#45

Post by aeonsky »

tinco wrote: post #9

Well that does it I'd say. With such a negative attitude, who wants him on the team anyway? What the advantages are? They're clearly laid out in the project. Seriously, screw that guy. edit: Yes I know who 'that guy' is and it's great he's been working on Vim for all these years, but he certainly has his head up his ass if he thinks Vim users would not benefit from some big refactorings, a more accessible code base a…

I still have yet to see these concrete user benefits.

Re: Bram Moolenaar responds to Neovim

#46

Post by mden »

raverbashing wrote: post #36
haberman wrote: post #32

Earlier quoted context omitted.

With that thinking we never get Linux (NeoMinix), tmux (NeoScreen), Clang (NeoGCC), WebKit (NeoGecko), Subversion (NeoCVS), or Vim itself (NeoVi/Elvis/Stevie/etc).

Huummmmm no Neovim is being sold as a VIM refactor, but apparently with no new functionality Very different from Linux (had an aim of being a playground for new features), tmux is different from screen as Clang is different from GCC, Subversion is a totally different beast from CVS

Neovim isn't a simple refactor though. It adds the ability to do many things which aren't currently possible or are extremely difficult to do with the current vim. Sometimes there is no easy way out and you have to put in the work to fix previous limitations.

Re: Bram Moolenaar responds to Neovim

#47

Post by darklajid »

Jare wrote: post #44
middleclick wrote: post #38

Earlier quoted context omitted.

Were you on the Commandos team? Mad respect to you. Probably my most favourite game of all times. Thanks for working on it.

Thanks! I was technology/tools lead on 2, and while my role in 1 was... hard to explain, yeah my contribution was important. :)

Did you write about that somewhere? Could you, even? Pretty please?

Re: Bram Moolenaar responds to Neovim

#48

Post by tambourine_man »

The project has already surpassed its requested value in the first 48hs. The enthusiasm reminds me of git-annex.

I really love this business model, the developer works on something he is passionate about, we can support the project and influence its future, all while strengthening the community around it.

Re: Bram Moolenaar responds to Neovim

#49

Post by sramsay »

mjn wrote: post #37
sramsay wrote: post #2

Perhaps this was mentioned the other day, but Neovim did make me think of this old chestnut from Joel Spolsky: http://www.joelonsoftware.com/articles/fog0000000069.html I realize Neovim is being characterized as an "aggressive refactor," but I'm sure that's the way Netscape thought of it as well. tl;dr Things you should never do: rewrite the code from scratch.

> tl;dr Things you should never do: rewrite the code from scratch. Considering vim itself is a from-scratch 'vi' clone, that's interesting advice. :) But in any case, I see this as more of a fork than a rewrite. It's more akin to the XEmacs/GNU Emacs situation, where someone submits significant patches upstream which aren't accepted, and then forks their own version to continue that line of development.

I think that's an excellent point. Vim is, after all, "Vi iMproved." nvi is a clone.

Re: Bram Moolenaar responds to Neovim

#50

Post by ggreer »

nhaehnle wrote: post #39
CJefferson wrote: post #10

Earlier quoted context omitted.

That is an overly simplistic viewpoint. Vim is written in an inedibly old style of C which is not taught anymore, or used by most people. The code if fill of typedefs for AMIGA and OS/2. Useful to a small number of people certainly, but making progression harder too. This is not a total rewrite, it is a massive overdue refactoring.

The code if fill of typedefs for AMIGA and OS/2. There's nothing wrong with that as long as those typedefs are properly isolated in some platform-specific header files. It's natural to have an initial feeling of being overwhelmed by that kind of stuff. However, it often turns out that there's nothing to gain from removing that stuff. The only real cost is when people expect a platform to work, but nobody from that pl…

Have you looked at the Vim source? There are a few things in platform-specific headers, but most ifdefs are scattered in actual code. There are even ifdefs in the middle of control flow statements. For example, in RealWaitForChar(): https://github.com/b4winckler/macvim/blob/master/src/os_unix...

That function is over 400 lines and has over 50 ifdefs. What does it do? It waits for any key to be pressed. Unfortunately, Vim is single-threaded and synchronously character-driven, so it has to try and process some autocmds and other events in the same loop.

Oh and the wait loop uses gettimeofday(), which is not monotonic.

To get another taste of Vim's source, take a look at https://github.com/b4winckler/macvim/blob/master/src/eval.c (Warning, may crash your browser.) That file is 25,000 lines and checks hundreds of different ifdefs.

Post reply on HN