I am submitting an application to Vim for the Google summer of Code, I thought I'd email the mailing list to see if anyone had any thoughts on improvements to my applications. Any thoughts would be appreciated, whether negative or positive. I have plentiful experience using vim, and always thought this would be a really cool feature to add to it. I believe I have the technical expertise in how to accompish it.
Many thanks, Jonathan Frawley. ---- On-The-Fly Code Checking Proposal Proposed Organization : Vim Name : Jonathan Frawley University : Trinity College Dublin Course : Computer Science Abstract : An attempt at speeding up the edit-compile-edit cycle which plagues programmers. A good way of doing this would be an update after every line gets written or one at a predefined timeout. Once the person has corrected the error, unhighlight it. The current system for detecting errors in vim is to use quickfix, which can run through errors after compilation. It can also display a group errors using the error window. This project will focus primarily on using the existing quickfix mechanism and modifying it to display the errors as highlighted words. A similar highlighting mechanism can be seen here : http://elephant.linux.net.cn/files/vim_screenshot.png. One option would be to highlight all errors in one colour. For the first phase of the project, I shall undertake to highlight all errors in one colour. Initially the project will be a script, hopefully evolving into an automatic error highlighting system, based on time and other constraints. This phase will also include integration with quickfix to tell the programmer what the problem associated with the highlighted portion is. For the next portion of the project, I will implement a script such as the one indicated here : http://www.vim.org/scripts/script.php?script_id=479 This will enable me to give different type of syntactical errors different highlighted colours. I will then determine the feasibility of an automated system, where as the user types, the code gets automatically highlighted every few seconds. If this is possible it will be implemented along with the existing system, hopefully as different options. This project should work alongside quickfix and should be useful to all vim programmers. Background on project : The project is outlined in my abstract. Here I will elaborate on the phases I wish to achieve during the summer of code project. Timeline : April 14 - May 26 -> Getting to know Vim's code structure. Discussing the project's objectives with members of the community through the mailing list and IRC. Ensuring my vision of the project ties in closely with Vim's philosophy. Investigate the feasibility of a time-oriented updater, updating the error checking by compiling and highlighting the code repeatedly every few seconds as the user types. Research into existing IDEs such as Eclipse will be made to see how their error highlighting scheme works in detail, and see if any of these methods may be applied, to vim's new error detection system on-the-fly. May 26 - July 7 -> Programming work beginning with the goal of achieving a simple highlighting script, which highlights errors and displays information about this error when the programmer has the cursor over the highlighted section. July 7 - August 11 -> Adding in of extra elements of the project including a multi-coloured highlighting system for different types of syntactic errors. This could be done using an existing script such as "Mark" outlined here : http://www.vim.org/scripts/script.php?script_id=1238 or an new solution could be made. Once this has been finished, and if a time-oriented updater was deemed to be suitable, a time-oriented updater will be made, allowing for error checking while writing code in insert mode. Otherwise an interface for the programmer will be written, allowing them to update the error checker repeatedly using a simple command. The first part of the project will be the expansion of the quickfix system, which allows one to jump to errors. This will have to be expanded so that it highlights all errors automatically using a given command. This should be set up by the user with their compiler. For example if a user is to use vim to write a c file to be compiled using gcc: They will have to set their compiler using a command like : set makeprg=gcc\ -o\ $* as is used with quickfix. Now the user can enter in a command such as ":uperrdet" which compiles the file using default options(perhaps using a.out as a destination). Then it highlights the errors, perhaps using the "Mark" script outlined earlier or a new system, written by me and optimized for this purpose, and the programmer sees all of the errors they made, highlighted. This should be an adequate solution for debugging purposes. After this has been accomplished (Most likely well before the time outlined above, but just to be sure) I will begin work on refining the system so that there is error-dependant highlighting done, which will probably involve a script written to parse errors and return their type. For instance, if a variable is not declared, it might be highlighted in red. Also, it is hoped that it is possible to implement a system where an as-you-type system will be in place. So that as the programmer is writing their file, they will see errors and be able to change them accordingly. Once this has been finished, I will implement a system where the programmer can cycle through errors cyclically, similarly to quickfixes system. So as the user is typing and sees that they have made an error on the last line due to it being highlighted, they press [Esc] to go into Normal mode, then types something like ":errback". My script will then remember the position vim was before it was called, and then when the user types ":errret" it returns them to the cursor position they were in before they corrected the error. In this way, it would be an improvement in productivity in comparison to Eclipse's error detection system. I believe also that this is in keeping with Vim's tradition of being incredibly fast at editing. --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
