Loading ...
Sorry, an error occurred while loading the content.

VIM: Out of the BOX

Expand Messages
  • Alok Bisani
    Case ... 1. What is the best thing that you like about VIM that is not there in other seperate individual Environments ( IDEs, Editors, Word Processors etc.)?
    Message 1 of 38 , Mar 8, 2004
    View Source
    • 0 Attachment
      Case
      ----
      1. What is the best thing that you like about VIM that is not
      there in other seperate individual Environments ( IDEs,
      Editors, Word Processors etc.)? Probably very little.

      2. Editing is a such widespread activity. We edit in so many
      places :- IDE, mail clients, word processors, browser forms (
      like this one ), text editors etc. But on how many different
      such tasks do you (or can you) use VIM? If you are someone
      who fall in the 90% category, probably not more than a few
      unique tasks.

      3. How many times, when you have edited using VIM for
      whatever
      purpose, that you felt you are missing some feature. A
      feature which would have been (or is) provided for better
      while in editing somewhere else. Probably IDE, or Mail client
      or Browser or whatever else. But then you can eat the cake
      and have it too. VIM is an editor and cannot/should not do
      more than that?!

      4. Quote from develop.txt
      "- Vim is not a shell or an Operating System. You will not
      be able to run a shell inside Vim or use it to control a
      debugger. This should work the other way around: Use Vim as
      a component from a shell or in an IDE. A satirical way to say
      this: 'Unlike Emacs, Vim does not attempt to include
      everything but the kitchen sink, but some people say that you
      can clean one with it. ;-)'"
      How applicable is this today? Can you truly clean everything
      with VIM. Probably not.

      5. World has progressed from CUI to GUI. It will move on.
      People will use advanced GUI and probably 3D UI for most of
      their tasks in the near future ;-) . How accessible is the
      unique interface of VIM in those situations. Probably not
      very accessible.

      Alternatives
      ------------
      What can we do now to make VIM accessible across the
      board, and forever? I suggest that we commoditize VIM. Wrap
      it in a useful framework of reusable objects (like one of the
      APIs available from Apache). Decouple it from anything that
      makes it captive in a box. And then mass market it. For use
      in any App where editing is involved. Have RAD elements of
      VIM controls. Something that would have VIM "OUT OF THE BOX",
      anywhere.

      I am no Systems Architect ( for now ) but I think the
      following steps outline this metamorphosis.

      1. Refactor the VIM codebase into a framework of reusable
      Object Oriented classes. Probably any (or every ?) OOP
      language could be used. Why keep VIM tied to C, when every
      modern system supports C++ or other OOPS.

      2. Make an API out of this framework codebase and use this
      intensively in a few environments like GVIM. Publish this for
      other projects to reuse.

      3. Make controls which would use this framework for ready
      deployment in GUI RAD Apps like using VB,MFC,GTK controls
      etc.

      This would take much more effort than currently gone into
      making VIM from VI. But it would certainly make VIM more
      pervasive. And much more accessible. And given time, and the
      involvement of contributors, this is certainly possible.

      Would love to hear the comments from the current Maintainers
      and VIM contributors on this line.

      -Alok

      __________________________________
      Do you Yahoo!?
      Yahoo! Search - Find what you�re looking for faster
      http://search.yahoo.com
    • Bram Moolenaar
      ... Extra data? ... I don t see why providing support for C plugins would be simpler than extending support for Vim scripting. Have a look at Python, which
      Message 38 of 38 , Apr 1 6:46 AM
      View Source
      • 0 Attachment
        Gergely Kontra wrote:

        > On 0309, Bram Moolenaar wrote:
        > > We already do: It is called Vim script. Since it mainly consists of Ex
        > > commands it's very practical for Vim users.
        > But not for complex tasks, which needs extra data

        Extra data?

        > > Attempts to use one of the (more or less) standard scripting languages
        > > have failed, for several reasons. My latest attempt is to suggest using
        > > Python, but you can see on the voting page how popular that is.
        >
        > Than can I write plugins in C, which can be compiled easily by end
        > users?

        I don't see why providing support for C plugins would be simpler than
        extending support for Vim scripting. Have a look at Python, which does
        support including C modules. It involves so many things: Getting them
        compiled, designing an API, etc. The main advantage is that it's
        faster.

        --
        hundred-and-one symptoms of being an internet addict:
        226. You sit down at the computer right after dinner and your spouse
        says "See you in the morning."

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
        \\\ Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///
      Your message has been successfully submitted and would be delivered to recipients shortly.