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



Reply via email to