Functions with [range] do not preserve the cursor line

[So8res]

I think functions with [range] should preserve the cursor line. Assume you have:

function RangeTest() range
echo line('.')
endfunction

And you put the cursor on line 2 and :%call RangeTest()

This function will echo 1, because the cursor is moved to the beginning of the range *before* entering the function.

I was attempting to create a function which does a search-replace (:s) without moving the cursor (using winsaveview() and winrestview()). It turns out this is not possible, because the cursor is moved before winsaveview() can be called.

Is this the intended behavior, or is it a bug? If it's intended, is there a way to save the winview before entering a function with [range]?

[Andy Wokula]

Am 19.11.2012 22:52, schrieb So8res:
> I think functions with [range] should preserve the cursor line.

Don't break scripts that count on this.

Example: remove trailing white space in range (default `%'), keeping
cursor position, last search pattern etc.

:no <Leader>ss :v/^-- $/s/\s\+$//e<C-B>KeepView InFunc! <C-E>
:ou <Leader>ss|sunm <Leader>ss
" final <CR> could be added

for :KeepView and :InFunc, see
http://vim.sourceforge.net/scripts/script.php?script_id=3800

:KeepView does winsaveview() and winrestview()
:InFunc does no more than executing the argument within a function
to make use of :h function-search-undo

You can insert any other command instead of
v/^-- $/s/\s\+$//e
that accepts a range.

--
Andy

[Andy Wokula]

Am 19.11.2012 22:52, schrieb So8res:

One more hint: when you call that function from a mapping and you want a
default range of `%', try the following:

cno <expr> <SID>% getcmdpos()==1 ? "%" : ""

" remove trailing ^M
no <script> <Leader>sm :<SID>%InFunc s/\r$//e<C-B>KeepView <C-E>
ou <Leader>sm|sunm <Leader>sm

--
Andy

[Nate Soares]

That's a nifty command and mapping, but I had no trouble with getting a custom command to use the range correctly. (You can just use -range, pass <line1> and <line2> to the function, and have the function do winsaveview() and winrestview(), which is what I do now.)

Then you can also default to the whole file much cleaner e.g. with -range=%. But I'm not trying to write a command, I'm trying to write a function.

The question is, is there any way to do this in a function that takes a range, called like:

%call SomeUniformApiFunction()

I'm not struggling to get the functionality, I'm struggling to expose a sane (function) API for the functionality.

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

[Andy Wokula]

Am 20.11.2012 01:29, schrieb Nate Soares:
> That's a nifty command and mapping, but I had no trouble with getting a
> custom command to use the range correctly. (You can just use -range, pass
> <line1> and <line2> to the function, and have the function do winsaveview()
> and winrestview(), which is what I do now.)
>
> Then you can also default to the whole file much cleaner e.g. with
> -range=%. But I'm not trying to write a command, I'm trying to write a
> function.
>
> The question is, is there any way to do this in a function that takes a
> range, called like:
>
> %call SomeUniformApiFunction()
>
> I'm not struggling to get the functionality, I'm struggling to expose a
> sane (function) API for the functionality.

You have to do it outside.
Prepend :KeepView or surround the :call with your own code.
(own code works better with script-local functions).

--
Andy

[Christian Brabandt]

I also stumbled over this behaviour in my csv plugin. I think this is
documented somewhere, but can't find it currently. What I usually do,
is either surround the call to the function by
winsaveview()/winrestview() calls. But this gets ugly when mappings
thing so I instead simply call the function without a range but have
the function take 2 extra arguments for the range.

regards,
Christian

[Ingo Karkat]

On 20-Nov-12 07:58:05 +0100, Christian Brabandt wrote:

> On Mon, November 19, 2012 22:52, So8res wrote:
>> I think functions with [range] should preserve the cursor line. Assume you
>> have:
>>
>> function RangeTest() range
>> echo line('.')
>> endfunction
>>
>> And you put the cursor on line 2 and :%call RangeTest()
>>
>> This function will echo 1, because the cursor is moved to the beginning of
>> the range *before* entering the function.
>>
>> I was attempting to create a function which does a search-replace (:s)
>> without moving the cursor (using winsaveview() and winrestview()). It
>> turns out this is not possible, because the cursor is moved before
>> winsaveview() can be called.
>>
>> Is this the intended behavior, or is it a bug? If it's intended, is there
>> a way to save the winview before entering a function with [range]?
>
> I also stumbled over this behaviour in my csv plugin. I think this is
> documented somewhere, but can't find it currently.

It is not (yet) documented at :help a:firstline, and "the function is expected
to take care of a range itself" would suggest that no automatic cursor placement
is done. I have also encountered this peculiarity when writing custom mappings,
too, and would be in favor of changing the behavior, as I would guess that few
to none plugins rely on that.

> What I usually do, is either surround the call to the function by
> winsaveview()/winrestview() calls. But this gets ugly when mappings
> thing so I instead simply call the function without a range but have
> the function take 2 extra arguments for the range.

I omit the range attribute on the function and explicitly pass the range
in:
#v+
function! s:Foo( firstLine, lastLine )
...
endfunction
command! -range=% Foo call <SID>Foo(<line1>,<line2>)
#v-

-- regards, ingo

[Christian Brabandt]

On Tue, November 20, 2012 17:46, Ingo Karkat wrote:
> I omit the range attribute on the function and explicitly pass the range
> in:
> #v+
> function! s:Foo( firstLine, lastLine )
> ...
> endfunction
> command! -range=% Foo call <SID>Foo(<line1>,<line2>)
> #v-

Yes, that was what I meant initially.

regards,
Christian

[Nate Soares]

I also believe that the behavior should be changed. As Ingo pointed out, the documentation is ambiguous and if anything implies that the cursor should *not* be moved on functions with [range].

I doubt there are any plugins which depend upon this bug, and there is at least one (mine) which is hindered by it.

As of now the functionality can be emulated with a command, but there is no way to create a function with [range] which saves and restores the view. That is a serious drawback.

[Andy Wokula]

Am 20.11.2012 17:46, schrieb Ingo Karkat:
>> I also stumbled over this behaviour in my csv plugin. I think this is
>> documented somewhere, but can't find it currently.
>
> It is not (yet) documented at :help a:firstline, and "the function is expected
> to take care of a range itself"

Please, no un-feature requests.
:h :call

,----
| Call a function. The name of the function and its arguments
| are as specified with |:function|. Up to 20 arguments can be
| used. The returned value is discarded.
| Without a range and for functions that accept a range, the
| function is called once. When a range is given the cursor is
| positioned at the start of the first line before executing the
| function.
| When a range is given and the function doesn't handle it
| itself, the function is executed for each line in the range,
| with the cursor in the first column of that line. The cursor
| is left at the last line (possibly moved by the last function
| call). The arguments are re-evaluated for each line. Thus
| this works:
`----

--
Andy

[Andy Wokula]

That works pretty well (for hidden implementation (<sid>Name() etc)
functions).
Just don't use this for a (global) function that can be used
(interactively) at the cmdline ... it's impractical for the user to pass
a range then.

--
Andy

[Nate Soares]

In that case I'd like to make a feature request for a way to handle functions with ranges without moving the cursor. My suggestion would be adding a [save] argument to :function which calls winsaveview() before entering and winrestview() after exiting the function, as this has potential applications beyond just [range] functions.

Thoughts on the proposed api?

[Ingo Karkat]

On 20-Nov-12 20:14:08 +0100, Nate Soares wrote:

> In that case I'd like to make a feature request for a way to handle functions
> with ranges without moving the cursor. My suggestion would be adding a [save]
> argument to :function which calls winsaveview() before entering and
> winrestview() after exiting the function, as this has potential applications
> beyond just [range] functions.
>
> Thoughts on the proposed api?

That might be a good compromise. Even though nobody has so far come up with a
use case for the current, impractical behavior, Bram is (rightly) very concerned
about preserving behavior.

Though I have no experience with this, I guess this argument (I'd call it
[keepview]) could be implemented without many lines of code and effort.

-- regards, ingo

PS: Please bottom-post on this list.

[Andy Wokula]

Am 20.11.2012 20:14, schrieb Nate Soares:
> In that case I'd like to make a feature request for a way to handle
> functions with ranges without moving the cursor. My suggestion would be
> adding a [save] argument to :function which calls winsaveview() before
> entering and winrestview() after exiting the function, as this has
> potential applications beyond just [range] functions.
>
> Thoughts on the proposed api?

Could you say more on your use case?

Earlier you said mappings are not involved -- it should be easy to pass
line numbers as function arguments ... but you don't want that -- why?

Why can't you just surround winsaveview()/winrestview()?

Normally, winsaveview()/winrestview() is only done once, at the top-level ...
why introducing more unnecessary winsaveview()/winrestview() actions
with nested function calls?

What's wrong with :KeepView (btw, it's prepared for nesting)?

--
Andy

[Ingo Karkat]

On 21-Nov-12 10:18:01 +0100, Andy Wokula wrote:

> Am 20.11.2012 20:14, schrieb Nate Soares:
>> In that case I'd like to make a feature request for a way to handle
>> functions with ranges without moving the cursor. My suggestion would be
>> adding a [save] argument to :function which calls winsaveview() before
>> entering and winrestview() after exiting the function, as this has
>> potential applications beyond just [range] functions.
>>
>> Thoughts on the proposed api?
>
> Could you say more on your use case?
>
> Earlier you said mappings are not involved -- it should be easy to pass
> line numbers as function arguments ... but you don't want that -- why?
>
> Why can't you just surround winsaveview()/winrestview()?

Christian, Nate, and I have all struggled with the current behavior of [range]
(and the documentation didn't help). Though the issue can be worked around (e.g.
with winsaveview()), maybe changing the behavior or introducing a new special
function argument would make this easier in the future.

> [3 lines deleted]

> What's wrong with :KeepView (btw, it's prepared for nesting)?

I like your utility library (though the generic "plugin/cmds.vim" script is
prone to naming clashes), but as a plugin writer I wouldn't consider adding a
dependency to it just for this little piece of functionality.

-- regards, ingo

[Andy Wokula]

Am 21.11.2012 09:05, schrieb Ingo Karkat:
> On 20-Nov-12 20:14:08 +0100, Nate Soares wrote:
>
>> In that case I'd like to make a feature request for a way to handle
>> functions with ranges without moving the cursor. My suggestion would
>> be adding a [save] argument to :function which calls winsaveview()
>> before entering and winrestview() after exiting the function, as this
>> has potential applications beyond just [range] functions.

Compared to the invocation of user commands with a range:

Alright, when one defines a user command with `-range', the cursor
doesn't move:

:com! -bar -range TestRangeCursor :echo "Range: <line1>,<line2>"
:%TestRangeCursor

There are also several Ex-commands that don't move:
:foldopen, :=, :z, :yank, ...

Others move although they don't operate on the range:
:list, :print, ...

>> Thoughts on the proposed api?

> That might be a good compromise. Even though nobody has so far come up
> with a use case for the current, impractical behavior, Bram is
> (rightly) very concerned about preserving behavior.
>
> Though I have no experience with this, I guess this argument (I'd call
> it [keepview]) could be implemented without many lines of code and
> effort.
>
> -- regards, ingo
>
> PS: Please bottom-post on this list.

Somehow I don't like `keepview', it does too much.

What about a function modifier (next to `range') that just prevents
cursor movement? No idea for a good name yet:
dontmove
keeppos
stay

func! MyFunc() range stay
echo a:firstline a:lastline
endfunc

(for the uninitiated, this is about unwanted cursor movement with
:func! MyFunc() range
:endfunc
:10,20call MyFunc()
)

--
Andy

[Nate Soares]

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

+1 for stay.

@Andy, it's quite a bit harder to pass line numbers than it is to use the built in range functionality. Compare

-5,+3call MyFunction('foo', 'bar', 'baz')

to

call MyFunction('foo', 'bar', 'baz', line('.') - 5, line('.') + 3)

It's quite a bit more typing, it's error-prone, it pollutes the argument space, it subverts perfectly good built in functionality, and it's inconsistent.

It makes functions strictly less powerful than mappings and commands: they fundamentally can't do something that the others can! This should be uncomfortable.

Here's a patch that adds the "stay" argument to the :function command. Thoughts?

[Christian Brabandt]

On Thu, November 22, 2012 04:42, Nate Soares wrote:
> Here's a patch that adds the "stay" argument to the :function command.
> Thoughts?

That is nice.

,----[ :h todo.txt ]-
| ":function f(x) keepjumps" creates a function where every command is
| executed like it has ":keepjumps" before it.
`----

I wonder, if one should combine the keepjumps and stay functions into one
special argument or make 2 of it.


regards,
Christian

[Andy Wokula]

No.

E.g. you want to make a change at the cursor position and
take [range] lines into account to compute the change.
And you don't want :keepjumps for it.

Even without use case:
"Sooner or later, everyone wants everything as an option."
The new `stay' argument is an example for it!
So, `no' again ^^.

--
Andy

[Nate Soares]

+ docs

[Christian Brabandt]

Hi Andy!

On Do, 22 Nov 2012, Andy Wokula wrote:

> E.g. you want to make a change at the cursor position and
> take [range] lines into account to compute the change.
> And you don't want :keepjumps for it.
>
> Even without use case:
> "Sooner or later, everyone wants everything as an option."
> The new `stay' argument is an example for it!
> So, `no' again ^^.

Fine with me, I was just thinking loud.

regards,
Christian
--
Es ist erstaunlich, wie vorurteilsfrei wir zu denken verm�gen, wenn es
gilt, eine Dummheit vor uns selbst zu rechtfertigen.
-- Karl Heinrich Waggerl

[So8res]

Bump. Should I add tests? What's the process for adding tests? (I couldn't find a test testing function [range] and didn't think that adding a new test file was the right decision.

Are there any objections to adding this functionality?

[Roland Eggner]

:h cmdline-ranges
> 4. Ex command-line ranges *cmdline-ranges* *[range]* *E16*
>
> Some Ex commands accept a line range in front of them. This is noted as
> [range]. It consists of one or more line specifiers, separated with ',' or
> ';'.
>
> The basics are explained in section |10.3| of the user manual.
>
> *:,* *:;*
> When separated with ';' the cursor position will be set to that line
> before interpreting the next line specifier. This doesn't happen for ','.


Why not reusing or enhancing already established commandline syntax?
If “,” and “;” are not sufficient for all desired features of range
specifications, why not just introducing a new separator between line
specifications? E.g. two adjacent commas “,,”, or a caret character “^” would
not clash with current commandline syntax AFAICS. This would be easier to learn
from a user POV. Implementation might require more effort, though.

--
Roland

[Nate Soares]

I considered that, actually. However, the :call docs contradict this, stating that the cursor is moved to the first line irrespective of the range separator.

I'd prefer updating :call to honor the range separator. This is potentially backwards incompatible. I think it would be preferable for sake of consistency with the :cmdline-ranges documentation -- are there objections to this backwards incompatible change and/or suggestions for ways to work around it?

[Andy Wokula]

Am 29.11.2012 18:40, schrieb Roland Eggner:
> :h cmdline-ranges
>> 4. Ex command-line ranges *cmdline-ranges* *[range]* *E16*
>>
>> Some Ex commands accept a line range in front of them. This is noted as
>> [range]. It consists of one or more line specifiers, separated with ',' or
>> ';'.
>>
>> The basics are explained in section |10.3| of the user manual.
>>
>> *:,* *:;*
>> When separated with ';' the cursor position will be set to that line
>> before interpreting the next line specifier. This doesn't happen for ','.
>
> Why not reusing or enhancing already established commandline syntax?
> If “,” and “;” are not sufficient for all desired features of range
> specifications, why not just introducing a new separator between line
> specifications? E.g. two adjacent commas “,,”, or a caret character
> “^” would not clash with current commandline syntax AFAICS. This
> would be easier to learn from a user POV. Implementation might
> require more effort, though.

AISI ...

`,' versus `;' is a matter of how to get to the range boundaries. The
option to not move the cursor should work together with both of them.

To "not move the cursor" can (or should) mean two things:
- don't move the cursor initially (demand from function definition):
:func! MyFunc1() stay
- make sure the function call doesn't move the cursor at all (demand
from caller):
:KeepView [range]call MyFunc2() or
:[range]callkeepview MyFunc2() ...

--
Andy

[Nate Soares]

I agree, but there's still the issue that, according to cmdline-ranges, the caller should be able to do

:1,10call MyFunc()

:1;10call MyFunc()

and have them behave differently due to the , ; difference.

I'm still +1 for the addition of 'stay', as it makes the :%call case configurable by the function definition.

[Roland Eggner]

On 2012-11-29 Thursday at 12:55 -0800 Nate Soares wrote:
> On Thu, Nov 29, 2012 at 9:40 AM, Roland Eggner <ed...@systemanalysen.net>wrote:
> > Why not reusing or enhancing already established commandline syntax? If “,”
> > and “;” are not sufficient for all desired features of range specifications,
> > why not just introducing a new separator between line specifications? E.g.
> > two adjacent commas “,,”, or a caret character “^” would not clash with
> > current commandline syntax AFAICS. This would be easier to learn from
> > a user POV. Implementation might require more effort, though.
>

> I considered that, actually. However, the :call docs contradict this, stating
> that the cursor is moved to the first line irrespective of the range
> separator.
>
> I'd prefer updating :call to honor the range separator. This is potentially
> backwards incompatible. I think it would be preferable for sake of consistency
> with the :cmdline-ranges documentation -- are there objections to this
> backwards incompatible change and/or suggestions for ways to work around it?

What backward incompatibility could you imagine, that could not be avoided by
proper implementation?


--

@all: Sorry for my error posting my previous message twice.


@Nate: In every footer of postings in this list I read …
“Do not top-post! Type your reply below the text you are replying to.”

--
Roland

[Roland Eggner]

On 2012-11-28 Wednesday at 23:26 -0800 So8res wrote:

:h cmdline-ranges
> 4. Ex command-line ranges *cmdline-ranges* *[range]* *E16*
>
> Some Ex commands accept a line range in front of them. This is noted as
> [range]. It consists of one or more line specifiers, separated with ',' or
> ';'.
>
> The basics are explained in section |10.3| of the user manual.
>
> *:,* *:;*
> When separated with ';' the cursor position will be set to that line
> before interpreting the next line specifier. This doesn't happen for ','.

Why not reusing or enhancing already established commandline syntax?
If “,” and “;” are not sufficient for all desired features of range
specifications, why not just introducing a new separator between line
specifications? E.g. two adjacent commas “,,”, or a caret character “^” would
not clash with current commandline syntax AFAICS. This would be easier to learn
from a user POV. Implementation might require more effort, though.

--
Roland

[Roland Eggner]

On 2012-11-29 Thursday at 23:46 +0100 Andy Wokula wrote:
> Am 29.11.2012 18:40, schrieb Roland Eggner:
> > :h cmdline-ranges
> >> 4. Ex command-line ranges *cmdline-ranges* *[range]* *E16*
> >>
> >> Some Ex commands accept a line range in front of them. This is noted as
> >> [range]. It consists of one or more line specifiers, separated with ',' or
> >> ';'.
> >>
> >> The basics are explained in section |10.3| of the user manual.
> >>
> >> *:,* *:;*
> >> When separated with ';' the cursor position will be set to that line
> >> before interpreting the next line specifier. This doesn't happen for ','.
> >
> > Why not reusing or enhancing already established commandline syntax?
> > If “,” and “;” are not sufficient for all desired features of range
> > specifications, why not just introducing a new separator between line
> > specifications? E.g. two adjacent commas “,,”, or a caret character
> > “^” would not clash with current commandline syntax AFAICS. This
> > would be easier to learn from a user POV. Implementation might
> > require more effort, though.
>
> AISI ...
>
> `,' versus `;' is a matter of how to get to the range boundaries. The
> option to not move the cursor should work together with both of them.

Indeed … thank you for the clarification.

To me it seems we can have it to “work together with both of them”.
What about …

2,4fun()
2,,4fun()
2;4fun()
2;;4fun()

Typing just one additional key is probably attractive for lazy typists.

> To "not move the cursor" can (or should) mean two things:
> - don't move the cursor initially (demand from function definition):
> :func! MyFunc1() stay
> - make sure the function call doesn't move the cursor at all (demand
> from caller):
> :KeepView [range]call MyFunc2() or
> :[range]callkeepview MyFunc2() ...

To specify “without cursormovement” at the function definition is an interesting
additional variation. It could contribute to the target of maximum automation.
Instead of “stay” I would suggest something easier to memorize, e.g.
“keepcursor”.

--
Roland

[So8res]

Just tried to apply these clean and realized that the doc patch had caught some changes to tags. My mistake, a cleaned one is below.

Bram, do you have any preference on the name of this argument?

[Bram Moolenaar]

I don't like "stay", but can't think of something better right now.
Perhaps "keepline"?

--
hundred-and-one symptoms of being an internet addict:
95. Only communication in your household is through email.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[So8res]

>
> I don't like "stay", but can't think of something better right now.
>
> Perhaps "keepline"?
>

How do you feel about using 'range!' (with a bang) instead?

It would keep the :function argument space more concise, and would only be usable with 'range', both of which are nice. However, there's no precedent (that I can find) for command arguments having bangs.

[So8res]

Any word on getting a variant of range functions that don't move the cursorline? This still bites me occasionally.