Remove format-on-save as the default

[Himujjal]

The plugin automatically calls zig fmt to format the code as soon as we save the file. This can be set as option rather than the default.
When developing on large files, zig fmt slows down the formatting when called from scratch. I for example use the ZLS (zig language server) to format which is much faster. I can disable this plugin for sure, but I would suggest keeping this as not the default.

[yohannd1]

Not only that, adding an automatic saving feature makes this plugin less consistent with most other filetype plugins, but I'm not sure if that is a particularly bad thing.

[haze]

I will leave this issue open, but I'm not particularly fond of changing the behavior because it isn't "consistent" with other plugins.

@Himujjal as far as I'm aware, both use zig fmt for formatting the files.
the file in the zig repo lib/std/special/compiler_rt/udivmodti4_test.zig is formatted with zig fmt in 230ms (65000 lines). I think the difference in speed here might be due to editor difference, as the LSP variant might use an async write while this plugin uses a sync one

[Himujjal]

@haze I figured out why it was slow in my setup (I had fish as the default vim shell instead of bash). I totally forgot about this issue. Sorry for not closing it sooner.

Anyways, I still think that having autosave on is a bad default and its of course very heavily opinion based. I am not sure if the option to disable it was available when I first opened this issue (cant remember). Since its available now, my problem is done. Thank you.

[haze]

If there is a growing audience for moving the default to not saving on default I'm happy to reopen this

[talhasaruhan]

I can second this request.

[andrewrk]

I want to point out that format-on-save breaks redo, which is pretty frustrating. Sometimes I do :let g:zig_fmt_autosave = 0 when working on tricky code just so that I can use the redo feature of vim.

I don't know why format-on-save breaks redo. It doesn't seem like it should.

[haze]

@andrewrk we nuke the entire file when we format:

zig.vim/autoload/zig/fmt.vim

Line 42 in 3538ae9

" Replace the file content with the formatted version.

[lucy]

This has made its way into upstream vim/neovim runtime files and is very confusing when using zls. It automatically puts errors in my loclist by default too which is annoying.

[Spiffyk]

I wanted to learn Zig and wasted quite a lot of time on this. I seriously dislike autoformatting and one of the reasons I use NeoVim is that it stays out of my way and does not do things like this unless I explicitly ask it to. The behaviour of this plugin breaks that, and it was pretty difficult to find out how to disable it, especially since I never even thought to suspect NeoVim's built-in runtime files to be at fault here.

It won't be an issue for me anymore, since I just plopped the let g:zig_fmt_autosave = 0 line in my .vimrc and will soon forget all about it, but on behalf of other Vim/NeoVim users who use it for similar reasons, I would ask you to reconsider the decision to keep auto-format on by default.

[heysokam]

+1 on this request.
This is one of the most frustrating things to deal with when you have your own workflow and are used to write in a specific way that works perfectly well in any language across the globe... come to Zig... and then you cannot format your own code in your own way anymore, because auto-zig_fmt-on-save hard-forces you their style into your throat.

Please let the users -choose- when they want to format their own code. Don't make decisions for us. Thank you.

[TomicekRosic]

Also had this issue. Frustrating.

[andrewrk]

Please let the users -choose- when they want to format their own code. Don't make decisions for us. Thank you.

It's by definition impossible to let users choose the default setting. The config file is where users make a choice

[heysokam]

It's by definition impossible to let users choose the default setting. The config file is where users make a choice

I think you missed the point of that message.
I'm not asking to decide my own custom default for myself. That just makes no sense.

I'm asking for the default to not be that I'm forced to find some hidden lsp config option to disable the formatting, when I'm learning and getting used to the lang, and everything is already foreign enough as it is.

Every other lang/tool I know lets you choose -when- you format. It doesn't just format your code without asking if you wanted to format your own code. That' just makes no sense.
The current default does do that. It doesn't let you choose, it just formats it and if you don't like it then good luck finding the option hidden somewhere (if you find it).

If power users want to format their own code, they will. Even if its disabled by default and they want it auto, they will figure it out.

If a newcomer to the lang wants to -not- format their code, because they are learning and used to their own ways of doing things and getting used to the new way of working... the current forced-format-default causes an unnecessary amount of frustration that basically serves no purpose.

I can even understand the not-configurable-by-design formatting choice. But... force-formatting by default is just something else.

