On 13/05/10 11:54, mobi phil wrote:
/*
* Version of strchr() and strrchr() that handle unsigned char strings
* with characters from 128 to 255 correctly. It also doesn't return a
* pointer to the NUL at the end of the string.
*/
char_u *
vim_strchr(string, c)
char_u *string;
int c;
{
char_u *p;
int b;
p = string;
#ifdef FEAT_MBYTE
if (enc_utf8&& c>= 0x80)
{
--->8---
etc.
Well, honestly, what percentage of C programmers are using the "old
style" function declaration?
I'd say at least all those who peruse the Vim source, even if only
occasionally, and even if read-only.
Of course if you want to do something and
you want to cover all possible cases, you end up never doing that
thing... I think vim should concentrate on evolution and not on
supporting very old things. If it would happen that somebody
exceptionally needs very old features, then he/she could fire up an
old version of the tool...
In case you hadn't noticed, vim has always concentrated on portability
and compatibility, including most especially long-range backward
compatibility (which also mean stability: with that policy in force as
strongly in the future as Bram has been known to enforce it in the past,
Vim plugins written today have a good chance of being still usable with
whatever Vim will be in 2025). IMHO the fact that "section" motions [[
]] [] ][ never find a brace if it isn't in the first column is a
(slight) compatibility flaw considering some of the "modern" coding
styles where the opening brace of a function block is on the same line
as the function declaration. That characteristic of [[ etc. doesn't
hamper much if you use a "coding style" where your braces are always on
their own line, as Bram does, or at least if your top-level _closing_
braces are, in which case you can highlight the block with ][v% thus
leaving the cursor on the opening brace: if there is a comment (one
C-style comment, not several lines of C++-style comments) just before
the function, ?\/\*?+0 will add it (including the whitespace before it
on its fist line) to the Visual area. But you may need to repeat the
search-back (using n or maybe n0 ) if there are comments describing the
parameters as in the example in the help:
/*
* comment
* describing
* the function
*/
int
foobar(arg1, arg2)
int arg1; /* description of arg1 */
int arg2; /* description of arg2 */
{
int local1; /* description of local1 */
etc.
or even, with a somewhat more "modern" coding style:
/******************
* comment *
* describing *
* the function *
******************/
int foobar(int arg1, int arg2)
/* arg1: (description) */
/* arg2: (description) */
{
int local1; /* description */
etc.
So, with the "contemporary version" of C declaration, the trivial algo
I mentioned should work..
However you made a good point with your example, as I did not think
that comments before a function definition normally belong to the
function, so they should be part of the function text object...
rgrds,
mobi phil
being mobile, but including technology
http://mobiphil.com
Best regards,
Tony.
--
"Life would be much simpler and things would get done much faster if it
weren't for other people"
-- Blore
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
