[Feature Request] Automatically show and hide scroll bar

[mvcouwen]

If you go to Setting - General on macOS, you have the following option to show/hide scroll bars.

You can see how this works by using Finder with the different options.
This also has an effect on most of the macOS applications but not on MacVim.

Are there any plans to add this? Or maybe start by implementing options that have to be set manually in MacVim?

[eirnym]

@mvcouwen Thank you for an issue

it makes total sense, and it's relatively easy to extend guioptions for that.

[ychin]

It's on my backlog of things I want to add but I remember there's some tricky bits regarding how it interfaces with Vim, and how to get the "place two fingers to show the scrollbar" feature working. Should be doable if some effort is made.

[tucnak]

Hate to do a +1 on this, but hopefully some attention could be turned to this sooner than later.

I've been trying to introduce "easy mode" Vim as a primary editor for GPT-3 interactive prose writing with my non-tech literature friends and so far one of the most common annoyances I've heard— had to do with how these scroll bars are not "pretty."

Hopefully this makes sense.

[ychin]

Oddly timely, but this is actually in the works and I'm working on it right now. It's quite a bit tricky to get right because it's actually kind of involved (it's essentially a new feature) and I need to submit a pull request to upstream Vim to introduce a new type of overlay scroll bar setting before MacVim will get it. The reason why this isn't just a one-line change is that Vim scroll bars are weird and you only get two scroll bars pinned to the left/right of the window and it's not useful to make those auto-hide (macOS also doesn't let you make an auto-hide scroll bar on the left to begin with). The horizontal scroll bar is even more problematic because there's a single horizontal scroll bar at the bottom shared by all the split windows. So properly fixing this means making an overlay scroll bar for each split window, which also means the middle vertical split will now also get a scroll bar as well which is nice (in current Vim only the leftmost and rightmost vertical splits get scroll bars).

This is a video of what it looks like now but it's not quite done yet:

macvim.overlay.scrollbars.mp4

[ychin]

I've been trying to introduce "easy mode" Vim as a primary editor for GPT-3 interactive prose writing with my non-tech literature friends and so far one of the most common annoyances I've heard— had to do with how these scroll bars are not "pretty."

On a tangent, kind of curious if there are other annoyances you hear. Learning Vim is kind of a process so seems like there would be more than just scroll bars that would bug them? I guess if it looks early to begin with they may not even be enticed to learn it.

[tucnak]

Wow, your demo certainly looks very beautiful. Would you be so kind as to give this feature a dedicated branch any time soon? I would love to check this out and use this on the daily. The only caveat: perhaps the sliders themselves could be a little bit thinner, I can't immediately recall where I saw it, but in some application I remember having these very thin and semi-transparent; only when you hover over it with the mouse— it grows to normal scale so you can manipulate it.

BTW, in one of the threads (on Reddit maybe?) a year back, or around that time— I recall you've said explicitly that smooth pixel-perfect scrolling is in the works. Is this one of the features you're hiding from us on your local machine? 😆 I've dreamt of this very feature for so long.. I mean, it's the natural next step given that MacVim uses Core Text rendering, which is correct me if I'm wrong, GPU-accelerated. I kind of assumed that it's the reason why my MacVim instance hasn't lagged, ever when my terminal-based Vim lags once in a while. I'm a huge fan of macOS trackpad, and a trackball mouse logi m575 where I created binds for both <ForceClick> as well as the wheel click, and back/forth buttons which I have connected to the jumplist, so basically I can read big swathes of code without ever having to touch the keyboard. Point-and-click gets me around definitions and language server location lists, back/forth buttons allow me to navigate the jumplist efficiently, and with the sensitive scroll wheel, I get this nice smooth riding around the code without having to move around with binds like {{ and }} or jittery PageUp/PageDown keys, notably missing on the MacBook keyboard.

I'm bringing this up because pixel-perfect smooth scrolling is one of those features where we could see MacVim absolutely shine, and it can prove once and for all the supremacy of GUI vim, which in case of MacVim is miles ahead of terminal Vim these days when it comes to OS integrations (macOS services! huge fan!) as well as the native approach to windowing system which is simply beautiful not to mention i18n support which is critical for people like me, who speak many languages, some of which are Cyrillic. Despite keymaps and langmaps, terminal Vim is almost impossible to use in an i18n environment, but MacVim solves this problem in the most straightforward way— simply relying on Input Method for different modes; so I can keep my normal mode binds, and the input mode language consistent when I'm writing a novel in Ukrainian. I have a solid expertise in QML and KDE, which I have used professionally for many years. I've had this idea for a long time— to finally sit down and create KVim— a MacVim inspired Vim GUI, that would integrate (via QML) with KDE and Wayland similarly to how MacVim integrates with macOS and Cocoa, but for years I've used macOS almost exclusively so there wasn't incentive for me to get involved in a huge project like it. However, I'm getting a Talos II Secure Workstation this year due to my new occupation in the security community, so I would have to spend lots of time there, and might end up making this project a reality.

[tucnak]

Now, going back on a tangent which is something I'm very passionate about.

On a tangent, kind of curious if there are other annoyances you hear. Learning Vim is kind of a process so seems like there would be more than just scroll bars that would bug them? I guess if it looks early to begin with they may not even be enticed to learn it.

So you understand where I'm coming from— since school I've been involved in the literary circles— I've published poetry and plays in English, Ukrainian, and Russian. And this is the interesting bit— whereas poetry can be written anywhere and is best written using a sheet of paper, when it comes to playwriting— you have to rely on your tools for long-form text editing. Having been used to Vim as much, I couldn't really feel comfortable with the software common in the industry. Thankfully, there's a plaintext format similar to Markdown which is specifically tailored for the purpose of screenwriting— Fountain. Most screenplay formatting software now supports in one way or another; there are also compilers which take in a Fountain script, and produce a well-formatted Courier 14pt industry standard script PDF.

I've ran into some limitations with it, ergonomics-wise, and especially once I got into interactive fiction, I've had lots of ideas how Fountain could be extended far beyond this static print medium of strictly formatted PDFs so this is why I created Playfount— a reverse-compatible dialect of Fountain for interactive playwriting, which I can extend as I see fit. The Playfount link above in fact points to a Vim plugin I created with MacVim, as well as syntax highlighting, and folding in mind.

(The darkened § areas are in fact folded scenes)

I've found Vim incredibly useful for fiction. I use it for writing all my literature, also in conjunction with vim-gnupg which functions as transparent file encryption— for my personal diaries and journals, so I can simply put the most confident, private of my thoughts in a Dropbox and simply use Yubikey touch decryption whenever I need to search for something in my past entries, or write another entry. Vim foldexpr capability helps me greatly, for I can write arbitrary expressions and format foldtext accordingly, as well as highlight certain parts of the text (think nota bene) depending on the nature of a journal. I absolutely love the extent to which my text editor MacVim augments my creative process; it doesn't get in the way, in fact it does the opposite— it's infinitely extensible and I can make it transparent in the most complex scenarios like hardware OpenPGP smartcard encryption of files via Yubikey in which the encrypted file is never exposed to the disk unencrypted.

As you can imagine, I couldn't help but share my experiences with my literary friends.

I've mentioned things like extensibility, splits, text editing model allowing things like vim-surround and targets as well as supreme search/replace and navigation key binds, ad hoc text highlighting, fold expression, transparent encryption. Moreover, Vim allows you to print things exactly as you see them either as PDF, or in HTML. For example, consider HTML of the play that you can see in the screenshots above. In the future, my Playfount text format will augment this with interactive HTML/WASM/WebGPU canvas elements to make a completely new medium of interactive fiction. Whereas most interactive fiction writers are concerned with games, I'm looking to explore more traditional plays, novels, short stories, novellas.

I did have some luck "converting" my writer friends to MacVim, using "easy" mode and configs I helped write for them specifically, but it's still too much work and hard to justify in most cases. The greatest pitfall lies in multiline formatting, for example. There is immense value in breaking your lines at 80 characters, primarily because in prose we have usually very long paragraphs, and diffs simply don't work if you don't break your lines. We programmers know that in Vim you can reformat with gqip whenever you like, but for nontechnical people it's not obvious. So I considered perhaps having gqip in autocommand mode, or something. I haven't figured it out yet, but I'm set and determined to popularise MacVim among the creative writers, scientists, and journalists alike.

So by now you can probably see where I'm coming from with OpenAI GPT-3 support, and things like that with relation to MacVim. Long story short— I want to create a fork of MacVim specifically tailored to be used with a variety of language models. I've fine-tuned one of the OpenAI models on 10GB worth of film screenplays and 20GB worth of plays from the books— this model can be used as a remedy to "writers block"— basically you get autocomplete at any point in your text where you might feel lost, or trapped. That's the idea— let's replace the tool bar in MacVim with a set of controls commonly found in OpenAI Playground:

So, you choose the mode Complete / Insert / Edit, set the variables, length, number of variants you want to see generated, and then press a button. Boom! All of it is interactively suggested to you, so you can take a look, inspiration, or outright synthesise something out of the completions suggested to you.

The good part is that GPT-3 and similar models are capable of solving abstract problems in language.

So it doesn't even have to be prose, it can fix grammatical errors, or help edit essays, et cetera. I wish to try and popularise MacVim— as the first editor to natively support language models on masking, editing, completion tasks. For this, I would probably need to patch it heavily, and distribute it with a set of plug-ins pre-installed. There's also an option of "bootstapping" a new installation by the virtue of source being able to load configs over the Internet. This is how I got my writer friend who knows nothing about programming— to boostrap my set insertmode-based distribution of Vim— on his freshly installed MacVim yesterday:

:source https://gist.githubusercontent.com/tucnak/65876d2a540c5574fc4c0d433dc13198/raw/5f4aa17ccd57e9ebed339e8f9cdfe84f9d654fe7/macvim+openai.vim

But this config is very limited, and at this point is simply an experiment. I'm proud to say that it does talk via curl to OpenAI API, and displays the suggestions in a split, but for now that's about it. I feel like I can get a lot by simply forking MacVim, and better utilising the tool bar, but I'm still not sure what's the best way to display the API suggestions. Currently, I simply flush them all to a buffer in a split, but I really wonder if a list-based approach, or a floating window-based approach could prove superior.

What do you think? @ychin

What amount of effort am I looking at here?

[ychin]

Wow, your demo certainly looks very beautiful. Would you be so kind as to give this feature a dedicated branch any time soon?

Not quite ready for that but when I do the PR for Vim, which should be soon-ish, I'll include a dev branch so people can try it out. I can link to it here when I do that.

The only caveat: perhaps the sliders themselves could be a little bit thinner, I can't immediately recall where I saw it, but in some application I remember having these very thin and semi-transparent; only when you hover over it with the mouse— it grows to normal scale so you can manipulate it.

Probably not. This is using native macOS scroll bars and is how most macOS apps work. Some (usually cross-platform) text editors implement custom scroll bars. I have no interest in doing so, as MacVim focuses on native integration, and also implementing custom scroll bars properly is a lot of unnecessarily work. (E.g. in macOS you can place two fingers on the trackpad and the scroll bars will show up. You would need to implement features like that yourself if you do custom scroll bars)

I recall you've said explicitly that smooth pixel-perfect scrolling is in the works. Is this one of the features you're hiding from us on your local machine? 😆 I've dreamt of this very feature for so long.. I mean, it's the natural next step given that MacVim uses Core Text rendering, which is correct me if I'm wrong, GPU-accelerated. I kind of assumed that it's the reason why my MacVim instance hasn't lagged, ever when my terminal-based Vim lags once in a while.

I have something in the works but it's quite buggy for multiple reasons. The Vim drawing APIs make it hard to implement without visual glitches, and in fact implementing this overlay scroll bar feature could help the smooth scrolling feature because I'm adding an additional API for Vim to communicate where the Vim splits are which lets the GUI know more about the underlying structure and be able to fake the scrolling better. This is also what Neovide (Neovim GUI with smooth scrolling) does as well and it's still quite buggy when I played with it.

Also, no, CoreText renderer is not hardware accelearted. I need to convert to a Metal hardware accelerated renderer (#1262), and this is another issue with smooth scrolling: it will eat up a lot of CPU / battery unless the Metal part is done.

So bottom line is, it's still in the works but has some other dependencies and won't be done in the immediate future. Please use #273 to continue this discussion.

[ychin]

So what you did with Vim is pretty cool! And I like the GPT-3 idea. And I'm glad you are liking MacVim so much and it means a lot to me to know that efforts like making sure localization works in MacVim is appreciated (btw if you want to help translate the MacVim-specific messages we can coordinate on #1102).

For making a KDE / Wayland Vim you may want to talk to some people who work on the Linux gVim and (controversial topic) Neovim GUI projects. The latter is mostly because Neovim has more of an ecosystem of "an external GUI embedding core Vim" whereas in Vim we mostly have vanilla gVim and MacVim (which to be fair did prove that you can embed regular Vim inside an externally managed GUI, albeit with a fair bit more work). We should split off to a different discussion on this as this is not really MacVim-relevant anymore. But of course you can also start your own and see how it goes. I could give some advice if you do so, but it's a fair bit of work to get MacVim to the integrated state that it is today (with custom forked changes in Vim that continues to be an integration burden when we merge from upstream).

I feel like I can get a lot by simply forking MacVim, and better utilising the tool bar, but I'm still not sure what's the best way to display the API suggestions. Currently, I simply flush them all to a buffer in a split, but I really wonder if a list-based approach, or a floating window-based approach could prove superior.

What amount of effort am I looking at here?

I would probably recommend against forking MacVim. It's easy to do the initial fork and get something working, but it's a lot of work to continually update and merge from upstream and maintain. MacVim is already downstream of Vim, and you would be downstream of MacVim. It's just a lot of merging, fixing merge conflicts, and maintenance, and you would need to sign/notarize your "GPT MacVim" build as well. The work itself is probably not terribly hard, but just setting up the extra GUI, and learning how the interfacing between the GUI and Vim processes work. Because you are a downstream fork, I would not really try to accommodate you when I make MacVim changes, and you would need to constantly be chasing how MacVim works etc.

I think a better solution is to make a separate Mac app that can talk to MacVim via a channel (see :help channel.txt). This way you can build your fancy configuration UI however you want and it will be able to talk to both terminal and GUI MacVim. Considering that all you want is to generate text via a config UI, I think that should be enough? It's also easier to make your plugin cross-platform that way since the plugin itself is just using some cross-process communication. One thing is the channel API only supports using a server:port way of connecting, so if you want to use a more secure cross-process communication platform you may need something else (maybe using Apple's XPC) but it doesn't seem like this feature requires that.

Another solution is to have MacVim support a way to build GUI plugins so you can simply extend MacVim with custom UI. Similar requests have popped up before (see #1176 and #218), but it's a bit tricky to actually design properly. It would be a longer term project / discussion if we go down this route.

If you want to continue discussing this we should make a new issue/discussion from this. You can use the … -> "Reference in New Issue" button next to your comment.