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

141–150 of 372 posts

Re: Neovim

#141

Post by bigtunacan »

rthomas6 wrote: post #92
bigtunacan wrote: post #25

I'm a hardcore Vim user and I just don't see the point of this. Not only that, but Vim is charity ware and requires the license to be included. The license is most notably absent from the Neovim fork. Wonder if that will be added any time soon...

So I read over the license and you're right, the license does need to be included. However I don't see anything wrong with the project as long as the license is included in its distribution. The license doesn't go against anything Neovim is doing, provided they include the license and provide the project source.

Therein lies the problem; the license is not being included. I find this a bit concerning since the default in forking a repo would have included it. So this gives off the impression then that the license was deliberately removed.

Just to make it clear (most people on Hackernews probably already know this, but for the sake of anyone that doesn’t), it would look like this.

hg clone https://vim.googlecode.com/hg/ neovim

cd ./neovim

git init && git add . && git commit -m “First commit”

git remote add origin https://github.com/neovim/neovim.git

git push -u origin master

There you have it; an exact fork from Mercurial push out to neovim on github, everything included. Getting those license files out of there took some manual steps somewhere in between lines 1 and 3.

Re: Neovim

#142

Post by badman_ting »

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?

"99% feature loss" sounds terrible but vim is actually way too featureful, in the sense that all that shit gets in the way of just using it as a text editor. The amount of silly pointless knowledge you need just to move around lines and save a file is a real burden.

Re: Neovim

#143

Post by ribs »

I'm not sure about libuv. Isn't that primarily for async I/O? This is a desktop application. Async I/O isn't going to significantly affect performance. And it doesn't make shit any simpler.

Re: Neovim

#144

Post by onli »

gradstudent wrote: post #136
phillmv wrote: post #113

Earlier quoted context omitted.

>You're confounding usability with "do not need a manual". They're not the same thing at all. Moreover, I reject entirely your assertion that vim is not usable. If by usable we mean "one can be productive in it" then yes that's correct, vim is immensely usable and I've been using it in that sense for six years. That however is a facile definition of what most people typically mean when we speak of 'usability'. A tool…

> If by usable we mean "one can be productive in it" then yes that's correct, vim is immensely usable and I've been using it in that sense for six years. Usable means an interface which is (i) consistent and (ii) well suited to the task at hand. It does not mean you should not require any training nor that you should be able to intuit the functionality without looking at the manual. vim is an example of software that…

> Usable means an interface which is (i) consistent and (ii) well suited to the task at hand.

No it doesn't. Usable as in Usability is defined in the ISO-norm 9241-110 by seven principles, a summary can be found here: http://www.userfocus.co.uk/resources/iso9241/part110.html

"suitability for the task (the dialogue should be suitable for the user’s task and skill level); self-descriptiveness (the dialogue should make it clear what the user should do next); controllability (the user should be able to control the pace and sequence of the interaction); conformity with user expectations (it should be consistent); error tolerance (the dialogue should be forgiving); suitability for individualisation (the dialogue should be able to be customised to suit the user); and suitability for learning (the dialogue should support learning)."

vim falls short in discoverabilty and, arguably, in user expectation, and suitability for learning.

Though I don't want to further spawn a vim-discussion. Just to show you that you don't seem to know the necessary vocabulary to tell you parent that he is wrong.

> You're doing it wrong. Read the bloody manual.

Yeah. Way to prove his point.

Re: Neovim

#145

Post by dllthomas »

PuercoPop wrote: post #127
dllthomas wrote: post #117

Earlier quoted context omitted.

"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?" I'm not convinced that's worse, but I'm not convinced it's better for the task of being a shell . It's totally, unequivocally, way the hell better when you're trying to build anything large out of it, but taking everything back to byte streams at the interfaces…

Have you seen http://xiki.org ? It seems a good idea for the she'll to know what a directory is for example.

I had not; I'll look at it at some point here.

What do you mean by "know what a directory is"?

Re: Neovim

#146

Post by ticviking »

