On Thu, Feb 22, 2007 at 07:39:50AM +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. > > > I guess you could easily find someone around you who has a standard C > library reference. Can't you borrow one from a public library or > somewhere else, if not online...
Theres no way I'm going to type in by hand all standard C keywords. If I can generate it easily from an online reference, I'll do that. I couldn't, so I did glibc from the info page 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. > > > > It would be better to take into consideration those who source the > current c.vim in their vim scripts. Are you sure that your proposed > modularization scheme give little or no harm to such user scripts? > It's not obvious to me. What's your prospect? Yes. Read the modification. All it does is define one new cluster, and include all files in the syntax/clibs directory PROVIDED some Vim variables are defined. If those variables are not defined, the syntax/clibs files are ignored, and c.vim should behave as it did earlier. (The commented out symbols you pointed out in your previous message will be added to a stdc.vim soon). > > > 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. > > > But once your syntax files are included in run time, poor users have > to either follow your taste all along or reject it completely. Why not > give them a middle ground? The proposed structure will surely give > such flexibility as you claim, but I don't feel the syntax files you > have proposed are written in such a way that they actually comply with > your claim. Have you read the attached syntax files? They do exactly what I claimed. (Read glibc.vim with fdm=marker, and you will see). > I still don't understand why familiar C library function calls ought > to catch our eyes; it could be sometimes sort of distraction for some > people. > > > 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. > > > I don't think this is the right purpose of highlighting. It would be > sometimes extremely harmful as much. If there are two or more similar > names, you can't tell one from others only by highlighting. If it > should pass compilation, you would surely get extremely frustrated to > spot a bug, because you would wrongly keep believing you had chosen > the right name. > > > 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. > > > I rather want to highlight something I need to pay attention to. It doesn't > matter and has nothing to do with my concern whether a symbol is made up of > upper case letters or lower ones or beginning with a underscore. I don't > understand how the choices mentioned above make coding efficient, though I > admit it makes hightlighting fancier. If you don't like it, you wont have to use it. If the (previously attached) files are included in Vims runtime, they wont take effect unless you explicitly request it in ~/.vimrc. I find the above useful, and think it makes my coding more efficient. You don't. A matter of opinion like this usually has no "right" answer, and different people have different tastes. There's an option by which users who find it useful can use it, and those who don't find it useful need not use it. Freedom of choice is best, GI -- VI VI VI The editor of the beast.
