Abdelrazak Younes <[EMAIL PROTECTED]> writes: > You've just described my very plan . I just thought it was obvious so > I didn't care to write it so explicitly. The problem is just that Lars > won't allow step 1.
<lazy drawl> Man, you really are too prickly. </lazy drawl> Read his mails again (snippets below). I don't see nothing that says "NO!" Seems to me that he's simply trying to understand what you're proposing to do. If you don't give him the big picture how's he supposed to read your mind? Bowing out of this thread, Angus Mail 1 ====== Why do you have to remove support for direct ascess to aspell or ispell to implement support for enchant? (What I am saying: Do cleanup after the fact, not before.) Mail 2 ====== | > Why can't enchant be added without touching the existing spellcheckers? | | I suggested that some days ago, but Jean-Marc argued that it is too much | work if the others are supposed to be removed. But we don't know that yet. Mail 3 ====== What is it in SpellBase that makes to hard for the controller to work with? Does the controlelr ever see anything else than a pointer/ref to some spellbase? If it is cleanup of this you want to change, go ahead... but it really should have no relation to introducing a new type of spellchecker. Mail 4 ====== | Interfacing with a lib or a process is different. Just read the code. Oh bullocks. Then our spellcheck abstraction is wrong. The controller does not need to know if it is accessing the spellchecker through a process or through a lib. Mail 5 ====== | Indeed. And the idea is that enchant might do that for us. However, | what I would like first is some research to be sure that enchant does | everything we need in all platforms. And what if something new pops up tommorrow? Or that I want to create support for useing www.webster.com as my dictionary? Will I then have to recreate the abstraction that was just deleted?
