Re: [PATCH] kconfig: wrap long expressions in menuconfig

[Julian Braha <julianbraha@gmail.com>]

On 10/11/26 17:20, Miguel Ojeda wrote:
> On Sat, Oct 10, 2026 at 11:50 AM Julian Braha <julianbraha@gmail.com> wrote:
>> In an offline conversation, Miguel Ojeda reported that scrolling
>> horizontally in menuconfig's search to read RUST's dependencies has been
>> slowing down debugging.
> Thanks for working on this!
> 
> This is definitely useful, because users (and ourselves) have had to
> scroll horizontally too much for `CONFIG_RUST` 🙂

Yeah the feedback I got from everyone I showed this to at LPC was, "any
form of wrapping is better than horizontal scrolling."
> Maybe it could help to clarify here that "debugging" above means
> understanding by users (i.e. not developers) why the dependencies are
> not satisfied. `menuconfig`'s search is uniquely useful because it
> shows the expressions with the current values; i.e. this is useful for
> most users dealing with long configs like `RUST`'s.
> 
> Is this patch the live one you showed me back in the conference?

Sort of, the version I showed at LPC was completely vibe-coded, so I
could quickly get feedback on the visuals.

This patch still creates that same visual look, but I've cleaned up the
code.

> 
> By the way, for context and future reference before I forget, I
> suggested a few other bits:
> 
>   - Wrapping on the top-level `&&` operators.

I personally liked this style when I tried it, but another maintainer at
LPC didn't: "I want menuconfig to take advantage of the full size of my
screen."

> 
>   - Even better, wrapping on the actual `depends on` lines, rather
> than every top-level `&&`, because sometimes they are logically
> grouped, even if they may use themselves `&&` for the condition. But
> IIRC we discussed that this would require tracking more state and/or
> reworking part of the parser.

Right, that would be a much larger change. I do intend to iterate on
this in the future, but wanted to start with something minimal.

> 
>   - For completeness, I also mentioned potentially considering to show
> (a subset of) attached comments, but that is not really needed and it
> is really low hanging fruit that is most likely not worth its
> complexity: we already have descriptions and most options are not as
> complex as `RUST`'s.

This idea turned out to be controversial. Another maintainer pointed out
that you don't always know exactly which lines the comment refers to.

Anyway, thanks for your feedback!

- Julian Braha