[PATCH] Hspell plugin for KSpell2

Nadav Har'El nyh at math.technion.ac.il
Fri Apr 29 19:29:04 BST 2005


Thanks for writing the patches.

On Fri, Apr 29, 2005, Mashrab Kuvatov wrote about "[PATCH] Hspell plugin for KSpell2":
>...
> Second, to be able to link against libhspell, one has to modify hspell.h i.e.
> add extern "C" stuff (thanks Oliver for tip!). One can get a modified copy
> from [1]. Hspell devs, please add it in next release, if you want C++ junkies
> use your lib. :-)

Why? What's wrong with C++ junkies knowing that this is a C library, and
therefore they need to do

extern "C" {
#include <hspell.h>
}

I believe that C++ users are already used to doing that for other libraries
written in C. There's certainly no reason to change the .h file!

Anyway, nO ".h" file of a C library will have this "extern C" stuff in it,
as this is NOT a legal C construct... The most we can do is to add some sort
of ugly (because it's not portable) conditional code like

	#ifdef __cplusplus
	extern "C" {
	#endif
	...

to the header file, but again I don't really see the point.

> Hopefully, people who speak Hebrew will comment whether it makes sense.

I think Dan already commented on this.

> I'm not going to commit it. As a lib, hspell is missing a key feature - add to
> dictionary. I think, without this feature it is just irresponsible to give 
> KSpell2 with it to user. It will save a lot of energy one has to spend to
> explain a user that actually the add-to-dict button is not broken in KDE, but
> it is a lib which cannot handle it. Hopefully, hspell devs will add it in next
> releases.

This is a delicate issue. We understand this need, but also the opposite view
also has merit; Our current implementation assumes that the user's personal
dictionary should be handled by the calling program, NOT by Hspell. There
are a number of reasons why we had this view: First, the calling program,
not the Hspell library, should be responsible for where this personal
dictionary should reside. The calling application (e.g., a word processor)
knows where to place configuration files, while the Hspell library doesn't
know which policy to use (save the word across applications? for the
current directory only? for the user? for the entire system?). The second
reason is that a word processor (for example) would normally like to have a
multilingual personal dictionary, and allow the user to view it to remove
excess words or add words, etc. If Hspell handled Hebrew words, and some
other library handled French words, the word processor won't have control
over the entire list.

But, we may reconsider this decision, especially if we understand more
about the needs of spell-checking library users. Doesn't KDE keep its
own list of correct words? Or does it assume that every spell-checking
library keep its own list?


> IHMO, there should be a kind of rule, a barrier I'd say, saying if your lib
> does not have this and that, do not even think of being a plugin in KSpell2.
> This will motivate spellcheck lib devs. :-)

Naturally, Hspell (the command line program, not the library) *does* have
personal dictionary handling. If someone cared enough, this trivial code
could easily be copied to the Hspell plugin in Kspell2 - it's not mandatory
that it resides in libhspell itself... But, like I said, if we understand
more about the philosophy of KSpell2 and why it thinks each plugin should
keep its own list, maybe we'll reconsider.





-- 
Nadav Har'El                        |       Friday, Apr 29 2005, 21 Nisan 5765
nyh at math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Those who beat their swords into
http://nadav.harel.org.il           |plowshares will plow for those who don't.




More information about the kde-core-devel mailing list