Bram Moolenaar wrote: > Birgi Tamersoy wrote: > > >> Hey everybody, >> >> Apparently many students (like me) are interested in this project. So, >> I decided to start a new thread where we can talk about the challenges >> in the project and how to solve them. I went over previous posts to >> include all the related ideas in this new thread. >> > > Thanks for starting this discussion. > > >> Here are a few initial thoughts about the project: >> >> I think *speed* is one of the major concerns. Basically, editing speed >> should not be affected at all by the code checker. >> >> Running a compiler in the background with a temporary copy of the >> code, parsing the error messages and highlighting the related parts is >> one of the intuitive solutions (which is also implemented in Emacs >> Flymake). Although this is a to-the-point solution it will be quite >> slow according to your project size. >> >> *Incremental compiling* can be used to enhance this method. Rather >> than compiling the whole code every time, the checker can compile only >> the necessary parts. Right now, I don't know if this is supported by >> the majority of the compilers or the interpreters. >> >> Using a *built-in parser* is solution emphasized by Charles E. >> Campbell Jr in a related post. A parser would be perfect for syntax- >> checking, but I think the code checker should also detect errors like >> a misspelled library name. >> > > In my opinion the errors and warnings that are highlighted must be 99% > correct. It's very annoying if you get an error for something that is > not wrong, or compiling fails with an error but the error was not > highlighted. I don't think that a built-in parser will be able to reach > this accuracy, except perhaps for some simple languages. >
There are yacc grammars available for several languages, including C, Matlab, and Lisp. The advantage of this approach is similar to the advantage of the syntax highlighting engine; its not particularly tied to any language. I mostly program in C/Matlab myself, but I know there's plenty of other languages and users out there (python, perl, sh/csh/ksh/zsh/tcsh/..., java, lisp, scheme, ada, matlab, ... apologies to those folks for whom I've missed mentioning their favorites) and tying a major feature of vim to one or two languages is probably not going to be universally appreciated. What I was advocating was the ability to use LALR grammars (read: yacc/bison) so that vim isn't tied to a particular language and, in fact, can be extended to cover future languages. The primary disadvantage is that effectively writing a new yacc/bison is not a small task. I have a real thick book about writing a yacc-like parser somewhere; if anyone's interested, I could look up its ISBN. Probably one could set up pipes to an external yacc or bison and avoid that problem, but that introduces the "external sort" type of problems people have had until vimgrep. If, in fact, a LALR parser is embedded a future GSOC would involve using it to do more accurate syntax highlighting. To support C++ and other object oriented languages would also involve symbol table handling. Sounds like a huge project to me to make it truly generic. I'm not sure I would like it; especially if I got yammered at for incomplete code. Regards, Chip Campbell --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
