Live data from Hacker News

Plans for Vim 7.4

groups.google.com

51–60 of 86 posts

Re: Plans for Vim 7.4

#51
post #47

Earlier quoted context omitted.

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

I like this idea the best, but I think revision numbers are conventionally prefixed with a dash;

    13.01-24
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pac...

(i can never quite distinguish between revisions and releases... when is each used?)

Re: Plans for Vim 7.4

#52
post #23

Earlier quoted context omitted.

>> 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…

evil-mode[1] is a really well crafted vim emulator for emacs. Not those clunky emulations that barely do hjkl but something that replicates even text objects or repeat (.) . This made my migration from vim to emacs possible. [1] http://gitorious.org/evil/pages/Home

After over 20 years of very happily using vim and other vi-clones, I'm in the process of making emacs+evil my main editor.

Making the switch is slow and painful for this veteran vim user who has perfected his vim environment, but I can already see that the emacs environment that I build will be superior... eventually.

Plus, I get the joy of scripting my editor in elisp and eventually guile (I hope). No more vimscript for me!

That said, vim is a wonderful editor. Even if vim ultimately isn't as flexible as emacs, it's still incredibly powerful; and there's a lot of cross-fertilization going on between the two editors, with vim users getting inspired by emacs features and packages and writing vim equivalents and vice-versa.

Re: Plans for Vim 7.4

#54
post #25

The number one thing I'd want in vim is support for Multi Cursors, ala Sublime Text. This is something that's very hard to get right with a vim plugin, but could probably be added to core vim much more easily.

Vim Align and Ctrl+V Shift-I works for me but I agree... multicursors would be awesome.

Re: Plans for Vim 7.4

#55

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…

I would say all the aspects that you find lacking with the way Vim is developed, in my opinion, is what makes it the stable, powerful editor it is today.

It is somewhat following the linux model (with Linus as the primary developer in the early days).

Just like linux, I believe this has added to the widespread popularity of Vim (ie. it is available by default on most distributions).

Vim doesn't need to "modernize". I would say its availability and ability to still stay relevant is more modern than most other open-source software.

Re: Plans for Vim 7.4

#56
post #47

Earlier quoted context omitted.

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

I like this idea the best, but I think revision numbers are conventionally prefixed with a dash; 13.01-24 http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pac... (i can never quite distinguish between revisions and releases... when is each used?)

Yeah, that would be better.

In this context a revision is just a bug fix release, the same as a "point release" or "minor release" or "patch version." I'm sure there are terms I'm forgetting. A micro-version increment, where the system is ${major}.${minor}.${micro} (in what the kids call "semantic versioning," but what used to just be called "not versioning like an idiot.")

Re: Plans for Vim 7.4

#57
post #21

Would love a package management solution.

Since it hasn't been mentioned yet, I'll add https://github.com/MarcWeber/vim-addon-manager

(Not to be confused with http://packages.debian.org/sid/vim-addon-manager -- and yes, the author of the former got permission from the author of the latter to re-use the name.)

Re: Plans for Vim 7.4

#59
post #30

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…

  | although more recently some distributions
Even CentOS 4 had a Vim with python in it. The issue that I always came up against was Ruby support. Ruby wasn't compiled in, and some Vim plugins (e.g. LustyExplorer, FuzzyFinder) relied on it. I worry less about that now that Ctrl-P (written in Vimscript) has replaced those for me.

Re: Plans for Vim 7.4

#60
post #48

Earlier quoted context omitted.

They are also immutable in Python.

What are you talking about? http://docs.python.org/2/library/string.html

  >>> a = "string"
  >>> a[1] = 'g'
  Traceback (most recent call last):
    File "", line 1, in 
  TypeError: 'str' object does not support item assignment
  >>> b = a.replace('t', 'g')
  >>> b
  'sgring'
  >>> a
  'string'
  >>> id(b)
  3065252256L
  >>> id(a)
  3075481632L
Also from here[1]:

  Strings and tuples are immutable sequence types: such
  objects cannot be modified once created.
[1] http://docs.python.org/2/library/stdtypes.html#mutable-seque...
Post reply on HN