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

GSoC: Buffer/Window/Tab Improvements

Expand Messages
  • Mads N Noe
    Hi, Realizing that Google has extended the deadline, I would like to hear what you think of my proposals for GSoC. Application follows: == Abstract == As
    Message 1 of 1 , Apr 1, 2008
    • 0 Attachment

      Realizing that Google has extended the deadline, I would like to hear
      what you think of my proposals for GSoC. Application follows:

      == Abstract ==

      As Tabbed Document Interfaces (TDI) gain footing in browsers, editors
      and IDEs, people will become increasingly aware of the TDI support of
      Vim. It is therefore desirable that the tab page functionality in Vim
      feels complete and integrated. These two proposals aim to address this
      by improving the extendability and usability of tab pages.

      Global Windows:

      The first proposal tries to circumvent the limitation, that you cannot
      have global (or permanent) windows when using tab pages, as all
      windows are enclosed by the tab pages. This is done by introducing a
      special, restricted kind of windows that encloses the tabs. Global
      windows make it possible for extensions to take full advantage of TDI
      in terms of integration between tab pages. Applications could be netrw-
      descendants, outlining tools, class explorers, debuggers etc.

      Buffer Locking:

      The second proposal makes it possible to reuse existing windows and
      tabs when navigating through multiple files. When issued by a command
      like <C-w><C-f> or:stselect, and the destination is already open, the
      corresponding window or tab page will be selected instead. This is the
      behavior known from for instance Eclipse.

      While it could be implemented with a simple script, this proposal is
      more flexible, as it let the user choose which windows to reuse by
      adding a mechanism to lock windows to a given buffer. Also, this
      prevents the window from accidentally switching to another buffer.

      == Detailed Description ==

      I have two proposals to improve the way buffers, windows and tab pages
      can be used when dealing with projects consisting of multiple files:
      Global windows that encloses a set of tab pages, and a buffer locking
      feature that makes it convenient to reuse windows and tabs.

      Global Windows:

      Tabbed Document Interfaces have become quite popular in the last few
      years, and I was happy to see that Vim 7 came with support for tab
      pages back in 2006. I like, for instance, to be able to see the which
      files I am working on all the time, so that I don't have to remember
      the filenames.

      However, while the implementation simple and elegant, I think it is a
      serious limitation that you cannot wrap tab pages inside windows. This
      makes it impossible (or really hard) to develop extensions that
      presents information globally for all tab pages, for instance
      outlining or a file selector. I can think of two approaches to make
      this possible:

      The one approach is to add another window class on top of the "*-do
      stack" (something like globwindo => tabdo => windo). Tab page and
      normal window operations works as usual, but you can switch between
      special "global" windows enclosing them in groups. To simplify the
      implementation, these windows could subjected to certain restrictions,
      like only allowing vertical splits. Also, one of the global windows
      will be the "main" one, that is, the only one in which the command
      minibuffer is shown. I have made a mock-up (only graphics) to
      illustrate the idea:


      The other approach is to make it possible to wrap tab pages and
      windows inside each other ad libitum. This is a controversial and
      ambitious approach, as it requires major modifications, and will be
      hard to implement without breaking backwards compatibility. This
      solution is more flexible, but the question is, of course, whether or
      not it is worth the trouble.

      Buffer Locking:

      Many IDEs only allow a file to be represented once, in one tab. While
      lowering the flexibility, this encourages reusing of tabs, thus making
      it easy to navigate between and keep track of a delimited set of

      In Vim, it is pretty easy to write a set of Vim-functions, that makes
      it possible to reuse tab pages and windows when issuing commands like
      <C-]> or gf (I have done that in a couple of lines). When you issue
      the command, Vim jumps to the corresponding tab page if it exists, or
      creates one otherwise. The problem is that this approach is not
      consistent. One command that doesn't follow this scheme (quickfix for
      instance), and your window/tab page shows a wrong buffer.

      My propose is to introduce a buffer locking mechanism to prevents that
      a window switches to another buffer. It works as follows:

      - When a window is locked to a given buffer, any attempt to open a
      window containing that buffer (<C-w><C-f>, :stselect) will instead
      activate the given window.
      - A buffer which has a window locked to it may still be shown in other
      windows, but a buffer may only have one window locked to it. This
      enables working in "split window mode".
      - Any attempt to switch buffer in a locked window will instead issue
      an attempt to open the new buffer in a new window (which again may be
      caught by the first rule)
      - A window can be opened from a locked one by issuing a special prefix
      to circumvent the locking mechanism.
      - Windows opened with a new buffer can be made locked by default, so
      that the default behavior will be to reuse all buffers.

      I think everything else should be untouched by this, but more research
      should be done regarding the actual design of these proposals, so that
      we get maximum flexibility and still ensure backwards compatibility.

      About Me:

      I have used Vim since I started using Linux in 2002. Presently I use
      Vim for all sort of purposes I can think of: configuration file
      editing, XML and LaTeX document editing, mail writing from mutt,
      development in C, C++, Python; I even ponder whether to use Vim or
      Eclipse for Java development.

      I want to be honest admitting that, though I have coded a lot, I have
      not previously attended an open source project beyond fixing small
      bugs. Yet I am good at structuring and organizing projects, and I know
      the etiquette, so I don't think that will be an issue.

      I am aware that the code base is complicated, but from the snippets I
      have read of it, it seems reasonably well-documented and intuitive.
      Based upon that, I think that my proposals should be realistic to
      implement properly in the given time span.

      Actually, as I preferably use old tried-and-tested programs on my
      system, I am very focused on developing stable and clean code rather
      than fast, feature rich code. I am reasonably test oriented, and
      enthusiastic about Agile development practices.

      I strongly believe in the one-task-one-tool principle, and I must
      stress that I with my proposals do not intend to turn Vim into an IDE,
      merely to improve extendability, and to make it more convenient to
      navigate between multiple files, for those who prefer tabs.

      I hope I have given you the impression that this is something that I
      am serious about. Please ask if there is something which I have not
      expressed clearly.


      Mads Navntoft Noe

      ====== (end of application)

      I'd be glad to hear whether you think these proposals are relevant,
      and whether they appropriate for a GSoC project. If you don't, I have
      thought about these ideas:

      - Omni completion plugin for XML using XML Schema (the current
      solution only supports DTD via the dtd2vim tool). The plugin could use
      an existing XML parsing library, and perhaps try to figure out the
      schema from the documents namespace declaration.

      - Work on file type plugins in general:
      - Better XQuery support
      - Improvement of commands for navigation in the document structure,
      for instance in Python, XML and LaTeX. The latter could be done in
      cooperation with the LaTeX-suite developers.

      - Of course, I could do some debugging as well :-)

      Also, if there are something which I should elaborate on in my
      application, please let me know.


      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
    Your message has been successfully submitted and would be delivered to recipients shortly.