I added API calls to export the "score" for each
suggestion. The score is the "distance" of a
suggestion from the original word. This can be used to
resort suggestions for a calling program which knows
something more about the words.
Here's the diff from the manual:
--- reference/aspell/aspell_0_60/manual/aspell.texi
2006-05-05 09:36:09.074874000 -0700
+++ aspell.texi 2006-05-16 16:49:01.891079000 -0700
@@ -2197,7 +2197,7 @@
@var{word}, @var{size});
AspellStringEnumeration * elements =
aspell_word_list_elements(suggestions);
const char * word;
-while ( (word =
aspell_string_enumeration_next(aspell_elements)) != NULL )
+while ( (word =
aspell_string_enumeration_next(elements)) != NULL )
@{
// add to suggestion list
@}
@@ -2206,7 +2206,30 @@
Notice how @code{elements} is deleted but
@code{suggestions} is not.
The value returned by @code{suggestions} is only valid
to the next
-call to @code{suggest}. Once a replacement is made the
+call to @code{suggest}.
+
+If you want to sort the Aspell words by some
additional criterion before
+presenting them, you should also take into account the
``score'' that
+Aspell used to sort them. The score gives the
``distance'' of the
+suggestion from the original, with increasing scores
giving increasing
+distances. To cycle through a list of suggestions
with scores,
+instead of the above example, copy this code:
+@smallexample
+AspellSuggestionList * suggestions =
aspell_speller_scored_suggest(
+
spell_checker,
+
@var{word}, @var{size});
+AspellSuggestionEnumeration * elements =
+
aspell_suggestion_list_elements(suggestions);
+const AspellSuggestion * sugg;
+while ( (sugg =
aspell_suggestion_enumeration_next(elements)) != NULL )
+@{
+ // Add to suggestion list sugg->word, of length
sugg->word_len, and
+ // with score sugg->score.
+@}
+delete_aspell_suggestion_enumeration(elements);
+@end smallexample
+
+Once a replacement is made the
@code{store_repl} method should be used to communicate
the replacement
pair back to the spell checker (for the reason,
@pxref{Notes on
Storing Replacement Pairs}). Its usage is as follows:
diff -ur for all the source files changed.
Logged In: YES
user_id=6591
Please also attach the manual diff, rather than including it
inline to avoid any reformating issues.
Logged In: YES
user_id=6591
Your should not be performing any conversions in
suggest.cpp. That should be done outside the speller module.
Rather than creating a new list FinalScores. Change
NearMissesFinal to a structure which includes the score.
And make any necessary fixes to the rest if the code. Fell
free to add methods to the new structure if that will be
easier than modifying code in several places.
With that done, SuggestionListImpl should be able to be
implemented in the same way as SuggestWordListImpl.
Logged In: YES
user_id=1415415
> Your should not be performing any conversions in
> suggest.cpp. That should be done outside the speller module.
Currently all the character-encoding conversions are done in
the C interface code, which strikes me as very odd. Should
we ever have a non-C interface, it will want the same
conversions, I would think. It has also led to hacks around
the generality of the interface macros.
I was loath to add more "c impl" code to mk-src.in, but
that's the way to implement conversions for "suggestion
enumeration" the way they are done for "string enumeration".
However, I'll switch over to that way of doing things if
you prefer it (though I'm way over my time budget for this).
> Rather than creating a new list FinalScores. Change
> NearMissesFinal to a structure which includes the score.
> And make any necessary fixes to the rest if the code. Fell
> free to add methods to the new structure if that will be
> easier than modifying code in several places.
I was trying to keep the existing WordList access as
consistent as possible (based on your earlier feedback). If
I make this change, the "under the hood" behavior will be
different. I believe you already know and approve of that.
Logged In: YES
user_id=6591
> Currently all the character-encoding conversions are done
> in the C interface code, which strikes me as very odd.
> ...
> However, I'll switch over to that way of doing things if
> you prefer it
Yes. This is by design. The spelling module should not
ever have to deal with conversion issues. I will not accept
this patch to this is corrected.
> I was trying to keep the existing WordList access as
> consistent as possible (based on your earlier feedback).
> If I make this change, the "under the hood" behavior will
> be different. I believe you already know and approve of
> that.
It is OK if the "under the hood" behavior changes a bit,
especially, if it will simplify things which I think it
will. However , it is not that important of an issue, it can
always be made latter.
Fixes of what Kevin objected to in aspell-diff.txt. Supercedes manual-diff and aspell-diff.
Logged In: YES
user_id=1415415
The latest patch should address both your issues.
SuggestionListImpl still doesn't use MakeEnumeration because
it needs a Suggestion struct to return a pointer to, and I
don't know how to do that for MakeEnumeration.
diff2, but with small fixes from local code review.
Logged In: YES
user_id=1044670
Originator: NO
Dear Ethan,
I have been meaning to send this for some time now. Your patch is incomplete,
as it is missing some files, and I cannot compile the patched version. I think that the recommended way to do a patch is "diff -Naur", instead of "diff -ur".
Regards,
Gora
Logged In: YES
user_id=1415415
Originator: YES
Thank you, Gora. I think I got all the original files. Could you tell me which files you think are missing? Are they the ones generated with the following?
cd auto/
perl mk-src.pl
perl mk-doc.pl
touch auto
Logged In: YES
user_id=6591
Originator: NO
I am most likely going to accept your patch for Aspell 0.61, rather
than Aspell 0.60. So could give me a patch which will apply cleanly
to the CVS version of Aspell. If you don't wan't to use the CVS you
can use an Aspell snapshot available at:
ftp://alpha.gnu.org/gnu/aspell/aspell-0.61-20071012.tar.gz
A few additional comments:
Please use a more generic name other than scored_suggest, since I
would may want to expand it to return additional information, maybe
"suggest_plus" to mean suggest with additional information.
Also, your comment "I don't use that struct because I want the convenience
of automatically allocated space for the strings." makes no sense or
is just wrong. A "String" as a struct member will behave in the exact
same fashion of a "String" in a pair. Please use a struct to allow
for the inclusion of additional information in the future.
Thanks in advance.
This issue has moved to GitHub: https://github.com/GNUAspell/aspell/issues/365