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.
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.
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.
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
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
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.
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.
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
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