| Summary: | [option=--misspell-suggestion] >=sys-portage/portage-2.1.9.42 | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Samuel Bauer <samuel.bauer> |
| Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | tom |
| Priority: | Normal | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 358927 | ||
| Attachments: |
Simply add a test to check if the user wants to compute and output misspell sugestions
Include documentation, and new constant added misspell-suggetions to make.globals, used git diff to generate the patch corrected mistakes in make.conf man page Added misspell-suggestion as a command line option rather than a feature Added misspell-suggestion as a command line option rather than a feature Added misspell-suggestions to emerge manual emerge: --mispell-suggestion option |
||
|
Description
Samuel Bauer
2011-04-11 17:47:16 UTC
Somewhat related to original topic: I've noticed an interesting quirk of that feature: if you're on stable and the whole package you want to emerge is not, then it's misdetected as not existent (and candidates given). Should probably just report "all not keyworded/masked" instead. Unfortunately, I've seen that awhile ago and no longer remember a specific package to reproduce. Created attachment 269685 [details, diff]
Simply add a test to check if the user wants to compute and output misspell sugestions
This patch is only a preliminary step
2 -> The feature needs to be registered
3 -> The feature needs to be documented (man pages, API doc, etc...)
4 -> A new must be available for the user when he emerge the ebuild
And maybe more steps. (It's first time I suggest something for portage, so let me know)
(In reply to comment #2) > Created attachment 269685 [details, diff] > Simply add a test to check if the user wants to compute and output misspell > sugestions Looks good. > > This patch is only a preliminary step > > 2 -> The feature needs to be registered It needs to be added to SUPPORTED_FEATURES in pym/portage/const.py. > 3 -> The feature needs to be documented (man pages, API doc, etc...) It needs to be documented in man/make.conf.5. > 4 -> A new must be available for the user when he emerge the ebuild I don't get what this means. > And maybe more steps. (It's first time I suggest something for portage, so let > me know) It appears as if you patched your installed portage. Take a look at [1]. It describes how to get a git checkout and how to run emerge from this checkout. You can then use git to create patches. [1] http://www.gentoo.org/proj/en/portage Created attachment 269691 [details, diff]
Include documentation, and new constant
Sorry, the first patch was as you said, made with my installed portage.
This one is made with diff -u --recursive, I just modified the things from a freshly uncompressed archive.
constant has been added in const.py
man page has been documented (though my english is poor)
If I use git to make the same patch, should I submit it again ?
(In reply to comment #3) > > 4 -> A new must be available for the user when he emerge the ebuild > > I don't get what this means. > I just mean there should be an information available through pkg_postinst or eselect news. Thus the ebuild needs also to be modified. (In reply to comment #4) > Created attachment 269691 [details, diff] > Include documentation, and new constant > > Sorry, the first patch was as you said, made with my installed portage. > > This one is made with diff -u --recursive, I just modified the things from a > freshly uncompressed archive. > > constant has been added in const.py > > man page has been documented (though my english is poor) s/valids packages name/valid package names/ I actually forgot something. It should be added to FEATURES in cnf/make.globals to enable it by default. > > If I use git to make the same patch, should I submit it again ? That would be neat. > I just mean there should be an information available through pkg_postinst or > eselect news. Thus the ebuild needs also to be modified. No, we don't announce stuff like this in the ebuild. If it annoys people enough they learn it from the man page or forums, etc. Created attachment 269699 [details, diff] added misspell-suggetions to make.globals, used git diff to generate the patch (In reply to comment #6) > s/valids packages name/valid package names/ Thanks, my english is poor, but we would use same structure in my native tongue (-1) (In reply to comment #6) > I actually forgot something. It should be added to FEATURES in cnf/make.globals > to enable it by default. I added it to make.globals but the heart wasn't there. This new feature makes me vomit (even I was happy to learn such algorithms at school): 1) Lot of people don't want tooltips (especially when use a shell, else .b.nt. is very attractive s/\./u/) 2) This is cpu greedy and not to be recommended for old configs. 3) The way to include it by default breaks the old behavior. (In reply to comment #6) > No, we don't announce stuff like this in the ebuild. If it annoys people enough > they learn it from the man page or forums, etc. never mind. (In reply to comment #7) > Created attachment 269699 [details, diff] > added misspell-suggetions to make.globals, used git diff to generate the patch > I suggest the following work flow: a) Modify the branch 'master' (that's where you start) (see git branch) b) Create a new branch and switch to it: git checkout -b my-fancy-new-feature c) Do a commit git commit -a d) Create a patch git format-patch master This will create a patch against the master branch e) You can now switch back to master and start working on the next thing git checkout master > (In reply to comment #6) > > s/valids packages name/valid package names/ > Thanks, my english is poor, but we would use same structure in my native tongue > (-1) The spelling is not corrected in the current patch. > > (In reply to comment #6) > > I actually forgot something. It should be added to FEATURES in cnf/make.globals > > to enable it by default. > I added it to make.globals but the heart wasn't there. This new feature makes > me vomit (even I was happy to learn such algorithms at school): > 1) Lot of people don't want tooltips (especially when use a shell, > else .b.nt. is very attractive s/\./u/) > 2) This is cpu greedy and not to be recommended for old configs. > 3) The way to include it by default breaks the old behavior. > It's actually disk bound. Some people like it, some hate it. It comes really handy if you don't have to find out yourself that foobar is actually named fooBar or foobar2. (In reply to comment #8) > I suggest the following work flow: > a) Modify the branch 'master' (that's where you start) (see git branch) > b) Create a new branch and switch to it: > git checkout -b my-fancy-new-feature > c) Do a commit > git commit -a > d) Create a patch > git format-patch master > This will create a patch against the master branch Done > (In reply to comment #6) > > s/valids packages name/valid package names/ > The spelling is not corrected in the current patch. I was thinking I made a mistake in the bugzilla messages. > It's actually disk bound. Some people like it, some hate it. It comes really > handy if you don't have to find out yourself that foobar is actually named > fooBar or foobar2. I have to admit in some situation it can be handy, but it's even better if the user can fine tune the behavior. Lot of times I did some request like: emerge -S "the feature", but in some package the description is "the-feature". When I explicitely query I would like to be able to perform fuzzy query, so would be nice to have an independent tool (qsuggests). May be it can it give some sense to the last point of the suggested workflow. (In reply to comment #9) > > > (In reply to comment #6) > > > s/valids packages name/valid package names/ > > The spelling is not corrected in the current patch. > > I was thinking I made a mistake in the bugzilla messages. No, in the description in make.conf. Created attachment 269729 [details, diff]
corrected mistakes in make.conf man page
Should put last message content here.
A possible alternative approach would be to allow the user to set EMERGE_DEFAULT_OPTS="--misspell-suggestions=n" in make.conf. For things that are only exist in the emerge interface, I typically use an option like this, and I reserve FEATURES for flags that need to affect all portage tools and portage API consumers. (In reply to comment #12) > A possible alternative approach would be to allow the user to set > EMERGE_DEFAULT_OPTS="--misspell-suggestions=n" in make.conf. For things that > are only exist in the emerge interface, I typically use an option like this, > and I reserve FEATURES for flags that need to affect all portage tools and > portage API consumers. If I get it, I should add an option in emerge. Created attachment 269911 [details, diff]
Added misspell-suggestion as a command line option rather than a feature
Hope it's the way, but I didn't add the doc in the man page.
Created attachment 269917 [details, diff]
Added misspell-suggestion as a command line option rather than a feature
Created attachment 269957 [details, diff]
Added misspell-suggestions to emerge manual
Created attachment 269979 [details, diff]
emerge: --mispell-suggestion option
Thanks, this is in git now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=ebb887ee7606ec2dd7b266dd3538e68b31ac3a38 I didn't include it in the short --help message, since I'd rather reserve that area for more important options. Also, I made it a < y | n > option since the code is a bit simpler that way. It's pleasure for me to have a more than modest contribution to gentoo after near ten years using it. For the --help short message, I didn't know. For the < y | n > option, it was done like this in the submitted patch. Thanks This is in 2.1.9.47 and 2.2.0_alpha31. *** Bug 366521 has been marked as a duplicate of this bug. *** |
