Many thanks for your suggestions. Yes I had a look at Flymake and it is very similar to what I envisage this project becoming. Perhaps a more lightweight, up-to-date and configurable version however. I have updated my proposal as follows, please let me know what you think, any input is very much appreciated.
Thank you very much, Jonathan. Updated : Abstract - An attempt at speeding up the edit-compile-edit cycle which plagues vim 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 simple program, hopefully evolving into an automatic error highlighting system, based on time and performance 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 integrate a script like the one shown 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. After this functionality is implemented well, an automatic updating mode will be implemented, 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 quickfix system. This project should work alongside quickfix and should be useful to all vim programmers. This combines the pure functionality a nd sheer usability of Vim with the user-friendliness of having errors highlighted on-the-fly. Edit: On some reconsideration of the problem, and some advice from a Vim developer, I will examine the possibility of having a compiler running in the background, with the code being recompiled and errors highlighted. This will be done after all of the other work has been completed. This tool will be similar to emac's "Flymake" system. In implementing this system I will examine the methods by which java and emacs accomplish this by examining the source code and talking with devlopers. It should also be noted that this tool will have to be configured by the user and will be off by default. Detailed Description - Proposed Organization : Vim Name : Jonathan Frawley University : Trinity College Dublin Course : Computer Science Year : 2nd Technical Background : I have two years of experience in all aspects of software development. During my college course so far I have developed object-oriented software systems in java. I have also done numeroussolo systems programming exercises in C and C+ +. I am also familiar with other programming languages such as Eiffel and more low level languages like 68k assembly, intel assembly. Extensive knowledge of hardware, including VHDL modelling and synthesis of microprocessor system design. Open source software is a hobby of mine, I use vim on my laptop where I have xubuntu installed, as well as in college. I use gcc for compilation on c projects mostly and g++ for my c++ projects. I am a co-founding member of two small open-source projects, one is an agent platform for mobile phones written in java, another is a 3D car game which is written in C++ and uses the irrlicht, newton and irrklang open-source projects. Please visit my homepage for more information : netsoc.tcd.ie/~df3n5 Why me? For me, this project presents several opportunities. Firstly, it lets me contribute to the most consistently useful program I have ever used. Secondly it lets me hone my skills as a systems programmer. In my computer science degree, I used vim extensively in developing programs for assignments and for fun. I have plentiful experience with vim, pico, nano, Visual Studio, eclipse, code::blocks and various other editors and IDEs. With this knowledge and my 2 years of experience working with C and C+ +, I believe that I am the ideal person to do this project. All in all, given the opportunity to work for Vim, I would work tirelessly for the summer to ensure I produce something which is of worth to programmers in everyday usage. I believe, with your support, I can contribute a lot to Vim. 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 on-the-fly error detection system. 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. My research so far has shown that it will be a valuable tool, which need to be tweaked and possibly parts rewritten for performance enhancments. 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 before it is used, it might be highlighted in red. The error detection scheme will be handled in the initial stage by quickfix or a variant of it. 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. Overall I believe that this project is very interesting, I would love for this to exist in Vim, and would love even more to be the one to implement it. Thanks for your time. Edit : On-the-fly code checking is a reality in Emacs due to flymake. A tool tailored around vim should accomplish this in a similar fashion, perhaps with a small window at the bottom of the current screen which gets updated with the number of errors/warnings/etc. Once the programmer puts the cursor over the error the window would display information about the error and possibly how it might be resolved. The system will first have to determine whether a check is possible, then it would handle the parsing of the file, the includes. After this it would create a temporary compilation of the file, parse the output from the error checking that the compiler outputs and then give that message to the user once they are on the error. Emacs flycheck is quite heavy on processing power so the main aim of this project will be to create a fast, lightweight tool which detects errors, highlights them and displays information about them to the user. Thanks to devloper AP for the information on flycheck. More information can be found here : http://flymake.sourceforge.net/ This feature is intended to be an add on for programmers who use vim heavily in their development on higher end machines, and will have to be enabled by some option, just like quickfix is. Thanks to Tony for his input on this matter. On Mar 30, 11:50 pm, "A.Politz" <[EMAIL PROTECTED]> wrote: > Jonathan Frawley wrote: > > [...] > > > ---- > > > 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... > > [...] > > The highlighting is not really the problem. The next paragraph is an > excerpt from the emacs info page. I think it sums it pretty much up, > what this is about. > > "Flymake is a universal on-the-fly syntax checker implemented as an > Emacs minor mode. Flymake runs the pre-configured syntax check tool > (compiler for C++ files, `perl' for perl files, etc.) in the > background, passing it a temporary copy of the current buffer, and > parses the output for known error/warning message patterns. Flymake > then highlights erroneous lines (i.e. lines for which at least one > error or warning has been reported by the syntax check tool), and > displays an overall buffer status in the mode line. Status information > displayed by Flymake contains total number of errors and warnings > reported for the buffer during the last syntax check." > > I think this stands or falls with the ability to have vim run > a compiler in the background, because nobody would use it, if > they had to pause editing in order to wait for the tool to check > the syntax. > Next question would be, when to invoke this checks and if existing > mechanisms could/should be used. > > Maybe the emacs manual would be a good further read ( and the code, if > you understand lisp ) because it is fairly general implemented (as > opposed to eclipse (?) ). > > Note:That's just my opinion, I have nothing to decide here. > > -ap --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
