From: Thomas Nemeth <tnemeth@free.fr>
To: Ben Knoble <ben.knoble@gmail.com>, git@vger.kernel.org
Subject: Re: Git trailing blank lines feature configuration
Date: Sat, 01 Aug 2026 10:48:11 +0200 [thread overview]
Message-ID: <3433010.aeNJFYEL58@cixi> (raw)
In-Reply-To: <06230920-FCA6-495C-BFE5-04DF1CC2A426@gmail.com>
Le samedi 1 août 2026, 02:05 Ben Knoble a écrit :
> > Le 31 juil. 2026 à 20:55, Thomas Nemeth <tnemeth@free.fr> a écrit :
> >
> > I wouldn't say necessary, of course. It's -- at least -- my
> > preference. For _my_ use case, it's useful. When I move code
> > around, and that code is at the end of the file or to be put
> > at the end of the file, I find it easier to already have a
> > blank line there. That is... Because that's how I use vim to
> > code.
>
> I use Vim, too, and I’ve not personally encountered the desire for
> keeping a blank line at EOF (though occasionally certain operations
> benefit from placing one there first!).
>
> I wonder if you could describe example workflows that lead to this
> desire? I might learn something, and in exchange, if I see a way to
> accomplish the same thing with less hassle, I’ll suggest it ;)
It's hard to describe something like that :)
Imagine you are editing a C file. It contains functions, code blocks
an so on. I usually organize my code as such :
#includes
[...]
#defines
[...]
static variables
[...]
static functions()
[...]
public_functions()
[...]
Code reorganization happens quite some times during the development
process.
If I need to move a previously static function at the end of the
public functions section, I switch to VISUAL, select the function
to be moved with the blank lines above (I like having neatly spaced
code) _and_ including the eol of the function last line.
Then I delete it (d), I move to EOF (:$). As the line is blank I
just have to paste (p) it back there. The function is moved. The last
blank line is kept for other code movements.
Conversely, I can select the last function to move it upper in the
file.
Adding new functions is also eased. It may be because I use only a
few vim commands (especially I rarely use the `o` command). But also
because I like spaced code :)
--
Thomas.
next prev parent reply other threads:[~2026-08-01 8:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 10:19 Git trailing blank lines feature configuration Thomas Nemeth
2026-07-31 11:08 ` Johannes Sixt
2026-07-31 11:50 ` Thomas Nemeth
2026-08-01 0:05 ` Ben Knoble
2026-08-01 8:48 ` Thomas Nemeth [this message]
2026-08-01 21:05 ` Johannes Sixt
2026-08-02 8:21 ` Thomas Nemeth
2026-07-31 18:49 ` Junio C Hamano
2026-08-01 8:21 ` Thomas Nemeth
2026-07-31 15:50 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3433010.aeNJFYEL58@cixi \
--to=tnemeth@free.fr \
--cc=ben.knoble@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.