8 ms·
Plans for Vim 7.4
- coolwanglu 13y agoHmm, the signature looks interesting.
- GhotiFish 13y agoE M A C S s e l o h c t t n i a a t f p r t e o l
- sigzero 13y agoha ha, love it.
- camus 13y agoCome on , there is room for both VIM and Emacs , but i must say VIM seems more popular today.
- munchor 13y agoMaybe on r/vim, but on r/emacs it seems that Emacs is, by far, the most used text editor in the whole world! What I mean is that it's hard to know which editor is the most popular, it really depends on the communities you visit
- oinksoft 13y agoI 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 <C-N>, buffer keyword completion, are unusably slow for my purposes). * Built-in support for some filesystem operations. NERD_tree/:! can be clunky, and dropping into the shell isn't always ideal. * Real shell buffer .. I know I'll get my head cut off for this because it is quite emacs-y, but it would be nice to be able to run my shell in a buffer. At the very least, it would be nice to have :sh be a somewhat capable terminal that could handle colors and generally feel like a normal terminal. I'm excited to see 7.4 because it looks like some real new direction for the project, for better or worse. 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.
- jaredmcateer 13y agoThe vim voting page describes the IDE features as a built in debugger and shell window.
- nathan_long 13y ago>> 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.
- sophacles 13y agoIve 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...)
- coldpie 13y agoVersion 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!
- oinksoft 13y agoFor internal purposes, you're probably right. For distribution and documentation purposes, I think it's much easier to understand "this plugin works on 7.3 or later" than "this plugin works on 2010-08-25 or later."
- keypusher 13y agoYou 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.
- tvon 13y agoJust 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).
- bti 13y agoAnyone know how long it would take for the 7.4 update to reach MacVim?
- chjj 13y agoI'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. using vimscript. I prefer that over hardcoded integration. I'm just curious what's meant by IDE features. Maybe I'm misinterpreting it. At the end of the day, I trust Bram. He's created an amazing text editor and maintained it for more than 20 years.
- sigmavirus24 13y agoWell, 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 https://news.ycombinator.com/item?id=5680216
- Kurtz79 13y agoWell, one of the reason of VIM success is its configurability. I'm guessing the "IDE" features could be enabled/disabled as will, just as you have the option of using vim as just "vi".
- zmmmmm 13y agoI 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).
- robotjosh 13y agoJust 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)
- mpyne 13y agoMouse 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.
- tmhedberg 13y agoNew features are voted on not by mailing list/Google group participants but by users who have donated at least €10 to the Ugandan charity that Bram sponsors via Vim development. Also, I'm not sure in what sense mouse integration is "the obvious flaw", given that (A) it already exists if you use the GUI version, or in the terminal if your terminal supports mouse reporting (see :help mouse-using) and (B) most Vim users tend to actively avoid the mouse anyway.
- mrgoldenbrown 13y agoWait, what? Since when does being in the google group let you vote? I thought you had to be a paying customer/sponsor to vote.
- keypusher 13y agoA paying vim customer?
- lacksconfidence 13y agoyes you need to donate 10 euro to the ugandan charity Bram chose to support. http://www.vim.org/sponsor/ http://www.vim.org/sponsor/
- keypusher 13y agoBecause 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.
- caioariede 13y agoThings 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
- ElongatedTowel 13y agoWith 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.
- kzrdude 13y agoThe Vim project seems to favor making everything work themselves.. Which is a shame, so much would be gained from learning from other projects and keeping up to date with best practices elsewhere. My own very brief discussion about encryption in Vim makes me conclude that Bram doesn't want to learn from others (not from me, from current best practices in crypto) and doesn't keep in touch with others.
- SandB0x 13y agoWould love a package management solution.
- dcope 13y agoI'm sure you've heard of pathogen, but if not, check it out here: https://github.com/tpope/vim-pathogen https://github.com/tpope/vim-pathogen. I've been using it for a while and it's fantastic.
- darklajid 13y agoVundle is what I use.
- SandB0x 13y agoI use Vundle too but it's often frustating. The package management in Sublime Text looks much slicker, but then Sublime Text is slick overall.
- jcoder 13y agoPathogen—as mentioned—is great, but I've switched to Vundle and find it easier to manage.
- vially 13y agoVundle (https://github.com/gmarik/vundle https://github.com/gmarik/vundle) is good enough for me.
- graywh 13y agoSince it hasn't been mentioned yet, I'll add https://github.com/MarcWeber/vim-addon-manager https://github.com/MarcWeber/vim-addon-manager (Not to be confused with http://packages.debian.org/sid/vim-addon-manager 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.)
- edanm 13y agoThe 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.
- xutopia 13y agoVim Align and Ctrl+V Shift-I works for me but I agree... multicursors would be awesome.
- lenni 13y agoI've been using this for a few weeks: https://github.com/terryma/vim-multiple-cursors https://github.com/terryma/vim-multiple-cursors Works great!
- gnosis 13y agoActually, I found this plugin to be kind of buggy. However, I'm sure it'll get better soon, as it only had its first release a few weeks ago.
- Kurtz79 13y agoStill motivated and eager to make improvements (and not really trivial ones) to his (free!) software after so many years to the benefit of the whole software community. Kudos to Bram Moolenaar.
- leishulang 13y ago1. Expand the vim philosophy to be a whole OS UI experience, be able to control all apps on the screen using vim controls. 2. jokes aside, the most important need is probably better repl: eval result should pop up on screen.
- leephillips 13y agoNot quite sure what you mean - have you tried ScreenSend?
- deleted 13y ago[deleted]
- gaving 13y ago"Besides that, if you are maintaining runtime files, please send me any pending updates." Sure feels like 2013.
- lightblade 13y agoI would love to see JavaScript integration so we can script vim with JavaScript. A JavaScript debugger integration would be awesome too.
- arc_of_descent 13y agoI've been using Vim for close to 10 years. Can't live without it. My only gripe is the session file created with mksession is quite huge in size.
- cm3 13y agoA properly integrated and efficient ido for vim would be nice. CtrlP didn't work as well the last time I tried.