jamesgeck0 wrote: post #103
bayesianhorse wrote: post #80

Earlier quoted context omitted.

Even if it sounds like sacrilege to some, I am putting it out there for comment. Both ideas arose from the dissatisfaction with text editing, one in the browser, and the other in the mobile space where currently almost nobody uses a text editor. Especially the "modal html5 editor" would be useful across a variety of websites, either built into the site or the browser itself. For example it would be nice to have plugi…

Path 2 is actually something you could do with neovim. The editor's core and it's UI would be decoupled, so you could put whatever UI you wanted to build on top of it relatively easily.

Ohh a modal vim with like wheel typing for taking notes on my iPad in meetings would be smexy

Re: Neovim

#147

Post by [deleted] »

SmileyKeith wrote: post #140

I think one of the most important things about this is the last bullet point. "Development on Github." I occasionally look at the vim-dev mailing list and I see people attaching patch files to conversations. I think Github's collaborative development workflow could help the barrier of entry to updates a lot.

[deleted]

Re: Neovim

#148

Post by dovel »

terminus wrote: post #119
tinco wrote: post #59

Earlier quoted context omitted.

I do what I want. Also, LaTeX is a system for creating documents, and Word is a system for creating documents. There's only four important differences: Word has a more modern architecture, Words compiler is integrated into its GUI, Word is closed source, Words source format is not human readable. Apples to Oranges? I can compare these Braeburns to those Fujis just fine thank you.

Those are just the surface differences. The modes in which you use all of these are very different. Word: explicit WYSIWYG control over typesetting. LaTeX: semantic level control over typesetting. Additionally provides explicit low level typesetting commands. Markdown: given how basic (trivial even) Markdown is ( http://daringfireball.net/projects/markdown/syntax ) I'm not sure why it's even in this list.

I do not use any of the mathematical elements of LaTeX and the work I do render using it is exclusively words. Just words. So really LaTeX isn't necessary for what I do. But, I write using MultiMarkdown in Scrivener, using Bibtex citekeys for referencing then export the document as LaTeX from scrivener and then compile using Texshop.

I guess I don't really have a point. Just that if you are writing essays in the humanities or sociology then markdown can have a place in your workflow

Re: Neovim

#149

Post by nousernamesleft »

jnbiche wrote: post #91
tinco wrote: post #50

Earlier quoted context omitted.

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.

>I do believe everything in C should be rewritten in C's successor which doesn't exist yet Both golang and D have a reasonable claim to being C's successor. People often think of D being a nextgen C++, but to me it has much more the feel of a C with garbage collection and batteries included. And golang definitely feels like a modern C, at least to me. And that's what Rob Pike had in mind, as well. PS: Had to use Word…

Go has absolutely no claim to being C's successor. It is useless for all the things it makes sense to use C for. That's why it has attracted virtually no C programmers. Go is python's successor if user influx is anything to judge by.

Re: Neovim

#150

Post by gradstudent »

onli wrote: post #144
gradstudent wrote: post #136

Earlier quoted context omitted.

> If by usable we mean "one can be productive in it" then yes that's correct, vim is immensely usable and I've been using it in that sense for six years. Usable means an interface which is (i) consistent and (ii) well suited to the task at hand. It does not mean you should not require any training nor that you should be able to intuit the functionality without looking at the manual. vim is an example of software that…

> Usable means an interface which is (i) consistent and (ii) well suited to the task at hand. No it doesn't. Usable as in Usability is defined in the ISO-norm 9241-110 by seven principles, a summary can be found here: http://www.userfocus.co.uk/resources/iso9241/part110.html "suitability for the task (the dialogue should be suitable for the user’s task and skill level); self-descriptiveness (the dialogue should make…

> vim falls short in discoverabilty and, arguably, in user expectation, and suitability for learning.

vim fits very well all the criteria you just cited. Moreover, "discoverability", "user expectation" and "suitability for learning" appear to be buzzwords that you just threw in on your own at the end.

Post reply on HN