More friendly /set string<CR> behaviour. #20

Merged
merged 2 commits into from Jan 26, 2012

Projects

None yet

2 participants

@Enlik
Contributor
Enlik commented Dec 5, 2011

If one types:
/set log
all settings that contain "log" are displayed.

If a user wants to change a setting and doesn't remember option name, he doesn't often want to look at the documentation or do "/set" and an eye-grep to find it, or whatever.
This commits makes it easy to find wanted option. It works for me without problems.

Please take a look and consider applying it.

@Enlik Enlik More friendly /set string<CR> behaviour.
If one types:
/set log<CR>
all settings that contain "log" are displayed.
52f8344
@pawelz
pawelz commented on 52f8344 Dec 8, 2011

/set blablabla
00:06:14 ::: Unknown variable: blablabla

This error message is confusing. It should say something like "No variable name matches 'blablabla'".

@Enlik
Contributor
Enlik commented Dec 17, 2011

Thanks a lot for the suggestion! This commit improves the message. Also I've found a little issue which is now fixed too: /set beep 1 should display the new value for "beep" only and not all variables that contain string "beep" in their name.

I have another idea for this, though. Maybe instead of matching a substring we could provide wildcard matching (for example "[asterisk]size", "backlog[asterisk]")? Glib would make it easy.
(It would also mean it won't be backported to 0.3.x series. I don't know if you are interested in such feature there - if yes then this current approach could be implemented there instead.)

@pawelz
Collaborator
pawelz commented Jan 9, 2012

I really like substring matching. IMO it is much better user experience than glob matching.

@Enlik
Contributor
Enlik commented Jan 26, 2012

Anything else?

@pawelz pawelz merged commit c979a96 into ekg2:master Jan 26, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment