Jumping between classes?

[goodboy]

In the docs you write:

In Python, ]m, ]M, [m, and [M are available to move to def or               
class blocks.  They are analogous to what's described in various-motions,   
except the part about braces.

I understood this as [M/]M would move the same as [[/]] normally do without the plugin installed?

Maybe i'm misunderstanding but how does one jump between top level definitions?

[tweekmonster]

There isn't a way to jump between top level blocks. As mentioned in #37, you can disable the maps for [[ and ]] to retain the maps set by the builtin ftplugin.

I understood this as [M/]M would move the same as [[/]] normally do without the plugin installed?

No. Without this plugin or the builtin ftplugin, [[ and ]] moves between { (open curly braces) without respect to their purpose. [m and ]m moves between { for methods/classes, and [M and ]M moves between } for methods/classes.

I felt that the builtin ftplugin's maps and the ones set by the python-mode plugin broke the meaning of these maps as explained in the docs. To me, it seemed like these maps were only added because there wasn't a meaningful way to jump between block boundaries. There aren't many languages where these maps are overridden in the builtin runtime scripts and I didn't like the inconsistency.

[goodboy]

@tweekmonster I like your thinking regarding how [[ and ]] should work in a braceless language.

So then my question is whether having a way to jump between top level blocks is something that is useful?

I personally miss it.

[tweekmonster]

So then my question is whether having a way to jump between top level blocks is something that is useful?

I think it's useful and I'm open to suggestions. You also got @blueyed's support, so that's something I can't ignore 😉

I've been getting by by using FZF's tag search. There's a discussion about the motions in #1 if it helps. After I got the sense that I made the scope of this plugin too big, I stopped adding new maps since there's only so many keys available.

I thought about adding [0 and ]0 as a "jump to block at first column" but thought it wasn't exactly ergonomic. Maybe it's better than nothing? I also thought about using <leader>[ and <leader>], but still has the ergonomic issue.

Whatever it is, it could do what the builtin ftplugin is doing since this feature wouldn't require block parsing.

Off topic: I'm now thinking I should rewrite the parser since I have a much better understanding of how python scripts are parsed by the interpreter now.

[goodboy]

After I got the sense that I made the scope of this plugin too big, I stopped adding new maps since there's only so many keys available.

Well then maybe you can accept #39 :)

@tweekmonster after thinking a bit more I'm starting to lean towards it not being a top level block jump but rather an actual class or type (other langs) jump. I agree that tags should be used where possible but sometimes it's handy between classes to get a feel for how things are organized especially since often classes the the main topic of interest with non-method helper functions surrounding them.

In terms of ergonomics I'm actually mostly partial to having the secondary key be on the lhs (querty of course) when using [ and ]. So I'd be partial to [s (section) or [t (top or type?).

[tweekmonster]

Well then maybe you can accept #39

It's been reviewed 😜

So I'd be partial to [s (section) or [t (top or type?).

I actually wanted to use [t and ]t, but it's in use by unimpaired which may as well be builtin with how much its recommended to new users.

[s and ]s could be used if there's a rule that states that it only works when spell is disabled. Another possibility is using ( and ) since I can't think of the last time that I found sentence motions useful in Python.

[goodboy]

@tweekmonster hmm. I really like using () but my concern would be with how it translates to other braceless languages...

Also maybe I'm blind, but where is unimpaired.vim using [t?

[blueyed]

@tgoodlet
https://github.com/tpope/vim-unimpaired/blob/4971b4226aa6f8a89fe4ba22310eb2451c84233a/doc/unimpaired.txt#L38-L39