[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [aspell-devel] clear_session, store_replacement, and support

From: Kevin Atkinson
Subject: Re: [aspell-devel] clear_session, store_replacement, and support
Date: Sun, 14 Aug 2005 01:19:35 -0600 (MDT)

[Also CCing aspell-user, as that is where this thread should of been
to begin with]

On Fri, 29 Jul 2005, Bill Moseley wrote:

> Again, I want to be clear about the API -- I want to make sure I'm
> testing return values for every function that returns a value
> indicating an error.

Most functions which return an int will return false on an error condition 
and true if they succeed.  Exceptions to this rule should be documented 
in aspell.h.

As an alternative you can use any one of 
As they will all return false (null or 0) if there is no error.  Any 
function which can create an error will reset the error object.  
Unfortunately which functions can fail is not well documented.  To be 
absolutely sure have a look at the interface code.  If a function
has the line "ths->err_.reset(ret.release_err())" than it will reset the 
error object.

> PS -- one other question:  I require the en_US dictionary installed
> for testing.  Of course, not everyone has that dictionary, but I'm
> not sure how I can test Aspell without knowing a specific dictionary
> is installed -- I want to make sure I can lookup mispelled words, so
> seems like I need a specific dictionary to do that.  If you or anyone
> has a better idea I'd like to hear.  Also, I'm not 100% clear how to
> verify that the dictionary I need is installed -- but I haven't
> looked at that yet.

You can always create a small dummy dictionary with a dummy language.  You 
can name the language and dictionary "qts" which is unlikely to ever 
conflict with any existing languages, especially since the the codes 
"qaa"-"qtz" are reserved for local use by the standard.  However 
Aspell 0.50 _may_ have some problems with the three letter language code, 
so you may want to use "qt", however this code is technically not reserved so 
it in theory might conflict with a future language.

PS: I will gladly accept any help from anyone willing to improve the 
documentation on the API.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]