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 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: http://www.daimi.au.dk/~u071450/GSoC/vim-glob-win.png 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 files. 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. Sincerely, 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. Cheers, Mads --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
