Allow exact terminal sizing with a visible sidebar

[isachivka]

Problem

External controllers can resize an agterm window, but they cannot always fit the terminal to an exact number of columns while keeping the sidebar visible.

One concrete case is a mobile client that asks the controller to fit the terminal to 45 columns:

• sidebar width: 220.4 pt
• minimum window width: 640 pt
• narrowest achievable terminal: 47 columns

After manually dragging the sidebar to 271.3 pt, the same controller can reach 45 columns. Hiding the sidebar also works, but changes the intended layout.

Possible approaches

1. Expose the sidebar width through the control API

Add a command such as:

agtermctl sidebar width <points> [--window W]

It could:

• target the frontmost window by default and accept the existing --window selector
• validate the value against the same 160...560 pt limits as manual dragging
• persist the applied width through the existing window snapshot
• expose sidebarWidth in tree or window list --json so callers can read back the value

This would keep terminal fitting logic in external controllers while exposing the missing layout primitive.

2. Lower or remove the 640 pt minimum window width

The other option is to revisit .frame(minWidth: 640, minHeight: 400) in agterm/agtermApp.swift. The 640 pt constraint is what prevents the controller from making the window narrow enough in this case. Lowering or removing it could solve the problem without adding a new control command.

What is the reason for the 640 pt minimum? Does it protect a specific UI or terminal-layout invariant, and is it still required? If it is not required, allowing narrower windows may be the simpler fix.

Which direction fits agterm better?

[umputun]

it fits the direction, and it is in now: merged as #512, so it will be in the next release.

agtermctl sidebar width <points> [--window W], close to what you proposed. Sidebar width was already persisted per window and adjustable by dragging, but had no command or read-back. Exposing that existing primitive is what the control API is for.

a few decisions worth knowing, since they affect how you drive it:

points, not columns. agterm reports no column count and does not convert for you. This is deliberate. #281 tried exact cols/rows sizing for overlays and was dropped because its benefit did not justify the added complexity, especially around cell metrics, split and reparented layouts, state read-back, and UI testing. Your controller measures its own grid and corrects.

the width is a Double. The drag writes a fractional cursor x, so an Int could not express every width the sidebar can actually reach, and your 271.3 would not survive a round trip.

the command clamps to 160...560pt, persists the stored width, and echoes it after clamping. That is how you tell a clamped request from an honored one, since both answer ok. Compare numerically rather than as strings: the value is a double, so 300 comes back 300.0.

the command targets the frontmost window by default; --window W selects any open window. Read-back is the tree's top-level sidebarWidth only. window list does not carry it, so use tree --window W for a specific window.

your arithmetic was right and made the gap easy to confirm. Thx for the precise report.