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

Plans for Vim 7.4

groups.google.com

Post reply on HN
Print view View original

41–50 of 86 posts

Re: Plans for Vim 7.4

#41

Post by samstokes »

richo wrote: post #20
oinksoft wrote: 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

Thanks for pointing this out! But I think you meant https://github.com/tpope/vim-dispatch.

Re: Plans for Vim 7.4

#42

Post by keypusher »

coldpie wrote: post #5

Version numbers are infuriating. Dates don't overflow, people! If you're doing incremental development that doesn't have a concept of a "stable release", just use dates. This applies to projects like Firefox and the Linux kernel. I was pretty annoyed when Linus went with 3.x. Eventually, it's going to run into the same problem 2.6.x did. Date-based versioning would have lasted forever!

You are assuming a monotonically increasing version number. What happens when you need to go back to the old "version" and push out an update? For instance, you shipped 3.0 a few months back but most of your users are still on 2.7. Uh, there's a bug on 2.7, you need to push out a fix. If you are doing versions by date, then there is no easy way to distinguish parallel development.

Re: Plans for Vim 7.4

#43

Post by keypusher »

mrgoldenbrown wrote: post #40
robotjosh wrote: post #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)

Wait, what? Since when does being in the google group let you vote? I thought you had to be a paying customer/sponsor to vote.

A paying vim customer?

Re: Plans for Vim 7.4

#44

Post by keypusher »

robotjosh wrote: post #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)

Because many, many vim users (majority even?) are running vim on a headless *nix server with no display or display software, let alone a mouse. Anyway, there is already "set mouse=a", or use something like MacVim or another port of vim to graphical UI.

Re: Plans for Vim 7.4

#45

Post by lacksconfidence »

keypusher wrote: post #43
mrgoldenbrown wrote: post #40

Earlier quoted context omitted.

Wait, what? Since when does being in the google group let you vote? I thought you had to be a paying customer/sponsor to vote.

A paying vim customer?

yes you need to donate 10 euro to the ugandan charity Bram chose to support.

http://www.vim.org/sponsor/

Re: Plans for Vim 7.4

#46

Post by sophacles »

hsitz wrote: post #30
sophacles wrote: post #19

Earlier quoted context omitted.

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...)

Vim supports scripting with Lua similar to the support it already has for Python, Perl, Ruby, Racket. Your instance of Vim just has to be compiled with that option. See ':h lua'. One major problem with its support for scripting languages has been that you can't count on other users having a Vim compiled with proper support. This includes Python, although more recently some distributions (e.g., I think, Ubuntu) have h…

Oh yeah, the Lua support is there, I was meaning a concentrated effort to have Lua replace VimScript completely.

Re: Plans for Vim 7.4

#47

Post by tvon »

keypusher wrote: post #42
coldpie wrote: post #5

Version numbers are infuriating. Dates don't overflow, people! If you're doing incremental development that doesn't have a concept of a "stable release", just use dates. This applies to projects like Firefox and the Linux kernel. I was pretty annoyed when Linus went with 3.x. Eventually, it's going to run into the same problem 2.6.x did. Date-based versioning would have lasted forever!

You are assuming a monotonically increasing version number. What happens when you need to go back to the old "version" and push out an update? For instance, you shipped 3.0 a few months back but most of your users are still on 2.7. Uh, there's a bug on 2.7, you need to push out a fix. If you are doing versions by date, then there is no easy way to distinguish parallel development.

Just to play devils advocate, you could use both versioning schemes. For example, 13.01.24 could indicate it was the 24th revision of the 13.01 release (as opposed to being released on the 24th of the month).

Re: Plans for Vim 7.4

#48

Post by hetman »

Avshalom wrote: post #22
sophacles wrote: post #19

Earlier quoted context omitted.

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...)

only thing about Lua is that strings are immutable so certain kinds of operations can be very slow.

They are also immutable in Python.

Re: Plans for Vim 7.4

#49

Post by Bognar »

coldpie wrote: post #5

Version numbers are infuriating. Dates don't overflow, people! If you're doing incremental development that doesn't have a concept of a "stable release", just use dates. This applies to projects like Firefox and the Linux kernel. I was pretty annoyed when Linus went with 3.x. Eventually, it's going to run into the same problem 2.6.x did. Date-based versioning would have lasted forever!

Version numbers for applications with a public API should have meaning:

http://semver.org/

Re: Plans for Vim 7.4

#50

Post by gnosis »

hsitz wrote: post #30
sophacles wrote: post #19

Earlier quoted context omitted.

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...)

Vim supports scripting with Lua similar to the support it already has for Python, Perl, Ruby, Racket. Your instance of Vim just has to be compiled with that option. See ':h lua'. One major problem with its support for scripting languages has been that you can't count on other users having a Vim compiled with proper support. This includes Python, although more recently some distributions (e.g., I think, Ubuntu) have h…

99% of vim scripts still use VimScript.

I think this happens for a few reasons:

  - First, as you pointed out, not every user is guaranteed
    to have your favorite language installed.  But they will
    have VimScript whenever they use vim.

  - Second, even if a user has your favorite language
    installed, the version of vim they have might not be
    compiled with bindings for that language.  Only VimScript
    is guarateed to be compiled in.

  - Third, VimScript is the only language in vim that's not
    crippled in some way in respect to functionality.  All
    the other languages it supports have to rely on
    VimScript itself in order to perform some vim-related
    functions.  In some languages, this makes it so that you
    might as well be using VimScript to begin with.
Post reply on HN