Gvim rustfmt-on-save oddity on Windows

editors and IDEs
1

This is a multi-year issue which I do not think existed at some point in the past, but I don't know when it started happening. From time to time I've tried to poke at it and figure out why it happens, but I never found a solution.

I have a philosophy about my development environment that I think is a little out of the ordinary: I don't like to bling it up too much. The basic idea is that I use things that are available in "normal" distributions. In some sense I don't want to become accustomed to anything that I won't be able to use wherever I might end up needing to work. (Backstory is that a colleague refused to work at a workstation once because he couldn't get all his editor bling working on it, and I realized I never want to become hooked to bling like that). This is all just to say that my setup is pretty spartan (I don't use rust-analyzer, for instance), but that does not mean it's 100% pure of custom modifications -- but the general answer to "are you running plugin X" is "no", unless it's part of the most common gvim distros. I use the same configuration on all platforms (vim configuration is checked in and distributed using scm), and I try to avoid platform-specific configurations. (Again, might not be 100% free of it, but I do my best to avoid adding any custom platform-specific configuration changes).

I do, however, use run rustfmt-on-save, because that's part of all the gvim distributions I use -- and it's what has been causing me some grief [on Windows].

The problem I'm having is that when I save a file [on Windows], and rustfmt succeeds, then gvim moves the cursor to the second-to-last line. Given how gvim works, I can in most cases just press Ctrl-O to get back to where I was, but it's still kind of annoying. (I've been able to live with this, because I usually do development on other platforms and just patch Windows-specific issues on Windows, but I'm currently working on something that requires more actual Windows screen time).

Has anyone seen this before? Anyone know how to solve this? Perhaps more importantly, how would one even begin to diagnose this? I'm ashamed to admit that whenever I've tried to solve this, it has basically been using the shotgun approach, because I don't know how I would go about investigating this systematically.

I have found a few others mention this behavior, and IIRC some had gvim place the cursor on a different line (not the second to last), but in other regards it appears to be the same issue -- but I haven't found any actual explanation/solution.

2

It's interesting. There simply no such spot where the cursor was before formatting. When I code, my new code just go in one line, sometimes it's a couple kilobytes in length. So, the line gets broken in hundred lines after a save, and any editor will be puzzled to move the cursor in the right line. My editor solves it simply holding the cursor in the same line, as it was before saving. But my editor isn't gvim. Maybe you can instruct gvim to keep a cursor in the last line of your editing?

1 Like
3

So the thing is that this is exactly what the built-in rustfmt support is supposed to do -- in fact, it does it on macOS and the linux distros I use (using the same configuration). I assume it is this record keeping that fails for some weird reason. It a little baffling -- I could sort of understand if it ended up on the first line, or even the last line, but second to last is just practical joke levels of weird.

But I assume you mean "do it manually, even if it's supposed to do it for you", which is actually an interesting thing to try. Unfortunately due to my spartan configuration philosophy, I have never learned vim at the level that I know where to start with such a thing. Time to learn New And Exciting Things(tm)!

4

Maybe it is a mismatch between unix and dos line endings?
When you do :set fileformat? does it say dos?

You can change it with :set fileformat=unix

1 Like
5

Hm.. That's an interesting thing to investigate. I forcibly set unix line endings everywhere that I can (using set ff=unix in modelines and in rustfmt.toml), but I wonder what would happen if I do the opposite, and force it to use Windows line endings everywhere instead.

The line endings theory would also vaguely relate to weird second-to-last line behavior, because the last line of the file is a modeline which does not have a hard line ending. You might be on to something here.