All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Adrian Ratiu <adrian.ratiu@collabora.com>
Cc: git@vger.kernel.org,  Patrick Steinhardt <ps@pks.im>,
	 Emily Shaffer <emilyshaffer@google.com>
Subject: Re: [PATCH v2] ws: add new tab-between-non-ws check
Date: Wed, 07 Jan 2026 11:12:16 +0900	[thread overview]
Message-ID: <xmqqsecii327.fsf@gitster.g> (raw)
In-Reply-To: <20260107013051.312291-1-adrian.ratiu@collabora.com> (Adrian Ratiu's message of "Wed, 7 Jan 2026 03:30:51 +0200")

Adrian Ratiu <adrian.ratiu@collabora.com> writes:

> The check is a bit complex because we want to detect places where
> a SP was intended (HT can expand to more than one display column),
> so we need to count both the display columns (col) and the string
> character columns (i) to determine if a HT looks identical to a SP
> or can cause confusion.
>
> +/....adoc text eol=lf whitespace=trail,space,incomplete,tab-between-non-ws

The name of the whitespace rule does not quite match what we want to
catch.  Can somebody find a phrasing than "between non-ws" that
conveys our intent better?  We want to catch a tab that is used by
mistsake when the writer would have used a space, and "between
non-ws" is one of the heuristics (another is "it is at the 7th
column to make it indistinguishable from a space") the code uses to
tell if a tab is such a mistaken tab.   "tab-instead-of-space"?
"tab-in-place-of-space"?  "tab-that-should-have-been-a-space"?

The last one is horrible and not a serious suggestion, of course.

> +test_expect_success 'check tab between non-whitespace (tab-between-non-ws: off)' '
> +	git config core.whitespace "-tab-between-non-ws" &&
> +
> +	printf "1234567\tb" >x &&

I notice all these printf create incomplete lines.  It is true that
the detection of a tab that is used when it should have been a space
should work even on an incomplete line, but using an incomplete
line, which is of course rather unusual, for these tests gives a
false impression that somehow this requires an incomplete line to
trigger, which is not what we want to give.

	printf "1234567\tb\n" > x &&

or something, perhaps?  I dunno.

  reply	other threads:[~2026-01-07  2:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-07  1:30 [PATCH v2] ws: add new tab-between-non-ws check Adrian Ratiu
2026-01-07  2:12 ` Junio C Hamano [this message]
2026-01-07 11:34   ` Adrian Ratiu
2026-01-07 17:33 ` Johannes Sixt
2026-01-07 18:11   ` Adrian Ratiu
2026-01-08  8:36     ` Johannes Sixt
2026-01-08  9:01   ` Johannes Sixt
2026-01-09 13:33     ` Adrian Ratiu

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=xmqqsecii327.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=adrian.ratiu@collabora.com \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=ps@pks.im \
    /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.