Stories
Slash Boxes
Comments

SoylentNews is people

posted by takyon on Monday September 12 2016, @10:28PM   Printer-friendly
from the asynchronous-release dept.

Vim 8.0 has been released. This is the first major Vim release in 10 years.

New features include:

  • Asynchronous I/O support, channels, JSON
  • Jobs
  • Timers
  • Partials, Lambdas and Closures
  • Packages
  • New style testing
  • Viminfo merged by timestamp
  • GTK+ 3 support
  • MS-Windows DirectX support

Even if Neovim never becomes status quo in the vi world, has the competition at least given Vim developers a shot in the arm?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Insightful) by Snotnose on Tuesday September 13 2016, @02:35AM

    by Snotnose (1623) on Tuesday September 13 2016, @02:35AM (#401081)

    I started the "what am I missing" thread, asking why half the new "features" are needed in a text editor. The replies are all yay/nay on vi vs SomeOtherEditor, not a single one is on why I would possibly want asynchronous I/O, timers, or Jobs in a bloody text editor.

    So, can we forget the Vi sux/rulz arguments and edumacate me on why I would want any of these new "features" in my daily text editor?

    FFS, I'd rather have a ctags that works for Java and Python over asynchronous I/O timers.

    --
    Why shouldn't we judge a book by it's cover? It's got the author, title, and a summary of what the book's about.
    Starting Score:    1  point
    Moderation   +1  
       Insightful=1, Total=1
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2) by Snotnose on Tuesday September 13 2016, @02:43AM

    by Snotnose (1623) on Tuesday September 13 2016, @02:43AM (#401085)

    I should clarify before I potentially get roasted. I run cygwin under Win10. Ctags + vim in this environment utterly fail for both Python and Java. As of maybe a year ago, when I last tried to get it to work on Java. Longer for Python.

    --
    Why shouldn't we judge a book by it's cover? It's got the author, title, and a summary of what the book's about.
    • (Score: 1, Funny) by Anonymous Coward on Tuesday September 13 2016, @05:11AM

      by Anonymous Coward on Tuesday September 13 2016, @05:11AM (#401134)

      I run cygwin under Win10.

      YOU SHOULD USE LINUX BECAUSE WINDOWS SUCKS AND MICROSOFT SUCKS AND YOU SUCK.

    • (Score: 2) by NotSanguine on Tuesday September 13 2016, @07:55AM

      by NotSanguine (285) <NotSanguineNO@SPAMSoylentNews.Org> on Tuesday September 13 2016, @07:55AM (#401184) Homepage Journal

      I should clarify before I potentially get roasted. I run cygwin under Win10. Ctags + vim in this environment utterly fail for both Python and Java. As of maybe a year ago, when I last tried to get it to work on Java. Longer for Python.

      have you considered native Windows Emacs [sourceforge.net] instead? It has all the features of vim (with vim key bindings [emacswiki.org] if you like), as well as Exuberant CTags [sourceforge.net] which can even be called from within emacs.

      In fact, once you open emacs, you never have to leave. You can read mail, browse the web, bake cookies, order pizza, control your Fleshlight™, mix margaritas and binge watch Knight Rider [wikipedia.org] (emacs users *love* David Hasselhoff!).

      --
      No, no, you're not thinking; you're just being logical. --Niels Bohr
  • (Score: 5, Informative) by Marand on Tuesday September 13 2016, @03:43AM

    by Marand (1081) on Tuesday September 13 2016, @03:43AM (#401106) Journal

    I started the "what am I missing" thread, asking why half the new "features" are needed in a text editor. The replies are all yay/nay on vi vs SomeOtherEditor, not a single one is on why I would possibly want asynchronous I/O, timers, or Jobs in a bloody text editor.

    So, can we forget the Vi sux/rulz arguments and edumacate me on why I would want any of these new "features" in my daily text editor?

    async

    This is coming from an emacs perspective, but the rationale for async is usually to avoid blocking the entire interface when waiting for a long task to complete. You could end up with, say, your editor freezing briefly because you're editing a file that's on a network share, the editor starts to autosave, and hangs waiting for the share. Or if your editor accepts URLs as valid filenames (like KDE's kate and kwrite), it could block while waiting on a site to load.

    In emacs this is often a problem with packages that rely heavily on network support, such as email and RSS clients. For another example, the built-in package manager for installing new packages will block while contacting the repository to update the package list. When this happens emacs is unresponsive, and any input attempts just end up held and executed after it finishes loading.

    Jobs, timers

    Jobs and timers sound like ways to schedule events, such as setting a timer to autosave every 5 minutes, or one to check if a file you're editing has changed since you opened it. Probably helps make it easier to automate things when extending vim.

    Partials, lambdas, closures
    Functional programming stuff, mostly. I'm not going to go over this in detail because it could get long, and you likely either aren't a programmer and won't care, or you are and already know what they are. If I'm mistaken and you're interested in an explanation, just ask and I'll give it its own post.

    Packages
    This sounds like package management for vim extensions, like how emacs ships with package.el. Think "apt-get for vim".

    Other
    I don't use vim much and have no idea what "new style testing" and "viminfo merged by timestamp" are about. The gtk3 and directx support would be related to UI rendering, not much to say there.

    Finally, you can read this text file [githubusercontent.com] if you want a better rundown of what the changes are about from a vim context.

    • (Score: 2) by bart9h on Tuesday September 13 2016, @03:50AM

      by bart9h (767) on Tuesday September 13 2016, @03:50AM (#401108)

      async can also work for, like, a plugin that auto-compiles the code in the background, and highlight errors while you're typing (like an IDE).

      • (Score: 2) by Marand on Tuesday September 13 2016, @04:15AM

        by Marand (1081) on Tuesday September 13 2016, @04:15AM (#401116) Journal

        Yep, another good example, along with things like symbol checking and completion, spell checking, etc. Basically anything that isn't directly related to "type character, output character" can end up blocking if it takes too long for some reason.

        I used network stuff in my examples because that's usually the most prone to blocking and the most frustrating when it happens. It's no fun having your program freeze because an extension pulls data off the internet and someone forgot to renew a domain name. :/

    • (Score: 0) by Anonymous Coward on Tuesday September 13 2016, @04:30AM

      by Anonymous Coward on Tuesday September 13 2016, @04:30AM (#401121)

      Partials, lambdas, closures Functional programming stuff, mostly. I'm not going to go over this in detail because it could get long, and you likely either aren't a programmer and won't care, or you are and already know what they are. If I'm mistaken and you're interested in an explanation, just ask and I'll give it its own post.

      So now Vim gets a scripting language more or less equivalent to Emacs Lisp... Except that elisp is probably one of the last widely-used Lisp dialects that uses dynamic binding, and hence doesn't have closures.

      And what was the advantage that vi supposedly had over Emacs here? The lack of a scripting language and the associated bloat such a thing supposedly added?

      • (Score: 2) by Marand on Tuesday September 13 2016, @05:22AM

        by Marand (1081) on Tuesday September 13 2016, @05:22AM (#401136) Journal

        Except that elisp is probably one of the last widely-used Lisp dialects that uses dynamic binding, and hence doesn't have closures.

        You're close, but your knowledge is a bit outdated. Emacs gained lexical binding in 2012 with v24.1 (ref. [gnu.org]), though it's disabled unless your elisp file explicitly enables it. So, closures are possible if you want them.

        Not really relevant to vim, just figured I'd tell you the situation changed somewhat. :)

    • (Score: 4, Informative) by cubancigar11 on Tuesday September 13 2016, @07:06AM

      by cubancigar11 (330) on Tuesday September 13 2016, @07:06AM (#401162) Homepage Journal

      viminfo is the file stores your workflow info such as where was your cursor when you close a particular file etc. It is autogenerated by vim. Now, multiple version of vim will merge their personal version (stored in memory) based on timestamp when you quit.

    • (Score: 3, Informative) by darkfeline on Tuesday September 13 2016, @04:58PM

      by darkfeline (1030) on Tuesday September 13 2016, @04:58PM (#401395) Homepage

      >In emacs this is often a problem with packages that rely heavily on network support, such as email and RSS clients. For another example, the built-in package manager for installing new packages will block while contacting the repository to update the package list.

      Emacs has had asynchronous *subprocesses* for ages. What Emacs doesn't have is asynchronous Emacs Lisp (not natively, anyway), and from my understanding neither does Vim. The problem with async is state, and text editors like Emacs and Vim have a LOT of state.

      (The old guard of email and RSS clients in Emacs were written in pure Emacs Lisp and hence suffer from blocking. Newer clients (for example mu4e) use async subprocess and don't block.)

      Emacs has had async subprocess for forever, and Vim is just getting them now. One of the key reasons why Neovim even exists is because Bram Moolenar wouldn't accept the async patches and it's such a good feature. I don't know whether to laugh because Vim is now usable as an IDE, or cry because Vim is just trying to reimplement Emacs, badly.

      --
      Join the SDF Public Access UNIX System today!
      • (Score: 0) by Anonymous Coward on Tuesday September 13 2016, @10:08PM

        by Anonymous Coward on Tuesday September 13 2016, @10:08PM (#401489)

        I pick cry because Vim is now usable as an IDE.

      • (Score: 2) by Marand on Tuesday September 13 2016, @10:49PM

        by Marand (1081) on Tuesday September 13 2016, @10:49PM (#401502) Journal

        Yeah, I'm aware that async is available and used by some packages in emacs; I have some (maybe many) that rely on it, in fact. Going to mod you informative for the benefit of anybody else reading, though. :) I just thought emacs would be useful for example purposes because, as you said, some packages still don't use it and will block, so it's a familiar enough situation that I could explain it.

        The one that bugs me is that package.el blocks when contacting its repos. I guess most people don't worry about it because it's usually fast, but on a shit connection like what I'm using right now it means a very long period of emacs being completely unresponsive. I also had a blocking problem with an email client, I think wanderlust, too, but that wasn't a big deal since I was just trying it out as a curiosity.

        I don't know whether to laugh because Vim is now usable as an IDE, or cry because Vim is just trying to reimplement Emacs, badly.

        To paraphase the quote about unix: those that don't understand emacs are doomed to reimplement it poorly. :)

        I kind of think it's funny, because the religious vim adherents always seem to mention how light their editor is, how it doesn't do all this extra stuff, and deride the emacs "everything and the kitchen sink" extensibility, but vim's been heading down that same path for years. It appears to even has its own package.el equivalent now, which I find hilarious.

        Personally, I like vim for quick edits and emacs for everything else, so the only thing I've done to vim is set a colour scheme (molokai) and set a few config options, and that's how it's likely to stay. Likewise, emacs remains my OS of choice for the foreseeable future. ;)

        • (Score: 2) by darkfeline on Wednesday September 14 2016, @05:17PM

          by darkfeline (1030) on Wednesday September 14 2016, @05:17PM (#401911) Homepage

          One thing to consider is that the packages that ship with Emacs cannot really rely on external programs being available, so they also need to rely on Emacs Lisp for portability.

          It shouldn't be difficult to extend packages.el to be asynchronous, but I suspect it's not as big an issue as Gnus. I update the packages whenever I restart Emacs, which is never, and I suspect most Emacs users do the same.

          --
          Join the SDF Public Access UNIX System today!
          • (Score: 2) by Marand on Thursday September 15 2016, @01:08AM

            by Marand (1081) on Thursday September 15 2016, @01:08AM (#402092) Journal

            In my case, I load the package list frequently because I often get this "I wonder if someone already did this?" thought and go see if there's already a package that does the job. So, that's why it bites me in the ass a lot. As for gnus, I never really got into it for some reason.

            Good point about standard packages not being able to rely on the async lib. It would be nice if it got promoted to becoming an emacs built-in, though. If a bunch of games can be shipped with it, why not async? (The same could also be said for some of the interesting language extensions, such as the stuff in dash.el. It'd be great to have dash.el's threading macros and some other features built-in)

  • (Score: 0) by Anonymous Coward on Wednesday September 14 2016, @02:31AM

    by Anonymous Coward on Wednesday September 14 2016, @02:31AM (#401595)

    Vim is for people who like the whole "casually press a few keys in a row to quickly modify a lot of text" bit that characterizes vi, but it's also very extensible, similarly to emacs.
    If you're a plugin author, you're probably going to want these features. If you're an end user, you're going to want these features so you can use plugins depending on vim 8.

    Many vim users use a lot of plugins, and there's a fair few who practically use it as an full IDE via plugins.