Re: Highlighting keywords from C libraries
* Gautam Iyer gautam@ [070222 11:42]: Anyways, following suggestions from this thread I made the following modifications: Well, I'd also suggested to split it to many different files: syntax/c.vim syntax/c/ansi.vim syntax/c/susv3.vim syntax/c/xlib.vim ... with something like if !exists(b:c_syntax_use_XXX) !exists(g:c_syntax_use_XXX) finish endif at the very start. And source it from main c.vim. So I can add my own symbol highlighting without having to hack this big and complex c.vim... -- Regards, Sir Raorn. signature.asc Description: Digital signature
Re: Highlighting keywords from C libraries
Gautam Iyer wrote: On Thu, Feb 22, 2007 at 01:47:07AM +0300, Alexey I. Froloff wrote: I find it useful to have standard functions and constants in C libraries highlighted. I attach syntax files for this purpose. Check out the std_c syntax, http://www.eandem.co.uk/mrw/vim/syntax/ I tried using this. It unfortunately doesn't define all std C items :(. The comments in this file said it could not be used as a drop in replacement for the default c.vim, so I didn't modify this. Anyways, following suggestions from this thread I made the following modifications: 1. Updated to use the most recent version of c.vim I could find. 2. If c_hi_identifiers is not defined, then the attached c.vim behaves exactly like the c.vim supplied with Vim. 3. I made c_hi_libs a List of libraries for which you want keywords to be highlighted. I chose to change to a list because in the unlikely event you have hundreds and hundreds of syntax files in the clibs directory, only the ones you want will be loaded. I also made c_hi_libs a buffer local variable, so that you can easily set it to include project specific keywords, or select a set of libraries based on the project. Again, by default users should not see any change. And users can get fine control of what they want highlighted from ~/.vimrc. Bram -- If you think it would be more useful to upload it on Vim.org as opposed to including in Vim, let me know. As it's currently not really clear what the best choice is for the distributed runtime files, please upload your script to the Vim website. My personal preference is to only highlight things that are part of the language. Whether items in the standard C library are part of the language or not is already a discussion. What standard means in this context is certainly debatable. -- Very funny, Scotty. Now beam down my clothes. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Highlighting keywords from C libraries
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.
Re: Highlighting keywords from C libraries
On Wed, Feb 21, 2007 at 10:07:22AM -0600, Bill McCarthy wrote: I find it useful to have standard functions and constants in C libraries highlighted. I attach syntax files for this purpose. This is a nice addition that I would like to see included. I noticed that you patched c.vim against an older version. The current version is dated Feb 13, 2007. Sorry. I did this sometime last year, and completely forgot about it. After seeing Bram at Google, and the video of his talk yesterday I got reminded and sent it off to the list. If it looks like it's going to be included with Vim, I'll of course update to the latest version and write appropriate documentation. GI -- An Apple a day, keeps Windows away.
Re: Highlighting keywords from C libraries
On 2/21/07, Gautam Iyer [EMAIL PROTECTED] wrote: 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. Reasonable. 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. Yes, this is appreciated, because I personally think that having too much highlighting goes against the purpose of highlighting - hey, the default highlighting is to highlight everything in the same color (black) and it works a lot better than having everything highlighted as green, red, blue, orange, yellow, black, magenta, I'm not the right person to say anything here, because my syntax definitions tend to highlight basically everything, but I've gone more and more to defining syntaxes where people can highlight anything they want, but keep the default set of highlights sparse. nikolai
Re: Highlighting keywords from C libraries
Gautam Iyer wrote: 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. 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... 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? 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. 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. Thanks, - KK
Re: Highlighting keywords from C libraries
* Gautam Iyer gautam@ [070221 12:17]: I find it useful to have standard functions and constants in C libraries highlighted. I attach syntax files for this purpose. Check out the std_c syntax, http://www.eandem.co.uk/mrw/vim/syntax/ -- Regards, Sir Raorn. signature.asc Description: Digital signature
Re: Highlighting keywords from C libraries
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
Re: Highlighting keywords from C libraries
Since projects won't have as many keywords as glibc, the only slow down will be with the syntax file (re)generation. ctags is reasonably fast Sorry. I haven't read your message thoroughly enough. I was talking about what you've written in your comment. /me hides ;) Marc
Re: Highlighting keywords from C libraries
Gautam Iyer wrote: snip 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. As you know, glibc borrows a great number of symbols from a bunch of the existing C library specifications such as POSIX, SVID, BSD, XOpen, and so on. Also, there're a number of symbols peculiar to GNU. Do you think people want to come across SIGCLD and SIGCHLD which are equally highlighted due to your reluctance in manual labor? What answer do you have for those who want to highlight only symbols complying with their libc? I think a decent stragey calls for some division, e.g., stdc.vim - collection of symbols commonly defined in any kind of the libc specifications. (I respectfully borrows the name from what you wrote below.) svid.vim - collection of symbols peculiar to SVID. bsd.vim - collection of symbols peculiar to BSD. ... xxx.vim - collection of symbols peculiar to the specification XXX. And then you offer some flags in order to let the user choose which specifications she/he wants to use. It is highly likely that gnu.vim is a short script invoking stdc.vim svid.vim, bsd.vim and other (UNIX variants.).vim. snip 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). I did read it. This is a baseless accusation. As you pointed out, my point is in the parentheses above. How come you could say as if I were lazy? It was my careful examination of your scripts that enabled me to point out the problem. If you don't want it, tell me, I'll quit. snip Have you read the attached syntax files? They do exactly what I claimed. (Read glibc.vim with fdm=marker, and you will see). Well, I would like to read this comment after you have done with what you call stdc.vim. Till then, we will never see it. snip 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, That's it. But what you actually did was to arbitrarily modify and break the original c.vim in favor of your preference. You deprived me of that freedom, didn't you? How dare you speak to me that way? You should have come up with a set of rewritten scripts and showed me how your scripts were as nice as you claimed before challenging my voluntary efferts for you. So long as c.vim works as it is, I don't care about what you are doing. GI
