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
