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

71–80 of 86 posts

Re: Plans for Vim 7.4

#71

Post by noselasd »

ShawnBird wrote: post #66
pyre wrote: post #60

Earlier quoted context omitted.

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

Oh. I guess I never thought of strings as immutable because there are so many ways to change them.

Given that they're immutable, you cannot change them. Instead all the operations returns a new, modified, string.

Re: Plans for Vim 7.4

#72

Post by UNIXgod »

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)

vi with mouse integration? They have had this for years. Download the source and grok my friend. You probably are running nvi and not vim. Also in either your terminal or x you can simply middle click your mouse if you need to mouse copy/paste. I recommend addressing in ex mode or using the vi visual mode commands to do it. If your really dependent on "drag/drop" gui style editing using ex proper will defeat that. In vim I'm sure a simple script would even bring it to the gui drag/drop concept to the editor by automating addressing from mouse selection. Though it would be slower for the end user and simply not provide the flow and control ed and vi/ex users have had for years.

Re: Plans for Vim 7.4

#73

Post by UNIXgod »

nathan_long wrote: post #12
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…

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

Want lisp the original source for Bill Joy's vi supports it.

http://ex-vi.sourceforge.net/

Happy hacking =)

Re: Plans for Vim 7.4

#74

Post by zem »

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

emacs is open-source and has a really good vi mode (evil). have at it.

Re: Plans for Vim 7.4

#75

Post by siddboots »

gnosis wrote: post #50
hsitz wrote: post #30

Earlier quoted context omitted.

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

#2 has been the biggest drawback in my experience. It often isn't realistic to compile your editor from scratch, particularly when you are working in a windows environment without administrator rights to your machine. This means that any extensions (e.g. dbext) dependent on those bindings are unavailable.

Is there a reason why there is no portable binary compiled with bindings for perl, python, lua, et cetera?

Re: Plans for Vim 7.4

#76

Post by sliverstorm »

tvon wrote: post #47
keypusher wrote: post #42

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

Yeah, that wouldn't be the slightest bit confusing.

Re: Plans for Vim 7.4

#77

Post by bjeanes »

rgrau wrote: post #23
nathan_long wrote: post #12

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

agreed. It's a phenomenally "true" interpretation of Vim. Focusing on the "operator", "motion" and "text object" abstractions and making them composable functions is just sweet. Honestly, I think it's a better approach than how Vim does it...

Re: Plans for Vim 7.4

#78

Post by ics »

gnosis wrote: post #68
eric-hu wrote: post #67

Earlier quoted context omitted.

I'm thinking of making the switch. Are you able to port your vim plugins to emacs in evil mode?

I don't know if it's possible to automatically port vim plugins to evil. However, according to the emacswiki page on evil[1], a number of vim plugins have been ported: evil-surround: Port of Vim’s surround script. evil-numbers: Vim-like increment and decrement. evil-leader: Port of Vim’s mapleader. evil-rails: Port of rails.vim. evil-nerd-commenter: Port of Vim’s Nerd-Commenter Also, there are many emacs packages tha…

I use both regularly, but considering the investments involved I would say that I "switched to emacs" and vim is simply there when I need it.

I agree with your tips but the one thing I would add is that if you're worried about porting your vim plugins, don't. I use evil and the evil-plugins you listed happily, but beyond those awaits a vast world of emacs plugins from hordes of emacs.d hoarders, ready to eval your kinkiest, textiest dreams.

Basically, don't get hung up on plugins. They exist because they don't make up the core of your editor, and if you find yourself liking emacs even a little bit then it is very likely you'll find a suitable replacement for each of those functions.

Re: Plans for Vim 7.4

#79

Post by richo »

samstokes wrote: post #41
richo wrote: post #20

Earlier quoted context omitted.

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 .

Sorry my bad. Typing from memory on my phone.

Thanks for clearing it up!

Re: Plans for Vim 7.4

#80

Post by zmmmmm »

chjj wrote: 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.…

I sort of want the inverse of IDE features; I want VIM to support APIs to make it embeddable. I should be able to use VIM as a window _inside_ eclipse, visual studio, XCode, etc. VIM will simply never replicate the thousands of man-years of work that has gone into the IDEs. And if it did, all it would achieve is being an IDE just like they are already. But I think with a relatively small amount of effort it could publish a binary API spec that would let any IDE embed it's windows (like how Eclipse embeds Internet Explorer windows).
Post reply on HN