linux-kernel - Re: [PATCH] nconfig: add search support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100806135429.GB25864@merkur.ravnborg.org>
Date:	Fri, 6 Aug 2010 15:54:29 +0200
From:	Sam Ravnborg <sam@...nborg.org>
To:	Nir Tzachar <nir.tzachar@...il.com>
Cc:	Randy Dunlap <randy.dunlap@...cle.com>, mmarek@...e.cz,
	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] nconfig: add search support

> >>
> >> Searching: pressing '/' triggers search mode. nconfig performs a
> >>            regular string compare, case insensitive, starting at
> >
> > I would say: simple string compare
> > "regular" has no meaning (at least for me) there.

pressing '/' triggers interactive search mode. nconfig search for the
string in the menu prompts (no regex support).

[Just a suggestion for a bt different wording]

> > Maybe I should just stick to config symbol searches.  I don't think it's all
> > that likely that people will know how each menu line text begins.
> >
> >
> 
> We can replace strcasecmp with strcasestr. I agree it would be more useful.

This is better.

> 
> > As for the search UI, I'd rather that it be presented like the symbol search,
> > in a box, instead of just a single line at the top of the screen.
> 
> But then it is not interactive. I was aiming for something similar to
> vim's search, where the search is matched as you type and the only
> free terminal real-estate to display the match string was at the top
> of the screen. I think such a minimal design is better than a
> cumbersome text box which displays the search results afterwards (as
> is symbol search), as the search is only intended for the currently
> displayed menu and the user would usually just want to save the extra
> typing of navigating to a specific menu item.

It was introduced to replace the "hotkey" support, and as such is useful.
If we want to search for content of all prompts then we should extend
the symbols search to do so.
Maybe we should just let it search for both symbols _and_ propmts.

If one search for HOTPLUG_CPU there is no hits in any propmts anyway.
And if one search for "Pentium" there is no config symbol hits.

	Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/