Not sure if this is better suited for the developer mailing list, but as I'm strictly a user (of the library) at present, I'll assume it's a user issue. I'm looking at updating code to use 0.50 rather than 33.7.1, and a change in functionality is tripping me up. So...
I'm wondering if there's a rationale behind not having suggestion scores (edit distances, though I know they're more than that) available through the C interface code. Previously these were passed back during the suggest() call. It seems likely to me that this was the simplest way to boil the call down to an extern C call, which makes sense. If that's the case, it might be worthwhile (to me or to everyone) to restore the functionality using an enumeration instead of a straight vector. However, I'm concerned that deeper forces were at work, possibly a refactoring of the scores which made them less user- friendly to the outside world (namely, me). If that's the case, perhaps what's newly hidden should stay that way. Another possibility for me seems to be to use the C++ headers themselves and recreate the scores, though I don't see a clear way to re-use the ones generated during the suggest() calls. Seems a bit dodgy, redoing the work, though it's not much time in my usage. For compilation reasons, limiting inclusion scope and all that, I'd prefer to stick to the straight C api. Anyway, to restate my questions, since they might be lost: Was there a reason beyond convenience for not including suggestion scores in the C interface? Are other library users similarly interested in these scores? Would it be worthwhile to add to the C API? Am I completely missing something and the scores are readily available? (For reference purposes, I'm working on a console/CGI app for Win32 with MinGW.) michael _______________________________________________ Aspell-user mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/aspell-user
