adaptive height is not compatible with top/bottom percent pa

Error message

adaptive height is not compatible with top/bottom percent padding

What it means

Same circular-sizing constraint as percent margins, but for padding: with adaptive height, top/bottom percent padding cannot be resolved because both depend on the final height fzf is trying to compute. The check at options.go:3652 fires when opts.Height.auto is active and opts.Padding[0] or opts.Padding[2] is a percent sizeSpec.

Source

Thrown at src/options.go:3652

		if len(runes) > 2 {
			return errors.New("--scrollbar should be given one or two characters")
		}
		for _, r := range runes {
			if uniseg.StringWidth(string(r)) != 1 {
				return errors.New("scrollbar display width should be 1")
			}
		}
	}

	if opts.Height.auto && (opts.Tmux == nil || opts.Tmux.index < opts.Height.index) {
		for _, s := range []sizeSpec{opts.Margin[0], opts.Margin[2]} {
			if s.percent {
				return errors.New("adaptive height is not compatible with top/bottom percent margin")
			}
		}
		for _, s := range []sizeSpec{opts.Padding[0], opts.Padding[2]} {
			if s.percent {
				return errors.New("adaptive height is not compatible with top/bottom percent padding")
			}
		}
	}

	if opts.Theme.Nth.IsColorDefined() {
		return errors.New("only ANSI attributes are allowed for 'nth' (regular, bold, underline, reverse, dim, italic, strikethrough)")
	}

	if opts.BorderShape == tui.BorderInline ||
		opts.ListBorderShape == tui.BorderInline ||
		opts.InputBorderShape == tui.BorderInline ||
		opts.Preview.border == tui.BorderInline {
		return errors.New("inline border is only supported for --header-border, --header-lines-border, and --footer-border")
	}
	if opts.HeaderBorderShape == tui.BorderInline &&
		opts.HeaderLinesShape != tui.BorderInline &&
		opts.HeaderLinesShape != tui.BorderUndefined &&
		opts.HeaderLinesShape != tui.BorderNone {

View on GitHub (pinned to bd4efa277b)

Solutions

Use absolute padding values for top/bottom with adaptive height (e.g. --padding=2,4,2,4)
Or use a fixed --height so percent padding is computable
Audit shared config files for percent padding when switching to --height=~…

Example fix

# before
fzf --height=~80% --padding=5%,2,5%,2
# after
fzf --height=~80% --padding=2,2,2,2

Defensive patterns

Strategy: validation

Validate before calling

// Shell: absolute top/bottom padding for adaptive height
case "$height" in '~'*) padding='1,2,1,2' ;; esac
exec fzf --height="$height" --padding="$padding"

Prevention

Use absolute padding values whenever --height starts with '~'
Audit shared themes for percent padding before enabling adaptive height
Left/right percent padding remains fine; only top/bottom conflict

When it happens

Trigger: Combining --height=~80% with --padding=5%,0,5%,0 (or any --padding where the first or third value ends in '%').

Common situations: Theme/config presets that use percent padding being reused with adaptive height; users assuming padding and margin follow different rules.

Related errors

AI-assisted analysis of junegunn/fzf@bd4efa277b (2026-08-15). Data as JSON: /api/errors/4ebf3fc5860e8d5e. Report an issue: GitHub.