[Isopod]

I literally just tried Zig for the first time, I copied some sample code into nvim, I type :w, and the formatting magically changes in front of my eyes. I thought I was imagining it. I undo it. Paste it again. Save. It happened again! With no information as to what is going on. It just magically changes it.

I did not even know I had a Zig language plugin installed! I never installed it. It looks like it’s shipped by default. And it just magically changes the text without asking me, without any message whatsoever, something that happens with no other programming language. I had to google this issue to figure out what is causing this and luckily I found this thread within like 5 minutes, but one might not always be so lucky. Stuff like this should never be enabled by default. This is unexpected, annoying and frustrating. Leave my text editor alone.

[zoriya]

Was as surprised as the others to see my qflist being populated/opened without asking it to or seeing my code autoformat. If this was just an opt-in plugin, I wouldn't really care, but now that zig.vim is included in both vim and neovim's default runtimes files, I do think this is intrusive behavior that should definitely not be on by default.

I also would like to note that there are now better ways to format code that won't break the undo/redo list (and that are non-blocking), so having auto-formatting that completely replace the buffer by default doesn't really make sense anymore.

[Tiseno]

This is an unreasonable default.

No other built in language support does auto formatting (or population of qflist) by default. If it were a plugin it would be fine, however it would still lie about what the scope is. From the readme:

