textobjects extension

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

textobjects extension

mobi phil
Hello,


I think it would make enough sense to extend the "textobjects" with
"af" that would select a function, that is its name, formal parameters
and the body. One could write a script for it, I know, but the same
time hundreds of mappings should be defined (d, v, y etc. etc.). I
think all programmers manipulate functions (move arround in source
text, duplicate etc. etc.)

What is your opinion?



rgrds,
mobi phil

being mobile, but including technology
http://mobiphil.com

--
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
Reply | Threaded
Open this post in threaded view
|

Re: textobjects extension

Antony Scriven-3
On 14 March 2010 13:53, mobi phil <[hidden email]> wrote:

 > I think it would make enough sense to extend the
 > "textobjects" with "af" that would select a function,
 > [...]

Define 'a function'. --Antony

--
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
Reply | Threaded
Open this post in threaded view
|

Re: textobjects extension

mobi phil
Thank you Antony, however I forgot to say, "... no need to answer
write a function etc..., as I know about that " :)

was wondering if other vim users would find sthg. like that usefull,
and, if smbd. would know about such a script...





On Sun, Mar 14, 2010 at 6:26 PM, Antony Scriven <[hidden email]> wrote:

> On 14 March 2010 13:53, mobi phil <[hidden email]> wrote:
>
>  > I think it would make enough sense to extend the
>  > "textobjects" with "af" that would select a function,
>  > [...]
>
> Define 'a function'. --Antony
>
> --
> 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
>



--
rgrds,
mobi phil

being mobile, but including technology
http://mobiphil.com

--
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
Reply | Threaded
Open this post in threaded view
|

Re: textobjects extension

Jürgen Krämer-4

Hi,

[quoting re-ordered, please bottom-post

mobi phil wrote:

>
> On Sun, Mar 14, 2010 at 6:26 PM, Antony Scriven <[hidden email]> wrote:
>> On 14 March 2010 13:53, mobi phil <[hidden email]> wrote:
>>
>>  > I think it would make enough sense to extend the
>>  > "textobjects" with "af" that would select a function,
>>  > [...]
>>
>> Define 'a function'. --Antony
>
> Thank you Antony, however I forgot to say, "... no need to answer
> write a function etc..., as I know about that " :)

I think what Antony wanted to say is: What do you understand by 'a
function'? How can it be identified in text?

IMHO a function is such a highly language-dependent construct that a
definition for a corresponding text object can not be easily described
by a single flag or even some parameters and that it is best put inside
a filetype plugin where you can make use of Vim's scripting language,
e.g., by defining expressions for start and end of a function or for the
whole body.

Regards,
Jürgen

--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us.     (Calvin)

--
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
Reply | Threaded
Open this post in threaded view
|

Re: textobjects extension

mobi phil
> I think what Antony wanted to say is: What do you understand by 'a
> function'? How can it be identified in text?
>
> IMHO a function is such a highly language-dependent construct that a
> definition for a corresponding text object can not be easily described
> by a single flag or even some parameters and that it is best put inside
> a filetype plugin where you can make use of Vim's scripting language,
> e.g., by defining expressions for start and end of a function or for the
> whole body.
>
> Regards,
> Jürgen

Sorry... Indeed Antony wrote "define". It seems that I wanted so much
not to read that "write a function" :)

Vim is and was primarily c and c++ programmers editor, and lots of
features are tuned for c.

* Without going deep into c's (or C++'s) grammar I think by starting
backwards to search for an opening "{" that has no ";" before it.
* The statement before it can be only a function definition or
while/for/if/switch statement. If we found a statement keep going
backwards.
* If we found a function header we do our best to find the full header
(ret type, name , formal params)
* After the opening "{" was found, use existing algo to find its pair.

Such an algo should work with C, C++, java, php, javascript, etc. etc.


So.. nobody moves functions around? Just reordering time to time,
based on logical groups etc... would make sense... and with such a
selection tool, job would be easier :)

rgrds,
mobi phil

being mobile, but including technology
http://mobiphil.com

--
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
Reply | Threaded
Open this post in threaded view
|

Re: textobjects extension

Kana Natsuno
In reply to this post by mobi phil
On Sun, 14 Mar 2010 22:53:57 +0900, mobi phil <[hidden email]> wrote:
> I think it would make enough sense to extend the "textobjects" with
> "af" that would select a function, that is its name, formal parameters
> and the body. One could write a script for it, I know, but the same
> time hundreds of mappings should be defined (d, v, y etc. etc.). I
> think all programmers manipulate functions (move arround in source
> text, duplicate etc. etc.)
>
> What is your opinion?

Did you mean: http://www.vim.org/scripts/script.php?script_id=2619
Though it should be polished further.


--
To Vim, or not to Vim.
http://whileimautomaton.net/

--
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
Reply | Threaded
Open this post in threaded view
|

Re: textobjects extension

Benjamin Fritz
In reply to this post by mobi phil


