syntax: highlight commands following sudo-style wrappers

[ChrisJr404]

Took a stab at #692 — wasn't sure of the cleanest place to hook this in, so happy to move it if there's a better spot.

The idea is to register ble/cmdinfo/cmd:NAME/chroma for a configurable list of wrapper commands (sudo, doas, command, nohup, env, xargs). The chroma walks past wrapper-specific options (handling things like sudo -u root, env VAR=val, --) and then applies the same command-type coloring used for the head of the line to the inner command word. Nested wrappers (sudo env CMD) are followed to the innermost command.

The list is exposed as bleopt command_wrappers. Setting it to an empty string disables the behavior; users can add or remove names with bleopt command_wrappers+=name / -=name. User-defined chromas for the same names are preserved across changes to the option.

I went with hardcoded option specs per wrapper rather than tying into the existing cmdspec machinery to keep the patch self-contained. A small case covers the flag-with-arg patterns each wrapper actually uses; happy to refactor onto cmdspec/opts if that's preferable.

Manually verified against bash-5.3 with out/ble.sh:

• sudo nonexistent_xyz → second word colored as error
• sudo ls, nohup ls, command ls, env FOO=1 ls → second/third word picks up command_file / command_builtin / etc.
• sudo cd, sudo _user_function → builtin and function are highlighted correctly
• sudo -u root ls → -u root skipped, ls highlighted
• sudo env nonexistent_xyz → nested wrapper followed, innermost word colored as error
• bleopt command_wrappers= → behavior disabled, no chromas registered
• Existing bash out/ble.sh --test passes with no new failures.

Closes #692

[akinomyoga]

Thanks for the contribution.

I haven't yet finalized the chroma interface, but basically, I would like to make ble/cmdinfo/cmd:$cmd/chroma the customization point, which the user directly defines. I.e., the user can put e.g.

# bashrc

function ble/cmdinfo/cmd:sudo/chroma { ble/progcolor/command-wrapper.chroma "$@"; }
function ble/cmdinfo/cmd:doas/chroma { ble/progcolor/command-wrapper.chroma "$@"; }

...

instead of indirectly specifying that through bleopt.

However, I haven't yet concluded the entire interface. Actually, the original idea is to put the chroma settings in contrib/chroma/sudo.bash, etc. (like the chroma directory in fast-syntax-highlighting) so that the file can be loaded on the first attempt of highlighting the arguments of sudo, which is a similar mechanism as scop/bash-completion's _comp_load (or __load_completion in bash-completion <= 2.10). To disable the bundled chroma, the user can put an empty file at ~/.local/share/blesh/local/contrib/chroma/sudo.bash.

[akinomyoga]

I need time to think about the design.

[ChrisJr404]

Makes sense — the direct ble/cmdinfo/cmd:$cmd/chroma customization point is cleaner than the bleopt indirection, and the contrib/chroma/sudo.bash autoload mirrors how completions get loaded, which is a nice symmetry.

No rush from my side. I'll rework against whatever interface you settle on. If a draft of the contrib/chroma split would help inform the design, I can put one up; otherwise I'll wait for your decision on the shape.