I agree this feature would be cool, I'm just not sure the possible memory/performance problems associated with loading all interfaces of all exposed modules in all packages (it would be most helpful but even more of a performance problem to even scan non-exposed packages) would be worth it. Probably it could be made practical by building a sort of index, which is cached on disk..
That is the approach the haskellmode plugins for Vim take: build an index of Haddocumented identifiers once per installation, build an index of import-available identifiers once per :make. The latter turns out to be a performance issue for large libraries, such as Gtk2hs, so some users had to switch it off, updating less frequently, the former doesn't seem to cause any problems. Then again, we don't do fuzzy matching, only completion of partial identifiers and suggesting possible qualified names and imports for unqualified ones. Completion alone can result in many matches, I'd expect fuzzy matching to be worse, and while edit distance is a useful criterion for well-chosen examples, I'd have to agree with those who have their doubts about its use in this context (but then, those who don't need a feature shouldn't stand in the way of those who do;-). A general comment: once there was a time when GHC error messages were inferior to Hugs ones, then Simon PJ spent a lot of time improving GHC's messages, until there came a time when some of GHC's messages were too helpful - you couldn't find the error in all the help provided. It used to be a good idea to have several Haskell installations, just to be able to compare error messages for tricky code. Things have levelled off since then, but there are still cases were longish fuzzy messages are provided by GHC when brief harsh messages would be more to the point - which wouldn't be a problem if the longer friendlier messages at least provided all the details of the short unfriendly ones, which isn't always the case. See, eg, #1928, #2360, #956, #589, #451, .. By all means, record unhelpful error messages as tickets, especially, but not only, when you have an idea of the information that is missing/misleading in them. It is an ongoing process, and balance is as important as perceived friendlyness, and lots of "friendly" suggestions without concrete, specific and useful help may result in a very unfriendly effect (think telephone/email support..). Claus