From: Sam Ravnborg <sam@ravnborg.org>
To: Jan Engelhardt <jengelh@medozas.de>
Cc: Nir Tzachar <nir.tzachar@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-kbuild@vger.kernel.org
Subject: Re: nconfig v7
Date: Sun, 13 Dec 2009 12:55:46 +0100 [thread overview]
Message-ID: <20091213115546.GA10592@merkur.ravnborg.org> (raw)
In-Reply-To: <alpine.LSU.2.01.0912131118280.28039@obet.zrqbmnf.qr>
> >As far as colrs are involved, I think it is best to not impose any
> >color scheme. You can never satisfy everyone, and will get into
> >endless fights about which is best.
>
> Well, menuconfig seems to have had the least fights. There was exactly
> one color scheme imposed, and that did not change for years; when themes
> were added, not much happened. There was a bit of discussion and
> submissions about themes (including myself), but in the end, it was
> sort-of agreed upon that four were enough. And they seem to work for
> everybody.
I also would like the current (menuconfig) defautl color scheme to be used.
> >Thanks for catching this. It is a by-product of the code for
> >presenting everything inside a single menu. Easily fixed in the next
> >version. By the way, is anyone using this option at all? It would much
> >simplify the code if I did not have to support the one giant menu
> >option.
>
> Well nconfig is the first to provide that option. (Note: I don't use
> gconfig or xconfig, so I cannot tell if they have something like that.)
> So to see whether there is use, you would have to wait a number of
> kernel releases that have nconfig integrated.
We already have:
Optional personality available
. ------------------------------
. If you prefer to have all of the kernel options listed in a single
. menu, rather than the default multimenu hierarchy, run the menuconfig
. with MENUCONFIG_MODE environment variable set to single_menu. Example:
.
. make MENUCONFIG_MODE=single_menu menuconfig
.
. <Enter> will then unroll the appropriate category, or enfold it if it
. is already unrolled.
. Note that this mode can eventually be a little more CPU expensive
. (especially with a larger number of unrolled categories) than the
. default mode.
But I do not think it is much used.
Sam
next prev parent reply other threads:[~2009-12-13 11:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-11 19:55 Jan Engelhardt
2009-12-12 11:37 ` Michal Marek
2009-12-13 7:23 ` Nir Tzachar
2009-12-13 11:09 ` Jan Engelhardt
2009-12-13 11:55 ` Sam Ravnborg [this message]
2009-12-13 14:25 ` Jan Engelhardt
2009-12-13 17:28 ` Sam Ravnborg
2009-12-14 5:34 ` Nir Tzachar
2009-12-14 5:39 ` Nir Tzachar
2009-12-14 5:41 ` Nir Tzachar
2009-12-14 12:26 ` Jan Engelhardt
2009-12-14 13:45 ` Nir Tzachar
2009-12-14 13:51 ` Jan Engelhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091213115546.GA10592@merkur.ravnborg.org \
--to=sam@ravnborg.org \
--cc=jengelh@medozas.de \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nir.tzachar@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®