From kde-core-devel Fri Apr 29 18:29:04 2005 From: "Nadav Har'El" Date: Fri, 29 Apr 2005 18:29:04 +0000 To: kde-core-devel Subject: Re: [PATCH] Hspell plugin for KSpell2 Message-Id: <20050429182904.GA20290 () fermat ! math ! technion ! ac ! il> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=111479982800023 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 } 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@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.