Hi DJ,

> Date: 2026-08-06 16:17:36-0400
> From: DJ Delorie <dj@redhat.com>
>
> Alejandro Colomar <alx@kernel.org> writes:
> 
> > Hmmmm, let's see.  I couldn't do it in five words, but how about this
> > schematic approach?
> >
> > 	The file may also contain
> > 	.IR filters ,
> > 	which limit the tunables following it,
> > 	The effects of a filter are terminated by
> > 	any of the following:
> > 	.IP \[bu] 3
> > 	The end of the file.
> > 	.IP \[bu]
> > 	The end of an included file.
> > 	.IP \[bu]
> > 	An
> > 	.B include
> > 	directive.
> > 	.IP \[bu]
> > 	A new (possibly empty) filter.
> 
> I like it as-is, other than "why are there blank lines" but I don't care
> about that ;-)

We can compact them.  ;-)

	The file may also contain
	.IR filters ,
	which limit the tunables following it,
	The effects of a filter are terminated by
	any of the following:
	.PD 0
	.IP \[bu] 3
	The end of the file.
	.IP \[bu]
	The end of an included file.
	.IP \[bu]
	An
	.B include
	directive.
	.IP \[bu]
	A new (possibly empty) filter.
	.PD

(I haven't tested; I've written it in the mail editor directly)

> > Since a filter can be empty, we should document that.  If we document
> > that 'filter:pattern' is optional, it'd be [[filter:pattern]] (with the
> > appropriate formatting differences: the inner '[' wouldn't be bold).
> > However, that's likely to be confusing, so let's document that
> > separately:
> >
> > 	A filter can also be empty:
> > 	.BR [] .
> > 	Such a filter has no effects.
> 
> Done.  I put it after the filter list, so the "also" made sense.

Thanks!


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>