On Thu, Feb 22, 2007 at 03:19:24AM +0900, Kazunobu Kuriyama wrote: > > <snip> > > I attach a modified "c.vim" syntax file (minor changes to accommodate > > the modular structure above), and "glibc.vim", "xlib.vim" (which should > > be put inside "syntax/clibs/") to highlight functions and constants from > > glibc and xlib respectively. > > > I'm afraid this is not a good idea; c.vim should not depend on any > set of the symbols which come from the particular implementation of an > arbitrarily chosen C library. > > To be more specific, I can't see any good reason why I have to give up > highlighting many symbols such as SIGCHLD, SEEK_CUR, to name a few, > unless I use glibc.vim together with c.vim. I strongly believe that > all symbols defined in the *standard* C library must remain in c.vim. > > Also, I hardly imagine a situation where all C library symbols are > needed at a time to highlight a file in a buffer. For example, it is > annoying that some simple symbols such as y0, y1, yn, j0, j1 and jn > are highlighted even if math.h is irrelevant that file.
Well, I think that all symbols defined in the *standard* C library should be included in say "libc.vim". I unfortunately could not find any definitive list online to generate keywords from, hence I did glibc instead. Maybe a better solution would be the following: All symbols *currently* highlighted in c.vim (and maybe some other common ones) should be moved to "clibs/default.vim", and keywords from this file should be included by default. Thus Vim users should see no change when they use the supplied syntax files. And users who want more keywords to be highlighted can control this from their vimrc. > Lastly, I'm afraid that, since C library functions are so common, > highlighting them would rather kill the purposes and effects of > highlightning. I personally find highlighting all keywords and constants from glibc and Xlib very useful. And browsing through the source files I usually edit, (and the Vim source) I found library calls very sparse, and the highlighting supplied helpful. However I don't think my personal taste should be forced on others, and hence I proposed the above modular structure. This structure allows you very fine control over what is highlighted. You can choose (from ~/.vimrc) to only have Xlib function calls highlighted for instance. Once people contribute keywords from other libraries (Gtk / Qt / etc), you can do the same for those libraries. It's extremely useful if for instance you forget weather some Xlib function is called XGetWindowAttrs or XGetWindowAttributes. Also the highlighting currently supplied for glibc comes with a large list of choices. You can choose to highlight only only upper (or only lower) case constants, or constants beginning with _, or function calls, or any combination of the above. GI -- 'Common' Proof Techniques: 14. Proof by eminent authority -- "I saw Karp in the elevator and he said it was probably NP-complete."
