Live data from Hacker News

Plans for Vim 7.4

groups.google.com

11–20 of 86 posts

Re: Plans for Vim 7.4

#11
post #4

I am curious what "add IDE features" means. It seems like a wide-open feature request. A few things I can think of: * Better support for background tasks .. :mak, :grep, system(), :! without interrupting editing. * Fancier errorlist and locationlists. cexpr()/lexpr() really make you fit round pegs into square holes. * Better omni-completion performance (any completion dialogs other than , buffer keyword completion, a…

A vimL API for parsing code, with AST, code transformations, and un-parsing would be a huge step in that direction.

This would allow plugins to all sorts of crazy stuff, with less magic, less regex, and more robustness.

This would make code completion better, too.

Re: Plans for Vim 7.4

#12
post #4

I am curious what "add IDE features" means. It seems like a wide-open feature request. A few things I can think of: * Better support for background tasks .. :mak, :grep, system(), :! without interrupting editing. * Fancier errorlist and locationlists. cexpr()/lexpr() really make you fit round pegs into square holes. * Better omni-completion performance (any completion dialogs other than , buffer keyword completion, a…

>> I'm sad to see VimScript de-emphasized, having invested a good bit of time in getting good with it, but VimScript is pretty slow, so this is good news.

I'm a Vim enthusiast who hasn't tried Emacs, but one thing I've heard that makes me jealous is that they can script their editor using a flavor of Lisp. This is extra awesome for devs whose primary language is already Lisp.

Sometimes I wish for a Vim-like editor with a nicer scripting language, but "Vim-like" is such a huge target at this point that any effort is bound to displease most users by omitting the one tiny feature they personally love.

If Python becomes useful for scripting Vim, that would be awesome in my book.

Re: Plans for Vim 7.4

#13
post #9

I'm not sure about IDE features. The whole reason I use vim in the first place is precisely because it's not an IDE. I don't want integration, I want unix instead. It's the same reason I use dwm for my desktop setup and configure everything by hand as opposed to using a desktop environment. I want technically simple software. Right now I could already easily configure/integrate vim to use gdb, gcc, git, jshint, etc.…

Well, either way the "Better IDE Features" won't be making it into Vim 7.4 (as Bram hinted at), so you don't have to worry just yet. As for the specifics of the IDE features, they've been summarized here: https://news.ycombinator.com/item?id=5680216

Re: Plans for Vim 7.4

#14
Just because people who follow the vim google group want more ide features and python integration doesn't mean thats what most vim users want. Why don't they fix the obvious flaw, mouse integration? (I know, because it would be hard)

Re: Plans for Vim 7.4

#16
Things that I really appreciate in the list:

* add IDE features (debugger integration, shell window)

* add integration with Python instead of inventing more Vim script

* add encryption for the swapfile

And something that could be included in that list:

* Built-in support for multiple cursors

Re: Plans for Vim 7.4

#17

Just because people who follow the vim google group want more ide features and python integration doesn't mean thats what most vim users want. Why don't they fix the obvious flaw, mouse integration? (I know, because it would be hard)

Mouse integration into a console vim window? It may be obvious to you but it's literally never affected me, I haven't even run GPM in like 10 years.

Re: Plans for Vim 7.4

#18
With the development beeing rather slow as it is, wouldn't Vim benefit more from improving the whole community aspect as well as connectivity?

I still use Vim, but it is a bit annoying to see well done solutions I've been using for years fall behind new projects (Hello Firebug) that accomplish more in a year than others in 20 years.

If Sublime Text was Open Source and the vi mode better I'd switch in an instant. And probably a lot of people too.

I don't want to sound snobbish and arguing without helping isn't the way to go in the open source community, but man, all that stuff that has been in development for so long, thought of in dusty university rooms, presented in worn 70's summer dresses...

It reminds me of the old tailor couple around the corner. They wont go away and probably have a lot of years to life left. A handful of people still value their skill and love to pay more. But it's an old house that hasn't been painted for a long time. You will only find it in the yellow pages and even then you're having trouble to actually find the shop because it's tiny and the house looks like it's soon to be demolished. The machines they use are old and they are the only ones who actually know how to fix them. If they die the shop is gone for good.

The same goes trough my head when I look at Vim's homepage, or Molenaars. They look like someone died or moved on to a life without the internet.

They don't make the impression that anything of value can be found. But in some places there is, scrambled across different pages by different people of different generations. Modern technology hammered into old shells. A reminder here that scripts can also be found on git. A wiki hosted on wikia there. GUI builds for Mac here, Windows there, none using any new features of the OS. It still runs, but there isn't really any love put into it.

If people talk about Vim plugins I only hear how bad VimScript is. If I install one I get it on github, not the script repository because that's where the skeletons lie. The installer I use (and the only one up-to-date) is made by the cream developers. No clue what I'd even do if they stopped producing them.

Vim became the double-edge razor a long time ago. It's cheap, it just works and I can pass it down to my kids. All it needs is some learning. But it's only noteworthy because every other kind of razor produced today sucks in one way or another.

Re: Plans for Vim 7.4

#19
post #4

I am curious what "add IDE features" means. It seems like a wide-open feature request. A few things I can think of: * Better support for background tasks .. :mak, :grep, system(), :! without interrupting editing. * Fancier errorlist and locationlists. cexpr()/lexpr() really make you fit round pegs into square holes. * Better omni-completion performance (any completion dialogs other than , buffer keyword completion, a…

>> I'm sad to see VimScript de-emphasized, having invested a good bit of time in getting good with it, but VimScript is pretty slow, so this is good news. I'm a Vim enthusiast who hasn't tried Emacs, but one thing I've heard that makes me jealous is that they can script their editor using a flavor of Lisp. This is extra awesome for devs whose primary language is already Lisp. Sometimes I wish for a Vim-like editor wi…

Ive always thought Lua would be a good vim scripting language.

* It's designed to be embedded

* It's easy to expose functionality and API's

* It's fast

* IME if other languages are also embedded, and a thoughtful API/plugin arch is created, functionality from other language plugins can be easily accessed in lua. (I know, bunch of caveats there, but if I'm dreaming...)

Re: Plans for Vim 7.4

#20
post #4

I am curious what "add IDE features" means. It seems like a wide-open feature request. A few things I can think of: * Better support for background tasks .. :mak, :grep, system(), :! without interrupting editing. * Fancier errorlist and locationlists. cexpr()/lexpr() really make you fit round pegs into square holes. * Better omni-completion performance (any completion dialogs other than , buffer keyword completion, a…

Background tasks, check out dispatch.vim[1]

https://github.com/tpope/dispatch-vim

Post reply on HN