On Mar 15, 4:39 am, mobi phil <[hidden email]> wrote:
>
> Sorry... Indeed Antony wrote "define". It seems that I wanted so much
> not to read that "write a function" :)
>
> Vim is and was primarily c and c++ programmers editor, and lots of
> features are tuned for c.
>

My "a function" text object for C code:

[[vaB

--
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
Reply | Threaded
Open this post in threaded view
|

Re: textobjects extension

Benjamin Fritz


On Mar 15, 8:56 am, Ben Fritz <[hidden email]> wrote:
>
> My "a function" text object for C code:
>
> [[vaB

...which of course will only work if your coding style places '{' at
the beginning of a new line, and could more easily be written [[v% in
most cases.

I must need some more coffee this morning. Sorry for the flippant
response. My point was, in Vim it probably only takes a few extra
keystrokes, with built-in functionality, to get exactly what you want
in this case.

--
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
Reply | Threaded
Open this post in threaded view
|

Re: textobjects extension

mobi phil
thanks,

* both examples are rather obvious, but they do not select the functions header.
* Ben: in what you proposed, [[ jumps to the wrong position if "{" is
not in the first colum, so both "[[%v" and "[[aB" do the job only if
"{" is in the first position
* this tells me that "[[" is less useful in most of the cases in programming
* [[ does not work well with C++ code or potentially java (nested functios)
* now I am thinking that this "af" (and eventually text motion
counterpart)  would make sense for structs, classes, and
for/while/switch blocks as well...

--
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
Reply | Threaded
Open this post in threaded view
|

Re: textobjects extension

mobi phil
In reply to this post by Kana Natsuno
That sounds good... will try out. Maybe adding what I was mentioning
in my prev email, would make sense ( select class, struct,
while/if/switch blocks together with their header)

--
rgrds,
mobi phil

being mobile, but including technology
http://mobiphil.com

--
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
Reply | Threaded
Open this post in threaded view
|

Re: textobjects extension

mobi phil
In reply to this post by Kana Natsuno
> Did you mean: http://www.vim.org/scripts/script.php?script_id=2619
> Though it should be polished further.

sorry... in my prev email I removed the quote, so it was not obvious,
what my answer reffers to

That sounds good... will try out. Maybe adding what I was mentioning
in my prev email, would make sense ( select class, struct,
while/if/switch blocks together with their header)

--
rgrds,
mobi phil

being mobile, but including technology
http://mobiphil.com

--
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
Reply | Threaded
Open this post in threaded view
|

Re: textobjects extension

Tony Mechelynck
In reply to this post by mobi phil
On 15/03/10 10:39, mobi phil wrote:

>> I think what Antony wanted to say is: What do you understand by 'a
>> function'? How can it be identified in text?
>>
>> IMHO a function is such a highly language-dependent construct that a
>> definition for a corresponding text object can not be easily described
>> by a single flag or even some parameters and that it is best put inside
>> a filetype plugin where you can make use of Vim's scripting language,
>> e.g., by defining expressions for start and end of a function or for the
>> whole body.
>>
>> Regards,
>> Jürgen
>
> Sorry... Indeed Antony wrote "define". It seems that I wanted so much
> not to read that "write a function" :)
>
> Vim is and was primarily c and c++ programmers editor, and lots of
> features are tuned for c.
>
> * Without going deep into c's (or C++'s) grammar I think by starting
> backwards to search for an opening "{" that has no ";" before it.
> * The statement before it can be only a function definition or
> while/for/if/switch statement. If we found a statement keep going
> backwards.
> * If we found a function header we do our best to find the full header
> (ret type, name , formal params)
> * After the opening "{" was found, use existing algo to find its pair.
>
> Such an algo should work with C, C++, java, php, javascript, etc. etc.
>
>
> So.. nobody moves functions around? Just reordering time to time,
> based on logical groups etc... would make sense... and with such a
> selection tool, job would be easier :)
>
> rgrds,
> mobi phil
>
> being mobile, but including technology
> http://mobiphil.com
>

Well, OK, so let's take a look at a typical function. It starts like this:

---8<---

/*
  * 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.

Of course you would want to include the type declaration "char_u  *"
which is on a different line, and the comment before that. (Vim source,
src/misc2.c lines 1795 sqq.). Notice that the starting brace of the
function body _is_ preceded by a semicolon, while the true-block of the
if inside the #ifdef isn't. (See also at the end of ":help style-examples".)

I think this should be handled by ad-hoc vimscript, probably as an
operator-pending mapping with an <expr> argument calling a function.


Best regards,
Tony.
--
"Apathy is not the problem, it's the solution"

--
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
Reply | Threaded
Open this post in threaded view
|

Re: textobjects extension

mobi phil
> /*
>  * 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? 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...

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

--
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
Reply | Threaded
Open this post in threaded view
|

Re: textobjects extension

Tony Mechelynck
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