Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MacVim incerts dot on a double space #1318

Open
5 of 7 tasks
eirnym opened this issue Oct 18, 2022 · 6 comments
Open
5 of 7 tasks

MacVim incerts dot on a double space #1318

eirnym opened this issue Oct 18, 2022 · 6 comments
Labels
Input Issues related to keyboard or other types of input

Comments

@eirnym
Copy link
Contributor

eirnym commented Oct 18, 2022

Steps to reproduce

  1. Open new file and enter insert mode
  2. "a b" (2 spaces)
  3. Observed: standard macOS replacement would be in place "a . b"

Issue is GUI-specific as too much "modernisation" in place

Expected behaviour

I'll see "a b" on a screen

I'd expect also a regression test for this case.

Version of Vim and architecture

arm64

Environment

macOS 12

How MacVim was installed

Github

Logs and stack traces

No response

Vim configuration where issue is reproducable

No response

Issue has been tested with given configuration

  • by running MacVim.app from GUI macOS interface
  • by running vim/gvim/etc installed by MacVim
  • by running other versions of vim (e.g. /usr/bin/vim)

Issue has been tested with no configuration

  • by running mvim --clean (or gvim, supplied by MacVim distribution)
  • by running vim --clean (in terminal, supplied by MacVim distribution)
  • by running vim --clean (in terminal, other suppliers, e.g. /usr/bin/vim)

Other conditions

  • The both Homebrew packages "vim" and "macvim" are installed
@eirnym
Copy link
Contributor Author

eirnym commented Oct 18, 2022

@ychin I understand MacVim modernization and I like it, while it doesn't break defaults and have ability to turn it off. If you add new CoreText features, it's fine, if you want to promote them, it's fine, but please, keep default Vim experience as default one. This is the same as with dictionaries, I like the feature overall and I agree that dictionaries turned by default could potentially be ok (till trackpad bindings are not involved), but I want to have an ability to turn it off partially or completely if I want minimal "Vim with GUI, mouse scrolling and selection and copy-paste experience" as it was by default all these years.

@ychin ychin added the Input Issues related to keyboard or other types of input label Oct 19, 2022
@ychin ychin added this to the Release 176 milestone Oct 19, 2022
@ychin
Copy link
Member

ychin commented Oct 19, 2022

Sorry, what "broke"? Core Text renderer has not supported the "double space -> period" shortcut since the beginning and it has been the default renderer since before I became maintainer. Are you saying that we should keep non-Core Text renderer around? As far as I am concerned, the non-Core Text renderer is not the "default" or "minimal" version of MacVim, and has been deprecated for years.

The issue with non-Core Text renderer is that it doesn't really work properly, at all, since the beginning. You can easily see that by typing emojis or CJK (Chinese/Japanese/Korean) characters in a vertically split window and immediately see the text layout break. We don't have control over the rendering as much as we do in Core Text renderer and that's why we switched over to a custom renderer a long time ago. This isn't going to change but we can add more support for Core Text renderer to behave more like a native text view, but we aren't going to support the non-Core Text renderer (frankly, we haven't supported it for years).

The non-Core Text renderer also has terrible performance (even though Core Text renderer isn't great). There is a reason why none of the terminal emulators use it. The class NSTextView is designed where it has complete control of the text so you can get hardware accelerated scrolling. We don't have that in MacVim because the text storage is controlled by Vim, so every time you scroll you have to update the entire text view which is quite slow. If we want to have even better scrolling performance (since Core Text isn't that great to begin with) we need to move to a hardware-accelerated renderer which will be built on top of Core Text renderer, not the old one.

In fact, the dictionary feature mentioned here was implemented just by supporting the text input client protocol more fully (which macOS expects from a text input). If you have been using the non-Core Text renderer, that feature already gets auto-enabled without a way to turn off, so if you have been using non-Core Text renderer I don't understand the complaint here as you would already have had it enabled. I haven't looked closely into this feature request, but I suspect it involves implementing some of the remaining missing features of the text input client.

Issue is GUI-specific as too much "modernisation" in place

As I said, this feature never worked in Core Text renderer, which has been the default for years. I suggest trying out older builds.

This is the same as with dictionaries, I like the feature overall and I agree that dictionaries turned by default could potentially be ok (till trackpad bindings are not involved),

I still don't understand the concern here. Can you actually explain to me in what way would leaving this feature on be a problem for you, please? "I don't like it" is not a good reason because you don't have to use the feature, and I'm not aware of any regressions caused by this (this issue isn't it as I already explained). It's also not like the feature caused MacVim to be more bloated in size (in fact, adding an option would add complexity to the code). Most of the code size comes from Vim, and overall package size is dominated by all the runtime files.

As I have mentioned multiple times, MacVim wouldn't use the dictionary feature from a trackpad gesture if you turned it off in the trackpad settings. I do not see a need for a setting if you need to go out of your way (either turning it on in trackpad settings or using an obscure Ctrl-Cmd-D shortcut key) to use it to begin with. What does "turning it off" do? The feature literally doesn't do anything unless you engage with it. It's like saying that you don't like say Vim's terminal feature and prefer tmux on iTerm2 and want the terminal feature "turned off". I mean sure, that's fine, but you could just choose to never use it by never typing :terminal.

I want minimal "Vim with GUI, mouse scrolling and selection and copy-paste experience" as it was by default all these years.

What you are asking for here isn't minimal Vim, as "double space -> dot" is not a Vim feature, but a macOS one. If you use Vim in the terminal (Apple Terminal or iTerm2) you don't get that anyway. This feature requires OS integration, and in a way break the default assumptions of Vim (which wants tight control over the input), so it's anything but "minimal Vim" experience. Any OS integration like this necessarily would make it less "Vim"-like and more "macOS"-like. E.g. macOS key bindings like Ctrl-A / Ctrl-E to go to begin/end of line are "Emacs"-style, so MacVim doesn't work with them, while Cmd-Left/Right doesn't conflict with anything in Vim and that's why we support them in MacVim.


As for this feature itself, there is an input revamp coming (tentative r176 but that may be pushed back) to fix misc input issues, and supporting system input is one of the things I'll fix, so I will try to make sure the double-space -> dot thing is covered.

@eirnym
Copy link
Contributor Author

eirnym commented Oct 20, 2022

I'll respond in several comments on this long text.

I use Core Text for years by now (starting as this option came live) and almost never turn it off (except for issue testing). In all release except the latest ones I had no issue with double space at all.

@eirnym
Copy link
Contributor Author

eirnym commented Oct 20, 2022

I don't cover Vim in terminal as you can enter as many spaces as you want and you'll never get dots as it should be. It's not a Vim core issue, just MacVim GUI's

@eirnym
Copy link
Contributor Author

eirnym commented Oct 20, 2022

Thank you for pointing me out to non-core-text renderer. After some specific issue I haven't turned it back on.

@eirnym eirnym closed this as completed Oct 20, 2022
@eirnym
Copy link
Contributor Author

eirnym commented Oct 20, 2022

Reopen to add tests for this case.

@eirnym eirnym reopened this Oct 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Input Issues related to keyboard or other types of input
Projects
None yet
Development

No branches or pull requests

2 participants