FR: Support for gj and gk

[chrisgrieser]

Since most of the text fields where svim will be used have line wrapping, having gj and gk would be very useful for mappings like

nnoremap j gj
nnoremap k gk

right now, j and k move logical lines, which makes them a bit hard to predict in text fields where you are not sure where exactly the previous line is (i.e. is the line above wrapped or a "true" previous line?)

The workaround might be as simple as mapping gj and gk to arrow-down and arrow-up, since the arrow keys in macOS use visual instead of logical lines?

[FelixKratz]

Oh, thats a nice idea! Funnily enough I have already coded something like that for arrow key movement in scrollable views, i.e. the Finder file list or PDF viewers etc. for my personal movement keys and only compiled in when the appropriate flag is set (jklö -> left, down, up, right arrows):

SketchyVim/src/ax.c

Lines 241 to 264 in 75d24df

	#ifdef GUI_MOVES
	// NOTE: Gui movement is currently hardcoded for my movement keys jklö and
	// NOTE: only available when compiling with the -DGUI_MOVES flag
	if (ax->role == ROLE_TABLE || ax->role == ROLE_SCROLL) {
	switch (character) {
	case K: {
	CGEventSetIntegerValueField(event, kCGKeyboardEventAutorepeat, false);
	CGEventSetIntegerValueField(event, kCGKeyboardEventKeycode, 125);
	} break;
	case L: {
	CGEventSetIntegerValueField(event, kCGKeyboardEventAutorepeat, false);
	CGEventSetIntegerValueField(event, kCGKeyboardEventKeycode, 126);
	} break;
	case J: {
	CGEventSetIntegerValueField(event, kCGKeyboardEventAutorepeat, false);
	CGEventSetIntegerValueField(event, kCGKeyboardEventKeycode, 123);
	} break;
	case OE: {
	CGEventSetIntegerValueField(event, kCGKeyboardEventAutorepeat, false);
	CGEventSetIntegerValueField(event, kCGKeyboardEventKeycode, 124);
	} break;
	}
	}
	#endif //GUI_MOVES

this could be used to do exactly what you want with a bit of fiddling.

I would accept pull-requests where this is optional (via a compile flag) and well integrated with the synchronization.

[chrisgrieser]

I would accept pull-requests where this is optional (via a compile flag) and well integrated with the synchronization.

(Just in case you are asking me, I unfortunately have zero knowledge of C and wouldn't be able to do that 🙈)