Re: vim autoformat ?

27 views
Skip to first unread message
Message has been deleted

M

unread,
May 27, 2023, 12:32:48 PM5/27/23
to vim...@googlegroups.com

сб, 27 мая 2023 г., 18:31 Igor Lerinc <igor.l...@gmail.com>:
I can't wrap my head around Vim autoformat at all. 
I want to have autoformat on save feature. 
I don't want it to have delays, so when i press `:w` it immediatelly saves and formats indentation properly.

I have no idea what is going on in (neo)Vim discussions about this autoformating. Looks like those people never coded in their life, and never do any useful thing with their godly configs other than to brag.

Using Vim feature `gg=G` i format and indent whole file. 
This is what I want to have, but discussions related to this are so complicated. They just say 'look at my config', but I have no idea, what is that I should look into his config, or just copying his whole config with a lot of bloat. 

Please help. 

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/961e2663-4abb-46d7-aabe-c5be9ac94498n%40googlegroups.com.

Basically, you need to catch BufWritePre event and do whatever it takes to format file there.

However, note that such "auto-features" quickly become very annoying, so think twice on what conditions to apply or to bypass it.

Kind regards,
Matvey

Enan Ajmain

unread,
May 27, 2023, 1:02:35 PM5/27/23
to Igor Lerinc, M, vim...@googlegroups.com
On Sat, 27 May 2023 19:32:31 +0300
M <matthew...@gmail.com> wrote:
> ____, 27 ______ 2023 __., 18:31 Igor Lerinc <igor.l...@gmail.com>:
> > [...]
> > I have no idea what is going on in (neo)Vim discussions about this
> > autoformating. Looks like those people never coded in their life.
>
> [...]
> However, note that such "auto-features" quickly become very annoying, so
> think twice on what conditions to apply or to bypass it.

Igor: I second Matvey's caution. If you are working on a project that
has an autoformat tool which all contributors are supposed to be using,
e.g., uncrustify, then autoformatting could possibly be useful. But if
you're working on a project that imposes no such formatting guideline,
then auto formatting code someone else wrote, which doesn't concern the
logic you're coding in a particular commit, is at best unhelpful for the
other contributors. And I mention other contributors because judging by
your comments such as "Looks like those people never coded in their
life," it's reasonable to expect you code in projects with multiple
people, not just yourself.

And as for a suggestion to your original question: see ':h formatprg',
':h formatoptions', ':h formatexpr', etc.


--
Enan

Salman Halim

unread,
May 27, 2023, 2:16:49 PM5/27/23
to Vim Users, Igor Lerinc, M

On Sat, May 27, 2023, 13:02 Enan Ajmain <3nan....@gmail.com> wrote:

Igor:  I second Matvey's caution.  If you are working on a project that
has an autoformat tool which all contributors are supposed to be using,
e.g., uncrustify, then autoformatting could possibly be useful.  But if
you're working on a project that imposes no such formatting guideline,
then auto formatting code someone else wrote, which doesn't concern the
logic you're coding in a particular commit, is at best unhelpful for the
other contributors.  And I mention other contributors because judging by
your comments such as "Looks like those people never coded in their
life," it's reasonable to expect you code in projects with multiple
people, not just yourself.

And as for a suggestion to your original question: see ':h formatprg',
':h formatoptions', ':h formatexpr', etc.


--
Enan

The other problem with reformatting an entire file is that you lose history. Git, for example, has a feature called blame (or credit, depending on your frame of mind) that will tell you the last person who modified each line and the corresponding git commit, which is useful if you have questions about a particular block of code and want to know whom to ask. If you reformat the entire file, though, then it will appear as if you wrote the entire file. Regrettably, this isn't just hypothetical: I've occasionally asked a developer about some code only to be told that they only reformatted it to make it pretty and can't actually explain what it's doing.

A better solution would be for you to figure out exactly which lines you've changed and only operate on those. I did recently write something in Vim9 to do this and use it to strip trailing spaces and things like that, but only from lines I've added or modified. (Back when I wrote it, I asked if there was any interest and no one expressed any, so it's not really in a state where it's ready to be consumed by other people as a proper plugin.)

Salman

Bram Moolenaar

unread,
May 27, 2023, 5:22:43 PM5/27/23
to vim...@googlegroups.com, Igor Lerinc

> I can't wrap my head around Vim autoformat at all.
> I want to have autoformat on save feature.
> I don't want it to have delays, so when i press `:w` it immediatelly saves
> and formats indentation properly.
>
> I have no idea what is going on in (neo)Vim discussions about this
> autoformating. Looks like those people never coded in their life, and never
> do any useful thing with their godly configs other than to brag.
>
> Using Vim feature `gg=G` i format and indent whole file.
> This is what I want to have, but discussions related to this are so
> complicated. They just say 'look at my config', but I have no idea, what is
> that I should look into his config, or just copying his whole config with a
> lot of bloat.
>
> Please help.

To get you started:

au FileType pascal au BufWritePre <buffer> * normal gg=G

This will add a BufWritePre autocommand to a buffer where 'filetype' is
set to "pascal". You probably want to ehance this. E.g. add an augroup,
so you can delete the autocommand again.

