Variable for "motion type" in Operator-pending mode

[glts]

Hi,

I have recently learnt of a patch that was submitted to the list almost
five years ago. Please see here:

https://groups.google.com/d/msg/vim_dev/lR5rONDwgs8/iLsVCrxo_WsJ

The reception was positive but for some reason the discussion was
abandoned. I would like to reopen the discussion. I'd be very interested
in this feature and happy if the patch could eventually be included.

As for the name of the variable, how about:

v:motiontype

The documentation says that when no motion type is given the variable
will be empty, when an explicit motion type is given ("forced") it will
be "v", "V", or "<C-V>". I don't think the word "force" is strictly
required to make the intent of the variable clear.

As for the underscore, the majority of v: variables with compound names
don't have it and I think this short name would look nice next to the
other variables which are relevant in this context:

v:register v:count v:count1 v:prevcount v:operator v:motiontype

What do you think?


--
David Bürgin

[Ingo Karkat]

On 18-Apr-2013 16:16 +0200, glts wrote:

> Hi,
>
> I have recently learnt of a patch that was submitted to the list almost
> five years ago. Please see here:
>
> https://groups.google.com/d/msg/vim_dev/lR5rONDwgs8/iLsVCrxo_WsJ

Oh dear, I remember that! It's frightening how quickly time passes :-)

It's in the official todo list ($VIMRUNTIME/doc/todo.txt), though:
,----
| Add v:motion_force. (Kana Natsuno, 2008 Dec 6)
`----

> The reception was positive but for some reason the discussion was
> abandoned. I would like to reopen the discussion. I'd be very interested
> in this feature and happy if the patch could eventually be included.
>
> As for the name of the variable, how about:
>
> v:motiontype
>
> The documentation says that when no motion type is given the variable
> will be empty, when an explicit motion type is given ("forced") it will
> be "v", "V", or "<C-V>". I don't think the word "force" is strictly
> required to make the intent of the variable clear.

With v:motiontype, I'd expect that to be applicable to _every_ motion,
not just those few special ones. I would prefer v:forcedmotiontype. The
only saving grace for this unreadable monster is that it's probably not
going to be used very much.

> As for the underscore, the majority of v: variables with compound names
> don't have it and I think this short name would look nice next to the
> other variables which are relevant in this context:
>
> v:register v:count v:count1 v:prevcount v:operator v:motiontype

Yes, consistency is good.

> What do you think?

I'm missing a bit where such a variable would be useful or even
necessary. A compelling example could avoid that we have to wait another
five years for inclusion :-)

-- regards, ingo

[glts]

Ingo,

On Fri, Apr 19, 2013 at 8:58 PM, Ingo Karkat <sw...@ingo-karkat.de> wrote:
> On 18-Apr-2013 16:16 +0200, glts wrote:
>> As for the name of the variable, how about:
>>
>> v:motiontype
>>
>> The documentation says that when no motion type is given the variable
>> will be empty, when an explicit motion type is given ("forced") it will
>> be "v", "V", or "<C-V>". I don't think the word "force" is strictly
>> required to make the intent of the variable clear.
>
> With v:motiontype, I'd expect that to be applicable to _every_ motion,
> not just those few special ones. I would prefer v:forcedmotiontype. The
> only saving grace for this unreadable monster is that it's probably not
> going to be used very much.

I don't care too much about the name, to be frank. In the end it's
mostly a matter of taste.

But let me rephrase my argument in favour of v:motiontype. The docs say
that the variable is empty when no motion type is given. Empty
essentially means "use the default motion type". "v/V/<C-V>" means
"override the default motion type with X-wise motion". So in any case
the variable asserts something about the type of motion.

Let's go with whatever people find prettiest, I'm fine with any name.

>> What do you think?
>
> I'm missing a bit where such a variable would be useful or even
> necessary. A compelling example could avoid that we have to wait another
> five years for inclusion :-)

To be honest, "motion force" isn't something I use daily. Every once in
a while I find my cursor sitting in a sweet spot and immediately see
that dvj would finish the job, or dV{, or cvit. My concern is to allow
custom text objects and motions to have the same capabilities as the
built-in text objects and motions.

Here's a good real-life example.

The textobj-word-column.vim plugin lets you select a column (Visual
block) of words/WORDs based on the word/WORD under the cursor. If
v:motiontype were available, the plugin could let you do, for example,
yVac (yank linewise a word-column), basically allowing you to yank a
range of lines which have a vertical component in common, so to speak.
See? Well, I think that is very useful.

[Kana Natsuno]

On Saturday, April 20, 2013 6:50:58 AM UTC+9, glts wrote:

> On Fri, Apr 19, 2013 at 8:58 PM, Ingo Karkat wrote:
> > With v:motiontype, I'd expect that to be applicable to _every_ motion,
> > not just those few special ones. I would prefer v:forcedmotiontype. The
> > only saving grace for this unreadable monster is that it's probably not
> > going to be used very much.
>
> I don't care too much about the name, to be frank. In the end it's
> mostly a matter of taste.
>
> But let me rephrase my argument in favour of v:motiontype. The docs say
> that the variable is empty when no motion type is given. Empty
> essentially means "use the default motion type". "v/V/<C-V>" means
> "override the default motion type with X-wise motion". So in any case
> the variable asserts something about the type of motion.

+1 to v:motiontype.

[David Fishburn]

On Apr 19, 2013, at 5:50 PM, glts <676c...@gmail.com> wrote:
...

>
> Here's a good real-life example.
>
> The textobj-word-column.vim plugin lets you select a column (Visual
> block) of words/WORDs based on the word/WORD under the cursor. If
> v:motiontype were available, the plugin could let you do, for example,
> yVac (yank linewise a word-column), basically allowing you to yank a
> range of lines which have a vertical component in common, so to speak.
> See? Well, I think that is very useful.
>

For the YankRing plugin I use expression maps. I have to pass in the motion to figure this out and take appropriate action.

There are still many cases where I have to guess and try to do the right thing.

So this too would help with it.


--
David Fishburn

[glts]

If we could settle on a name for the variable, I would be happy to
update the patch and write a test. This is a low-risk patch unlikely to
cause any trouble, neither in 7.3 nor in 7.4.

Please make your opinion heard if you haven't already.

https://groups.google.com/d/msg/vim_dev/lR5rONDwgs8/iLsVCrxo_WsJ
https://groups.google.com/d/msg/vim_dev/MNtX3jHkNWw/bhL-o6TlKtgJ