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

81–90 of 372 posts

Re: Neovim

#81

Post by paddyoloughlin »

xutopia wrote: post #51
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…

I think a modular base would mean that VimScript could be entirely replaced with a different kind of scripting language. I for one would love to see Ruby or Python take that spot!

You can already script Vim with those languages.

Vim needs to be built with the support enabled, though.

Python: [1] (more info [2])

Ruby: [3]

[1] http://vimdoc.sourceforge.net/htmldoc/if_pyth.html

[2] http://stackoverflow.com/questions/905020/resources-concerni...

[3] http://vimdoc.sourceforge.net/htmldoc/if_ruby.html

Re: Neovim

#82

Post by dbbolton »

As far as I'm concerned, just moving a vim clone to git is a huge improvement.

Ever tried building vim from the ports tree on a <1GHz machine? Painful.

Re: Neovim

#83

Post by iso8859-1 »

kansface wrote: post #65
bronson wrote: post #4

It sounds like they have no interest in getting this stuff pushed back upstream? There's no mention of it on the home page. At this point it smells kind of Emacs/XEmacsish. Hope they can rally immense development effort.

Bram shows no interest in these sorts of things. Frequently, devs post to the vim mailing with a month or two of work on some new feature with no comment from the BDFL.

So why don't all these people get together and fork?

Re: Neovim

#84

Post by tinco »

stusmall wrote: post #78
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.

I don't mean to be a jerk, but how much do you actually use/have used LaTex? They aren't even similar. They have very few similar use cases. One is a typesetting system the other is a word processor. Sure, documents come out the other end with both but the process and targets are very different. One allows you to quickly and easily make a quality document. One allows you to make the document to look exactly how you w…

I'm by no means a LaTex expert. I've written a few papers and a bunch of reports, nothing published, just undergraduate stuff. I dropped out halfway through my graduate degree, so I'm not what you'd call an academic. But I've seen and read enough to know that you can do impressive things with LaTex.

I have another question though, how much have you used Word? I have used it only a couple of times since highschool, but it's gotten pretty impressive. I bet that if you really dive into it you could get very close to the power of latex. At least, with regards to the typesetting. The drawing images/formulas/schemas thing is a whole different ballgame I'd agree.

Anyway, my point was not that Microsoft Word in any way is a good replacement for LaTex, I'm just saying that if LaTex could be as well written as Word is, it could have these fancy GUI and fast rendering features too.

There's people out there that think that the power in typesetting that LaTex has is mutual exclusive with the speed and usability that Word has. That just isn't so.

The only reason LaTex isn't fast and more easily extensible is that it was written for the machines of 40 years ago, that didn't have enough RAM to hold the parsed tree of a document.

LaTex could be ten times as fast, were it written in Ruby, the slowest language out there. Just because a modern programmer would make use of the modern hardware and modern design concepts, and just make it responsive. A GUI could be as simple external process that accessed a message passing API, rendering it to HTML and run it through Webkitview.

Overhead everywhere, still ten times faster than LaTex...

(edit: definitely worth a downvote, this comment :P)

Re: Neovim

#85

Post by goldfeld »

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…

I think you miss a major thing here: if you put vim with just it's top 100 plugins up against Sublime Text, I think it will easily lose. Why would I even use that? It's because of the long tail of thousands of plugins (your 1% usage) that I choose vim/emacs (more specifically, each power user chooses it because of the set of many of those top 100 hundred plugins + a handful of weird, obscure plugins that fit their needs perfectly.)

Re: Neovim

#86

Post by keithpeter »

segphault wrote: post #16

As someone who uses Vim to write articles and documentation in addition to code, I'd really love to see a richer UI with proper support for features like variable-width fonts. It looks like the developer behind this refactoring effort has some really good ideas for decoupling the Vim engine from the user interface layer. It'd be great if somebody could build a really good cross-platform Qt-based UI on top.

"I'd really love to see a richer UI with proper support for features like variable-width fonts."

Would the variable-width fonts be simply for display with plain text being edited and buffered, or do you wish to be able to have rich text formatting within the editor (e.g. italic, bold, smart quote marks &c)?

Just interested: rich text formatting has been suggested for emacs I recollect.

Re: Neovim

#88

Post by NAFV_P »

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…

> Look at SublimeText, it's got 1% of the features of Vim, yet it's converting Vim users left and right, by its sheer usability.

I just looked it up, $70 is way out of my pay range. I'll convert when I have a full-time job.

> We as developers in the Open Source community should be ashamed people are still using Vim to write LaTeX in Bash running on terminal emulators.

Yes, you should be ashamed.

Re: Neovim

#90

Post by davidgerard »

tinco wrote: post #71
Crito wrote: post #66

Earlier quoted context omitted.

If that is all you need and expect from a replacement for LaTeX, why aren't you just using LibreOffice?

It's not, I need the human readable source part, so I can track my work and cooperate in git :) I use LibreOffice for some stuff though.

Versioning of OpenOffice/LibreOffice documents using git: http://blog.riemann.cc/2013/04/23/versioning-of-openoffice-l...
Post reply on HN