Troy, >From a user's perspective, they simply want to do a search for G140 and return all of the results for that. Then they want to do a search for G1401 and return all of the results for that. If the engine doesn't allow this (which it hasn't until this change), then from the user's perspective, it's a bug. Now you're saying that it will be slower to do the correct thing in this case. From the user's perspective again, making something slower to do the correct thing (which used to work just fine and does for other modules) is a bad thing. Now we have to make all of the searches slower just so we can be sure of getting correct results in KJV. Again, this indicates to the user that there is a design flaw. I never intended to attack your justifications for doing things this way, nor did I attempt to tell you that the technical design was bad. It's just that if a new method of doing things causes a regression, and doing it correctly is much slower, then from the user's perspective a bad decision was made.
My complaint is two-fold. First of all, I have to introduce another ifdef for this. Secondly, the searches will be slower (they are already excruciatingly slow in some circumstances on some platforms). In addition, "doing the right thing by default" would solve this problem for other frontends, eg diatheke. It wasn't my intention to complain about "adding a '.'". I hope you can see how this is a problem for the average user who just wants searches to return reasonable results. Explaining to a user that this is a feature rather than a bug is a difficult thing to do. Matthew _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
