Boldly provide default maps? about splitjoin.vim HOT 11 CLOSED

I don't like to put default mappings in order to avoid conflicts, but I see your point. Using splitjoin without a mapping is pretty pointless, so a user would have to figure something out anyway. Providing a reasonable default should help them out.

I'd imagine you'd agree that sj and sk are nonstarters (take it from the guy that used to map s
in surround.vim). And leader maps are pretty lame.

Can't argue with you there.

You could pick a pair like cS and cJ (or cJ and cK, if that feels more natural)

I've never thought about cS and cJ, that does sound sensible. It is a "change", after all. One thing that bothers me is that the c family leaves the cursor in insert mode, while splitjoin doesn't. That might throw some people off. But having S and J (or J and K) as a second key shouldn't conflict with anything I can think of.

Basically, the two things I need to figure out are:

• What kind of prefix to use?
• Should I aim for mnemonic keys (e.g. cS, cJ), or directional ones (e.g. cJ, cK)

My current favorites are gJ and gK. The g prefix is a bit of a mixed bag anyway (from what I've noticed). I'll ask around for some opinions and think of something.

from splitjoin.vim.

For what is worth I'm currently using ,ss and ,sj but I realize that it's quite lame.
My vote is for cS and cJ (they are in accordance with the plugin's name).

from splitjoin.vim.

I don't like to put default mappings in order to avoid conflicts, but I
see your point. Using splitjoin without a mapping is pretty silly anyway,
so a user would have to figure something out anyway. Providing a reasonable
default should help them out.

Default mappings get a (deservedly) bad rap because there are a lot of
mediocre plugins loaded with them. Your commenting plugin doesn't need 15
maps. Your calendar plugin doesn't need even one. But if your plugin makes
character-level changes to the buffer, it probably deserves a map or two.

I've gotten increasingly bold in my default maps over the years (while
still avoiding the ridiculousness I discussed above), and the only
complaints I can think of are about the visual mode s map in surround.vim
(which I've since removed), and that unimpaired.vim's bracket maps can be
tough on international keyboards.

I've never thought about cS and cJ, that does sound sensible. It is a
"change", after all. One thing that bothers me is that the c family
leaves the cursor in insert mode, while splitjoin doesn't. That might throw
some people off. But having S and J (or J and K) as a second key
shouldn't conflict with anything I can think of.

I did it with cs in surround.vim and that turned out okay. Keep in mind
that Vim itself has some weird combinations (dp doesn't delete anything).

How about =J and friends? The logical leap from indenting to formatting
is a small one. There's also gqJ.

Basically, the two things I need to figure out are:

• What kind of prefix to use?
• Should I aim for mnemonic keys (e.g. cS, cJ), or directional ones
  (e.g. cJ, cK)

Take your time. Unimpaired's blank line maps started (unpublished) as
[<CR> and ]<CR>, but I changed them because the pinky gymnastics were
too much. (I suspect gqJ would have the same problem, for example.)

My current favorites are gJ and gK. The g prefix is a bit of a mixed bag
anyway (from what I've noticed). I'll ask around for some opinions and
think of something.

gJ is taken. So are zJ and zK, if that's your next instinct.

from splitjoin.vim.

In the case of joining, one particularly bold strategy would be to make regular J or gJ "smart", falling back to the original behavior if there's no applicable splitjoin logic. gJ, in particular, is pretty worthless in source code due to indenting. People could always hop into visual mode if they hit an edge case. That leaves open the question of the split mapping. gS is free.

from splitjoin.vim.

Okay, that last one got me a little excited, so I made a proof of concept:

function! s:join(cmd)
  if exists(':SplitjoinJoin') && !v:count
    let tick = b:changedtick
    SplitjoinJoin
    if tick == b:changedtick
      execute 'normal! '.a:cmd
    endif
  else
    execute 'normal! '.v:count.a:cmd
  endif
endfunction

nnoremap <silent> gJ :<C-U>call <SID>join('gJ')<CR>
nnoremap <silent>  J :<C-U>call <SID>join('J')<CR>
nnoremap <silent> gS :SplitjoinSplit<CR>

I've clobbered both J and gJ here so I can get a feel for just how annoying it will be. (I suspect I'll end up with just gJ).

from splitjoin.vim.

I did it with cs in surround.vim and that turned out okay. Keep in mind that Vim itself has
some weird combinations (dp doesn't delete anything).

The cS and cJ mappings sound reasonable to most people I talked to, so I guess that's a good option if the others don't work out. =J and similar could work, but I'm worried about the position of the = key relative to Shift+j. Then again, cS might have a similar problem -- both keys are on one hand. Regardless of what prefix I figure out, J and S are going to require one-handed chords, which I dislike (part of the reason I like J and K). It does seem most people prefer mnemonics, though, so it shouldn't be a global issue.

In the case of joining, one particularly bold strategy would be to make regular J or gJ "smart",
falling back to the original behavior if there's no applicable splitjoin logic.

I hadn't realized gJ is taken, and I'm a bit worried about the "smart" idea in general. Technically, if you want to simply join a line without "splitjoin"-ing it, you wouldn't be able to unless you specifically recognize that the line is "special" and mark it in visual mode. I can imagine this being annoying. The other problem with it is that a few joins don't exactly play well with detection. For example, this coffeescript code:

foo = """
  bar
"""

bar = """
  baz
"""

If I were on the bar line, I can join the string. However, if I were between the two strings, it would still attempt to join them, because the """ delimiter is the same and it can't figure out which one is the beginning and which one is the end. I should probably make a check if I'm in a string-like syntax, but I'd have to go around all definitions and see how I can make them safer. Which is a good thing to do regardless of the mapping, mind you, it's just that I have to do it :).

Now, that said,

gJ, in particular, is pretty worthless in source code due to indenting. People could always hop
into visual mode if they hit an edge case.

The fact that gJ is fairly useless is pretty important. I'm not really sure what context you'd want to use it anyway, but in a programming language, it should really be pointless. And in a plaintext file, you probably wouldn't have splitjoin definitions anyway, so you'd have the default behaviour for free. It also makes a nice parallel with the built-in j mapping, since, as I mentioned, the g prefix tends to mean "do something a bit different". I could add a few warning words in the doc files, too, so if someone actually does use it a lot, they could do the mapping themselves.

The POC looks good. In general, splitjoin functions return 0 if no change has been made, and 1 otherwise, though there's nothing enforcing that. Using b:changedtick might actually be more stable. I'll have to think about what to use here as well. Do let me know whether you run into any problems with that mapping.

Take your time.

I will. The gJ/gS pair seems reasonable enough for now, even if it does override a built-in. Maybe I could go around the definitions and try to make them a bit more strict, just in case.

from splitjoin.vim.

I went through the plugin to check for odd behaviour when no splitting/joining is possible, but couldn't find any problems. I seem to have bad memories from a time when splitjoin attempted to join tags when inside of them, which caused it to mangle entire html documents. Apparently, I've fixed that since.

I've pushed a commit to master that sets gJ/gS as default mappings and provides options to set them to whatever a user wants. I don't have much experience on providing mappings, but this seems like a flexible deal. Let's hope it's not too convoluted. If anyone has any advice on this, I'd appreciate it.

I'm going to close the issue with this. @tpope, if you've found any problems in your experiments, do reopen. And thanks a lot the s:join implementation and, more importantly, for the mental push towards mappings in the first place :).

from splitjoin.vim.

I've run into a few behaviors I'd like to see tweaked (I'll write them up when I have more time), but no blockers. It's great to see this released!

from splitjoin.vim.

@tpope, I've had some (admittedly rare) issues with the gJ fallback, like #72. I think there was one more, but I have no memory of any details, just that there was one :). I can't figure out what the problem might be, though, so I'm thinking maybe I should just remove the "smart" functionality of gJ. It feels like not that many people would care (or really, even know) about this. What do you think?

from splitjoin.vim.

Without even trying to understand that issue, would it be possible to leave the gJ fallback in place only for file types with zero splitjoin support?

from splitjoin.vim.

Nevermind, I'm an idiot. I just figured out the problem, and it's extremely easy to fix. Sorry to bother you :).

from splitjoin.vim.