MacVim defaults clean up and modernization

[ychin]

Just a general issue for improving the defaults for what I consider to be what constitutes a modern GUI text editor. Changing defaults is always contentious, and therefore should require a bit of thoughts behind them. None of the proposed defaults below change any features and they would just require either a vimrc change or changing them in the user settings. Just listing them below to keep track of and to gather feedbacks:

• Smooth resizing defaults to on (#1276)
• set guioption+=k
• set macligatures
• MMShareFindPboard should be NO.
• Overlay scroll bar (once implemented)
• set guifont=-monospace-

Update: I have made a comment for each of the new option in case people want to vote on them using emoji reactions. (Per suggested by a comment)

[nico]

I'm here because the release notes asked for feedback. Maybe it makes sense to have one comment per bullet point, so that people can thumbs-up and thums-down each item?

• No real opinion on smooth resizing (I have it on; having it on is probably a nicer default)
• No strong opinion on k
• No opinion on macligatures either. I don't use a font with coding ligatures, so it won't affect me. People who do use fonts with ligatures would probably prefer if those just worked, so it makes sense to me from a distance.
• Disagree on MMShareFindPboard being NO. A shared find pasteboard across apps is a macOS thing, and integrating MacVim with that seems like a good thing to do by default
• Depends on how good the overlay scroll bar impl is, but if it's good then that sounds good (as long as it honors the OS-wide pref for this)
• In favor of using -monospace- by default!

[ychin]

Maybe it makes sense to have one comment per bullet point, so that people can thumbs-up and thums-down each item?

That's not a bad idea. I'll do that. I wish there's a better way to do this in GitHub.

---

No opinion on macligatures either. I don't use a font with coding ligatures, so it won't affect me. People who do use fonts with ligatures would probably prefer if those just worked, so it makes sense to me from a distance.

Yes that's the main reason for turning it on. The main reason it's not on right now is that the renderer is less efficient when ligatures is on, so I'll be investigating this only after hardware-accelerated renderer is implemented and see if the improved renderer can make sure to have good default and worst case performance before switching defaults over. E.g. some terminals like iTerm2 don't even support hardware accelerated ligatures.

Disagree on MMShareFindPboard being NO. A shared find pasteboard across apps is a macOS thing, and integrating MacVim with that seems like a good thing to do by default

I think my annoyance with this is that a lot of search commands I do in Vim are oddball regex that don't translate to other programs, but maybe I never really bought in to this part of the Mac philosophy (sharing find pboard everywhere). But it's good to hear a dissenting view here. I should at least expose it as a graphical user-visible setting. (FWIW Cmd-E/Cmd-G in MacVim are hard-coded to use the system shared find pasteboard no matter what, and it ignores MMShareFindPboard)

[ychin]

New default:

• Smooth resizing defaults to on (#1276)

[ychin]

New default:

• set guioption+=k

[ychin]

New default:

• set macligatures

[ychin]

New default:

• MMShareFindPboard should be NO.

[ychin]

New default:

• Overlay scroll bar (once implemented)

[ychin]

New default:

• set guifont=-monospace-

[brombres]

New default:

• MMShareFindPboard should be NO.

• I downvoted.
• I don't feel too strongly about it either way.
• Agreed that the regex searches we often use aren't useful to other apps - but they could be in the future.
• Unless it being on by default is a pain point for people, we should just stick to the Mac paradigm. I've been a MacVim user for ~15 years and I never noticed that behavior, so it's prolly not bothering most people.
• I think your suggestion of leaving it on (YES) but exposing it as a GUI setting sounds great.

[bikermikem]

set guifont=-monospace-

Yes. Please.

[caseyandgina]

Can you please briefly explain what set guioption+=k and MMShareFindPboard would do?

Also, I downvoted ligatures because I assume that would mean that things like => would be rendered automatically as a ligature, and I think that would be jarring to me and others editing code as I've never experienced that behavior in the editors that I've used over the years (granted, most of those have been terminal-based, so it's more due to lack of ligatures in terminals, but I think I would find it annoying enough to search for a way to disable it).

[ychin]

set guioption+=k

This would make the window not change size when you add a new tab, scroll bar, and toolbar. Without this setting, adding/removing those will try to resize the GUI window to preserve same number of lines, which could be jarring for the user and unlike how most other text editors work. Setting the option makes it work more like in full-screen, where it will change the number of lines to preserve the GUI window size so the window stays stable.

MMShareFindPboard

This defaults to "YES" right now. It makes it so that all the search you do (e.g. using /) will be shared to macOS's find pasteboard. Then means you can search for something in Vim, then do Cmd-G in another app (e.g. Safari) and it will just work. The primary reason I don't like this is that a lot of times Vim searches are complicated regex patterns that may not make sense in other text editors. But from other people's reactions I'm easing on that.

Also, I downvoted ligatures because I assume that would mean that things like => would be rendered automatically as a ligature, and I think that would be jarring to me and others editing code as I've never experienced that behavior in the editors that I've used over the years (granted, most of those have been terminal-based, so it's more due to lack of ligatures in terminals, but I think I would find it annoying enough to search for a way to disable it).

=> will only be turned into a ligature if your font supports it, which I would guess your font does not. I actually don't know if there's any font ligature at all in the default monospace fonts provided by Apple. Usually people have to install custom fonts like Fira Code in order to get ligatures. Ultimately your font dictates what ligatures you will get, and usually when people use a font that supports ligatures that is because they want ligatures, but maybe that's not always true.

But it's a fair point that a renderer isn't obligated to support ligatures, and the default should probably be more minimal, as people who care about ligatures can just turn it on.

[caseyandgina]

Thanks! Given that, I upvoted both of those.