Although this is what you asked for, you probably soon find out that
formatting text only when editing it works better. Formatting the whole
file may mess things up without you noticing.

--
From "know your smileys":
:-) Funny
|-) Funny Oriental
(-: Funny Australian

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Igor Lerinc

unread,
May 27, 2023, 11:54:54 PM5/27/23
to Bram Moolenaar, vim...@googlegroups.com
But what about plugins like 


That use some external formatters.



I find them slow, because it need to start program when called from Vim.
And they say, it means you need to have some type of service running on your system.
Like for 'prettier', you need 'prettierd' to not have lag when calling it. 

But I tried to setup 'prettierd', and got lost. 

And there is also some efm-langserver , which they say is fastest, because it formats only lines that need to be formatted (if I understood correctly). 
But I just have no idea what to do with this, how to install it, how to connect it to other external formatters, Vim plugins.. 

https://github.com/mattn/efm-langserver


Vim-autoformat have explanation how to setup. But as I said, it takes time to start up program, so it already need to be running, using some sort of something, like efm-langserver ?

I don't know really how to do this.
I just want to have code more readable.




Owajigbanam Ogbuluijah

unread,
May 28, 2023, 12:53:51 AM5/28/23
to vim...@googlegroups.com, Bram Moolenaar
Hey Igor,

Formatting in Vim is pretty simple. Vim already understands how to format many filetypes. Try not to use too many plugins to complicate things; especially if you're not mandated or forced to.

I'll second what Bram, and the others, said here earlier.

You can start by formatting the entire file gg=G and checking that into Git. Subsequently, when you code, you can format-as-you-go. Remember = can take motions as well :help = has more details.

p.s: the "motions" bit means you can do something like =ip to format the lines in a code block

All the best,
Igbanam

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.

Igor Lerinc

unread,
May 28, 2023, 3:36:19 AM5/28/23
to vim...@googlegroups.com, Bram Moolenaar
So if I understood correctly, external tools won't help me more than Vim already has ?
Specifically, here is an example, for some use case, where I would need a formatter to fix ? 
Or another, extreme example, or cluttered code. 

Because I always thought of just writing code, in line, and then leaving editor format the rest, so I don't have to worry about readability . 
Of course, that doesn't replace improper usage of indentation or blocks of code (like, for python it needs to have good indentation to work in the right way). 
But it could help, if it at least helped when I write code inline, for it to format, as it sees fit. Not changing the meaning of code, just for readability, how much language allows of course.

First example uses .yaml, and sometimes it can change the meaning of a file, by indenting it, as you know for .yaml files.. 


You received this message because you are subscribed to a topic in the Google Groups "vim_use" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/69sd3p5DVlM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_use+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAOmRJreAjb0Omvs%3D8Z757rT-%3DeZHZLc6O1aRtPUAUrgXjbqrRA%40mail.gmail.com.

aro...@vex.net

unread,
May 28, 2023, 9:57:02 AM5/28/23
to vim...@googlegroups.com

If it's Perl code, there's a utility called perltidy, which is stand-alone.

BTW, I suspect that Bram monitors vim-use, so cc-ing him just means he'll
get two copies of the message.

Bram Moolenaar

unread,
May 28, 2023, 1:22:40 PM5/28/23
to vim...@googlegroups.com, aro...@vex.net

> BTW, I suspect that Bram monitors vim-use, so cc-ing him just means he'll
> get two copies of the message.

So long as it's one message sent to different mail addresses, the
Message-ID field will be equal and they can be de-duplicated easily.

--
From "know your smileys":
O:-) Saint

Enan Ajmain

unread,
May 29, 2023, 1:32:28 AM5/29/23
to Igor Lerinc, vim...@googlegroups.com, Bram Moolenaar
On Sun, 28 May 2023 09:35:00 +0200
Igor Lerinc <igor.l...@gmail.com> wrote:
> So if I understood correctly, external tools won't help me more than
> Vim already has ?
> On Sun, May 28, 2023 at 6:53 AM Owajigbanam Ogbuluijah
> <xigb...@gmail.com> wrote:
>
> > Hey Igor,
> >
> > Formatting in Vim is pretty simple. Vim already understands how to
> > format many filetypes. Try not to use too many plugins to
> > complicate things; especially if you're not mandated or forced to.

I agree with what Owajigbanam said, except external tools not helping.
First, Vim is great _because_ it can interface with any commandline
tools so effortlessly. And if there is a tool that specialize in
something, you _should_ use that. You will still be able to use the
'={motion}' keys, but underneath Vim will call the external tool (that's
what ':h formatprg' exists for). I understand your reservations about
not wanting to spawn new processes, but most commandline tools are tiny
and consume virtually no resource at all.

Vim takes time to familirize with. Be patient and go through the help
docs. That would be better than asking people broad questions such as
how formatting in Vim works, because everyone is at different level of
understanding and no one knows from which level to talk to you. If the
question is specific, e.g., how do I open a new tab?, then that's fine to
ask the next person instead of going through the manual. But if the
question is broad, e.g., how does formatting work? or how do jumplists
work?, then you'd do better reading the manual.

So I suggest again as --
Reply all
Reply to author
Forward
0 new messages