File detection and syntax highlighting for the [zig](http://ziglang.org/) programming language.

That should be the only thing this piece of code does.

It is not only intrusive as it destroys your buffer when you did not ask for it, but it also has a performance hit on save, which is totally unreasonable as a default. This seriously made me reevaluate using neovim over vim.

How did this make it into the neovim runtime?

Edit: I realise this rant should probably be in the neovim repo, not here 😅.
As a plugin this is great 👍
The point about the readme lying is still valid though.

Edit2: Actually this plugin is included in vim as well, which is absurd.
The fastest way forward for me personally is just to compile neovim from source and remove it. But the correct course of action I think is letting this be an ide-like plugin and to implement the bare bones separately (file type and syntax) and get that included in vim instead. Would someone be interested in making that implementation? I am not proficient enough in vim script to do it the correct way.

[iovis]

The fastest way forward for me personally is just to compile neovim from source and remove it.

While I disagree with the autoformat on save being the default, you can just:

vim.g.zig_fmt_autosave = 0 # In lua
let g:zig_fmt_autosave = 0 # in vimscript

And it'll disable the behavior. No need to recompile anything.

[Tiseno]

For me its equally fast as I am already compiling from source and rather not pollute my config with options that should not exist.

BUT the real point is that I do not want BufWritePre auto commands being registered in the first place, not that I do not want auto formatting.

augroup vim-zig
    autocmd! * <buffer>
    autocmd BufWritePre <buffer> if get(g:, 'zig_fmt_autosave', 1) | call zig#fmt#Format() | endif
augroup END

That should be something a user should register themselves if they want it.
And again, this is probably ok (and good) for a plugin, but not as a default language support built into vim.

In the latest neovim release 9.4 zig is the only language that does this and has its own folder under runtime/autoload (except for xml for some reason which has some wierd stuff).
Other language roughly supplies the following (im sure there are some wierd exceptions for some languages somewhere):
filetype detection+filetype, regex based highlighting, a default compiler makeprg, and/or a default omnifunc.
No BufWritePre auto commands that I could find.

But... after some digging around I discovered, to my horror, that the rust language support also does a BufWritePre au by default in the later releases of vim and has its own folder with a bunch of stuff inherited from the https://github.com/rust-lang/rust.vim.
Before fc93594d56 (2023-09-12) it had the more sensible default to not register the auto command if the user had not explicitly opted in with the rustfmt_autosave flag, but now it always register the au command which does some wild checks for a bunch of configs before checking that flag.

[Tiseno]

As an example, go has done it exactly the way I described with
https://github.com/google/vim-ft-go
and https://github.com/fatih/vim-go

[gabrieldechichi]

Sorry for re-opening this issue, but just wanted to post yet another request for format-on-save not being the default. Similar to @Spiffyk, I was just learning zig for the first time, and was experiencing slow edits + weird behavior due to the format no save feature (I have an autosave plugin, so "save" happens every time I enter normal mode). Ended up spending 1 hour tracking down the issue. Not an ideal experience.

Of course not a big deal after I found out the zig_fmt_autosave flag, and I'm still excited to learn the language, but as this is something that can affect vim users on their very first contact with Zig, figured it would be worth raising it again.

[edrozenberg]

Same, I had zig 0.12 installed and after saving any .zig file in vim, it winds up completely reformatted. I definitely don't expect or want this behavior and it's completely surprising as well as extremely difficult to troubleshoot for any "normal" user. Uninstalling the zig 0.12 package was the only way I found make vim stop doing this terrible thing. Thanks for the tip to add let g:zig_fmt_autosave=0 to my .vimrc but imho nothing should F with and reformat my code unless I specifically ENABLE some option, esp. when this "magic" autoreformat behavior kicks in seemingly from out of nowhere ("nowhere" being visible using grep -r fmt /usr/share/vim/vim91 | grep zig) only when zig happens to be installed. In my specific case I was making a small edit to someone else's code and I wind up with dozens of changes when trying to use diff later, due to all the unexpected autoreformatting.

[Tiseno]

I have a PR for removing this behavior from the vim runtime (vim/vim#13803), but I lost a little steam as I am no vim script expert. And I couldn't really find any concrete guidelines for what the correct course of action should be, like what is the philosophy here, for instance, the rust plugin does a shit ton of things, but everything is opt-in.

To me this should all get removed, i.e. the au command and std dir setup.
And probably also from the builtin rust plugin 🤷 if a user wants those options they should install the plugin.
To me it is obvious that all built in plugins should be very minimal.

[glyh]

Putting my 1 cent here as zig fmt takes forever to complete on my end. And it's not even done in async.

[Tiseno]

FYI this is now removed from the vim and neovim runtimes vim/vim#13803

[hockeyhurd]

I might be late but this is completely ironic. Zig strives to not use hidden-control, yet the default (control) is to enforce formatting on the use (at least with neovim)...

[andrewrk]

I don't really maintain this plugin other than editing the syntax file for new keywords because I don't know vim script and I plan to never learn it, so I have no plans to tackle this issue. But @haze said he would reopen it if a lot of people want it, and it's clear that is the case, so I will click the button.

Please note that if you don't have ast-check enabled on save, you're 100% definitely doing it wrong. Format-on-save off, OK, but you absolutely need to see those quick errors on save. It's a game changer. (from the CLI that's zig ast-check foo.zig, it's instant and it only reports errors). So that should be on by default FOR SURE. If the neovim folks patched it out, they need to patch this alternative back in pronto.

congratulations to this for getting under my skin:

this is completely ironic. Zig strives to not use hidden-control, yet the default (control) is to enforce formatting on the use

🙄 c'mon man give me a break. that doesn't make any sense

[Spiffyk]

Please note that if you don't have ast-check enabled on save, you're 100% definitely doing it wrong.

I don't disagree, but there are multiple ways to get that, and there will be users who will just plop a language server in their config and be done with it. ZLS does this and more for Zig. Enabling ast-check by default will be in conflict with setups that already use ZLS.

The problem with enabling things like this by default is that there is no standardized way to disable them in (Neo)Vim, and generally, (Neo)Vim users will expect the editor to do nothing extra, unless instructed to do so by their own config. Especially when talking about behavior for specific languages (i.e. the editor does nothing like this for C, JavaScript, Go... but does for Zig - that is very surprising and hard to track down).

And (Neo)Vim doing stuff besides text editing by default will conflict with people's setups, which do get complex. It is the established culture, which may not be to everyone's taste, and that is understandable, but it is the reason why people use (Neo)Vim in the first place.

[Spiffyk]

Ah, sorry, I didn't see the last comments in vim/vim#13803, which basically imply this ziglang/zig.vim plugin has been decoupled from the default one built into (Neo)Vim. Thanks and congratulations to @Tiseno for becoming the maintainer there.

I am fully on board with the current state, with this plugin here being completely opt-in installable with whatever defaults its (future?) maintainer wishes it to have, and the built-in one only including file detection and syntax highlighting.

[hockeyhurd]

My apologies @andrewrk, it was not my intention to cause grief. TLDR; @Spiffyk explained my gripe with this behavior vs expectation just about perfectly.

I don't use auto-save features for various reasons nor any Zig related (neovim) plugins
(C/C++ and Rust only). I also agree with your points on this. However, as a new user of Zig, I was not expecting auto-formatting or "hidden control" and simply found it of annoyance as a first time experience; non of which are particular Zig's fault! Bottom-line is many (neo)vim users use (neo)vim because of its relative simplicity (once familiarized of course) and opt-in flexibility through plugins it provides. I can imagine many others wouldn't expect this in their first impression of Zig as well. Again, non of which is Zig's fault per se.

[jake-stewart]

makes my vim hang when saving a .zon file. nice one

[cyuria]

I found this issue because neovim was hanging for between 1 and 6 seconds every time I saved a .zig file. I initially tracked it down to the nvim-treesitter code folding, however there were a few issues with that.

1. The issue did not present itself with :noa w
2. My own autocommands were not the culprit (I commented them all out)
3. Reloading code folds (which is what I do after a save) is basically instant and sometimes neovim would crash during the save and my changes would be lost (not a big deal because of swap files).

These led me to check which autocommands were actually being run, and to my surprise there's an autocommand in a filetype plugin of all places. I disabled format on save and lo and behold no hanging issues (I can't reliably reproduce the crash and I'm not sure what's causing it, but that may very well be gone too). I don't know where the conflict actually is, but it'd be nice if format on save was an opt in feature, not opt out, as that would've saved me this headache that I've had for a while.

I'm happy to make a PR for this if necessary. The change should be as simple as just changing the 1 to a 0 here

zig.vim/ftplugin/zig.vim

Line 55 in 15d6510

autocmd BufWritePre <buffer> if get(g:, 'zig_fmt_autosave', 1) | call zig#fmt#Format() | endif

[Spiffyk]

@cyuria This is already fixed in upstream NeoVim master, you only need to wait for a release.

[edrozenberg]

@cyuria you can grab a pre-release from https://github.com/neovim/neovim/releases such as the latest NVIM v0.11.0-dev-1046+g25b53b593 (look under Assets for the appropriate binary for ex. nvim-linux64.tar.gz or Mac or Win or appimage etc).

[cyuria]

@Spiffyk @edrozenberg thanks I didn't notice that. My offer is still on the table if you want to change the behaviour here of course

[gusvianadev]

Just here to say that I spent like an hour thinking that conform.nvim or zls had an issue until I realized it was neovim doing autoformatting for me. Thank god it's getting removed

[meshula]

Is it getting removed? I thought the fix noted above solves the slowdown not the autosave problem?

I just reformatted a friends project and pushed it to his repo before noticing that vim had reformatted THE ENTIRE FILE not just the bits visible to me on screen when I saved.

Please consider this a plea to remove this behavior asap. Now I'm faced with rolling back the mess I made and reapplying my changes, and also messing with configurations and hoping I don't mess up again tomorrow by using a different computer and forgetting to turn off the auto-scribble feature there.

[cyuria]

Is it getting removed? I thought the fix noted above solves the slowdown not the autosave problem?

I just reformatted a friends project and pushed it to his repo before noticing that vim had reformatted THE ENTIRE FILE not just the bits visible to me on screen when I saved.

Please consider this a plea to remove this behavior asap. Now I'm faced with rolling back the mess I made and reapplying my changes, and also messing with configurations and hoping I don't mess up again tomorrow by using a different computer and forgetting to turn off the auto-scribble feature there.

This plugin/repo won't get any changes, however the version bundled with (neo)vim is being updated (idk the status of that off the top of my head).

I do wonder why you don't want the formatted zig though, as it just uses the standard zig formatter (i.e. zig fmt) that at least attempts to make zig look consistent. In my book that's only really a good thing and if you have some issue with the formatter, maybe it's better to open an issue there instead of not using the formatter?

[Tiseno]

@meshula it is removed from neovim nightly, and will be a part of the 0.11 release, I believe.
The first version of vim that has it removed is v9.1.0430

[haze]

I don't have write access to this repository anymore. I suggest someone open a PR to disable and let @andrewrk merge.

[meshula]

I do wonder why you don't want the formatted zig though,

@cyuria The answer to your question is that I need to conform to a house style that is not the same as the style zig fmt implements. For sure, it is great when everyone agrees on matters of legibility and aesthetics, for all the familiar reasons!