Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Software

Vim 7.2 Released 106

sanguisdex writes "After fifteen months of work: a brand new Vim release! This is a stable version. There are many bug fixes and updated runtime files. The only new feature worth mentioning is support for floating point. Upgrading from a previous version is highly recommended: a few crashing bugs and several security issues were fixed. For the details see the announcement or go directly to the download page."
This discussion has been archived. No new comments can be posted.

Vim 7.2 Released

Comments Filter:
  • by yagu ( 721525 ) * <yayagu.gmail@com> on Tuesday February 10, 2009 @03:40PM (#26803181) Journal

    O'Reilly released the latest new version of their vi book, (now "Learning the vi and Vim Editors") [amazon.com] last summer with seven new chapters devoted to vim!

  • First post! (Score:1, Funny)

    by Anonymous Coward

    :x

  • by Anonymous Coward on Tuesday February 10, 2009 @03:45PM (#26803283)

    beep constantly, and break everything

    • by Eudial ( 590661 )

      Ah, but it is very good at those things.:wq

    • ... is in front of the screen ;-)

    • command mode (beep constantly?)
      insert mode (not sure how you are breaking things here)

      and

      visual mode.

  • Am I crazy? (Score:5, Informative)

    by liebeskind ( 1401873 ) on Tuesday February 10, 2009 @03:46PM (#26803285)
    Am I crazy - or has vim 7.2 been out for a while?
    The date on the announcement is from August 8, 2009.
    Also:
    ~$ vim --version
    VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Nov 11 2008 17:20:43)
    • Re: (Score:1, Informative)

      by Anonymous Coward

      Just click the link, the post dates from 9 Aug 2008

    • The date on the announcement is from August 8, 2009.

      Oops, I meant to say "August 9, 2008". Sorry for the self reply.

    • by gardyloo ( 512791 ) on Tuesday February 10, 2009 @03:50PM (#26803363)

      The date on the announcement is from August 8, 2009.

            Eek! The Large Hadron Collider's effects have started leaking to other slashdot dimensions!

    • by dedazo ( 737510 )

      Yeah, this is way old. Except that Slashdot's search function doesn't seem to return an article on the release, so I guess you can't call it a dupe. OTOH you kind of wonder why a site like Slashdot would not publish that news to begin with. Since it's impossible to know if someone submitted it last year, we'll never know.

    • by Jurily ( 900488 )

      Am I crazy - or has vim 7.2 been out for a while?

      * app-editors/vim
      Latest version available: 7.2.021
      Latest version installed: 7.2
      Size of files: 9,077 kB
      Homepage: http://www.vim.org/ [vim.org]
      Description: Vim, an improved vi-style text editor
      License: vim

  • by Spasmodeus ( 940657 ) on Tuesday February 10, 2009 @03:47PM (#26803317)
    I've gone back in time six months!
  • posted by kdawson (Score:1, Interesting)

    by Anonymous Coward
    hey malda, I'm sure you and your corporate overlords are trying to save money these days. Rather than posting more slashvertisements, how about firing this douchebag?
  • News for the vim people, these days "vi compatible" means "nvi compatible". KTHX.

  • by Sponge Bath ( 413667 ) on Tuesday February 10, 2009 @03:58PM (#26803509)

    I will not make an Amiga or OS/2 binary for Vim 7.2.

    Why not? Then you would have an editor as antiquated as the OS it runs on.
    Ooooh! BURRRRN!

    • Please... (Score:5, Informative)

      by Anonymous Coward on Tuesday February 10, 2009 @04:15PM (#26803827)

      I work daily with humongous text files. I have found no other editor that performs as well when you work with text files that are in several gigabytes range. All the other major shell text editors cough instantly (tried for instance Emacs, it loaded one of those files for 30 minutes before I got bored of waiting) and most of the shiny new GUI editors are even worse. For instance gedit practically dies instantly on the stuff I work with.

      There is a place for vi*. You use them when the tool has to work. They are pain in the ass to use, but they manage things others do not.

      • Re: (Score:3, Funny)

        If the files you are editing are *that* big, then a text editor is not the correct tool.
        • Re:Please... (Score:5, Interesting)

          by Waffle Iron ( 339739 ) on Tuesday February 10, 2009 @05:33PM (#26805127)

          If the files you are editing are *that* big, then a text editor is not the correct tool.

          Ok. Let's assume that you've been given a plain text file of that size, and you need to modify something in it. What tool do you suggest?

          I can think of the stock answers:

          "Load it into a database" - lots of hassle and probably overkill

          "Filter it with a custom script" - maybe, if you're a programmer

          "sed" - could work, but why bother if vim works? Personally, I can never remember the sed syntax.

          "Don't use text files that big" - Assumes facts not in evidence

          Any other suggestions?

          • Re:Please... (Score:4, Informative)

            by lewiscr ( 3314 ) on Tuesday February 10, 2009 @07:05PM (#26806349) Homepage

            "sed" - could work, but why bother if vim works? Personally, I can never remember the sed syntax.

            *sputters* You can't remember the sed syntax? It's the same as vi.

            Mostly likely, if you're editting a several gig text file, you're doing bulk edits, not single edits. ala:

            :%s/hamburger/cheeseburger/g

            Well, here's the sed script to do that:

            sed 's/hamburger/cheeseburger/g' < infile > outfile

            They're so similiar, I suspect that they're related... yup. The Sed History [umich.edu] says that "Sed was first written in 1977 as a stream adaptation of the ed editor".

            And since vi is just a fancy tui on top of ed, you already know sed.

            Why bother? Just because vi can edit large files, it's still painfully slow. Large and/or many edits are very slow to apply and undo. The same commands executed in sed can be done order of magnitude faster. I believe (but have never taken the time to prove it) that it's related to the undo buffer. And yes, my anecdotal evidence took place on machine with enough RAM that no swapping was required for vi or sed.

            Now if you want to get really productive, we can talk about taking your vi commands, wrapping them in a sed script, then running it through sed2perl. Oh the Thinks you will have Thunk.

            • by nlper ( 638076 )

              "sed" - could work, but why bother if vim works? Personally, I can never remember the sed syntax.

              *sputters* You can't remember the sed syntax? It's the same as vi.

              Mostly likely, if you're editting a several gig text file, you're doing bulk edits, not single edits. ala:

              :%s/hamburger/cheeseburger/g

              A perfectly good point, unfortunately marred by the remarks that follow.

              Mostly likely, if you're editting a several gig text file, you're doing bulk edits, not single edits.

              You're assuming conditions not previously specified. What if the poster only changes hamburger to cheeseburger depending on the values of relish and pickle on nearby lines? Are you one of those manly men who use sed to repair mismatched braces in your source files?

              My point being that if the previous posters in the subthread find vim satisfactory for the problems they're thinking of, it might be because they understand their typical prob



              • As long as the fileformat is somewhat sane, this isn't at all difficult. To replace hamburger with cheeseburger between "two lines down from pickles=yes" and "three lines above the next occurrence of relish=no":

                /pickles=yes/+2,/relish=no/-3s/hamburger/cheeseburger/g

                You can get quite funky as those two range markers are fully regexp-aware, of course!
              • by lewiscr ( 3314 )

                vi are pretty much irrelevant to a thread on vim

                Sorry, I'm on one of those platforms that replaced vi with vim years ago. I incorrectly use them interchangably. Please substitute all references of vi in my previous post with vim.

                I have not benchmarked vi in this area for at least 6 years, so I won't talk about vi.

                because they understand their typical problems better than you do

                Very likely. I can only offer my own experience. When I open a large file in vim, I'll usually wait a few seconds and then start writing a sed, awk, or perl script to accomplish the same goal. I'll drop awk and perl for the rest of the discu

            • Seeing as you seem to know what you're talking about I'm going to risk being rude by hijacking this sub-thread to ask a question:
              Is it possible to fold not lines, but groups of words in vi(m)? E.g. to change

              This is some text (and it contains this paranthesized phrase which I wish to fold away) which has a paranthesized phrase hidden away in the first line. I'd like the text to be a little shorter.

              into this

              This is some text FOLD+-- which has a paranthesized phrase hidden away in the first line.
              • by lewiscr ( 3314 )

                There are some modules aimed at code folding, but they all appear to be line based.

                I'm not very expienced with folding, so I might be missing something. Maybe if you explore the depths of Folding by Syntax [vim.org] or Folding by Expression [vim.org].

                Sorry I couldn't be more help.

                • by crush ( 19364 )
                  Thanks for the references. I'd already read those bits and come to the same conclusion: folding is entirely line-based. Seems like an itch to scratch! Thanks again.
          • Depending on what you need to replace, how large the file is, and how many files you need to change, dd might be your "editor" of choice. Although IANA('nix pro), so I'm not sure it's possible to get dd to just overwrite a few bytes in the middle of a file without setting up a loopback device.

            Hmm..

            A quick skim through the shred man page suggests it might be useful if the bits you want to overwrite are at the begining of the file...

            It always bothered me that Perl's "in place" option actually is nothing of t

      • by Nutria ( 679911 )

        I work daily with humongous text files. I have found no other editor that performs as well when you work with text files that are in several gigabytes range.

        Not in Debian (or maybe all of Linux?) it doesn't.

        http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=139510 [debian.org]

        This bug is 7 years old, and a variant of it still exists.

        • by nlper ( 638076 )

          I work daily with humongous text files. I have found no other editor that performs as well when you work with text files that are in several gigabytes range.

          Not in Debian (or maybe all of Linux?) it doesn't.

          Sorry, I view that link you gave as less of a bug report than a Twit Alert. Seriously, when was the last time you ran across a 2.7 GB file of nulls and thought of it as a text file to be edited?

          The relevant section of the Vim docs [vim.org] explains that the maximum length of a line and the maximum number of lines per file depends on the local size of long integers, typically 32 bits. So if your box is limited to 2G lines per file and 2GB per line, is it any wonder there's an error message upon encountering 2.7 GB of

      • Re:Please... (Score:4, Interesting)

        by Mad Merlin ( 837387 ) on Tuesday February 10, 2009 @07:08PM (#26806395) Homepage

        There is a place for vi*. You use them when the tool has to work. They are pain in the ass to use, but they manage things others do not.

        Not really, I use Vim in preference to every other editor. Once you're used to Vim you can edit at least 10x faster than with an "easy" GUI editor.

        • AOL. Vim is *really* powerfull if you know how to handle it. For example lets asume you download some show and want to have sane filenames. So i go to the directory of the show every few months and make a 'ls -1 > out; vim out'. In my vimrc i have this: let @m="0v$hyimv \"^[A\" \"\"^[hp0j"

          With this i press @m and transform a line from

          The.Daily.Show.2009.02.04.PDTV.XviD-aAF.[VTV].avi to

          mv "The.Daily.Show.2009.02.04.PDTV.XviD-aAF.[VTV].avi" "The.Daily.Show.2009.02.04.PDTV.XviD-aAF.[VTV].avi"
          (usually someth

        • by Cyberax ( 705495 )

          Bullshit.

          It may be true for extremely large files, but is false for almost everything else.

          For example, VisualStudio has almost all advanced features of vim. Like clipboard ring, vertical blocks, bookmarks, automatic positioning, etc.

  • by gEvil (beta) ( 945888 ) on Tuesday February 10, 2009 @04:02PM (#26803605)

    Hey! Check out this post I came across while browsing usenet. Have any of you heard anything about this? Sounds like it might be kinda cool.

    From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
    Newsgroups: comp.os.minix
    Subject: Free minix-like kernel sources for 386-AT
    Keywords: 386, preliminary version
    Message-ID:
    Date: 5 Oct 91 05:41:06 GMT
    Organization: University of Helsinki
    Lines: 55

    Do you pine for the nice days of minix-1.1, when men were men and wrote
    their own device drivers? Are you without a nice project and just dying
    to cut your teeth on a OS you can try to modify for your needs? Are you
    finding it frustrating when everything works on minix? No more all-
    nighters to get a nifty program working? Then this post might be just
    for you :-)

    As I mentioned a month(?) ago, I'm working on a free version of a
    minix-lookalike for AT-386 computers. It has finally reached the stage
    where it's even usable (though may not be depending on what you want),
    and I am willing to put out the sources for wider distribution. It is
    just version 0.02 (+1 (very small) patch already), but I've successfully
    run bash/gcc/gnu-make/gnu-sed/compress etc under it.

    Sources for this pet project of mine can be found at nic.funet.fi
    (128.214.6.100) in the directory /pub/OS/Linux. The directory also
    contains some README-file and a couple of binaries to work under linux
    (bash, update and gcc, what more can you ask for :-). Full kernel
    source is provided, as no minix code has been used. Library sources are
    only partially free, so that cannot be distributed currently. The
    system is able to compile "as-is" and has been known to work. Heh.
    Sources to the binaries (bash and gcc) can be found at the same place in /pub/gnu.

    ALERT! WARNING! NOTE! These sources still need minix-386 to be compiled
    (and gcc-1.40, possibly 1.37.1, haven't tested), and you need minix to
    set it up if you want to run it, so it is not yet a standalone system
    for those of you without minix. I'm working on it. You also need to be
    something of a hacker to set it up (?), so for those hoping for an
    alternative to minix-386, please ignore me. It is currently meant for
    hackers interested in operating systems and 386's with access to minix.

    The system needs an AT-compatible harddisk (IDE is fine) and EGA/VGA. If
    you are still interested, please ftp the README/RELNOTES, and/or mail me
    for additional info.

    I can (well, almost) hear you asking yourselves "why?". Hurd will be
    out in a year (or two, or next month, who knows), and I've already got
    minix. This is a program for hackers by a hacker. I've enjouyed doing
    it, and somebody might enjoy looking at it and even modifying it for
    their own needs. It is still small enough to understand, use and
    modify, and I'm looking forward to any comments you might have.

    I'm also interested in hearing from anybody who has written any of the
    utilities/library functions for minix. If your efforts are freely
    distributable (under copyright or even public domain), I'd like to hear
    from you, so I can add them to the system. I'm using Earl Chews estdio
    right now (thanks for a nice and working system Earl), and similar works
    will be very wellcome. Your (C)'s will of course be left intact. Drop me
    a line if you are willing to let me use your code.

                    Linus

    PS. to PHIL NELSON! I'm unable to get through to you, and keep getting
    "forward error - strawberry unknown domain" or something.

  • by Leto-II ( 1509 ) on Tuesday February 10, 2009 @04:45PM (#26804321)

    We now know for sure kdawson is not a Vim user.

  • i sure wish the vim developers would fix that buggy gtk2 frontend, i get artifacts in the menus and the buffer loses text...

    Midnight Commander's built in editor (mcedit) is good enough for me...
  • Great News! (Score:5, Funny)

    by PPH ( 736903 ) on Tuesday February 10, 2009 @09:41PM (#26807571)

    I've been waitti^H^H damn! ^H^H ^Q ^[ .... :w :q :wq :wq! ^d
    exit X Q ^C ^? :quitbye CtrlAltDel ~~q :~q logout save/quit :!QUIT
    ^[zz ^[ZZZZZZ ^H man vi ^@ ^L ^[c ^# ^E ^X ^I ^T ? help helpquit ^D
    man quit ^C ^c ?Quit ?q CtrlShftDel "Hey, what does this button d..."

No spitting on the Bus! Thank you, The Mgt.

Working...