[sword-devel] Comming soon: new improved sword searching

[David's Mailing List and Spam Reciever]

On Sunday 08 September 2002 01:42 am, Joel Mawhorter wrote:
> The first area that I will be working on is adding a new type of search to
> Sword. The new search type will be based on typical boolean search
> operations (AND, OR, NOT,and maybe XOR using the operators &, |, !, and ^
> respectively). Grouping with parenthases will be supported. For example,
> (God & (Father | Son | Spirit)) will give you all of the verses that have
> the word "God" and at least one of the words "Father", "Son" and "Spirit".
> Both word and phrase search terms will be supported within the same search
> expression. For example, (Jesus & "son of God") will find all verses with
> both the word and the phrase in them. I will also be adding a specialized
> AND operator that considers verse proximity. For example, ("lamb of God",
> Jesus, "take away", sins @3) will find all combinations of verses within 3
> of each other that have all the search terms in them. This could be one
> verse that has all the search terms or any set of n verses (where n <= the
> number of search terms), each with one or more of the search terms, such
> that the two verses in the set that are fartest apart do not have more than
> two verses in between. I will also allow simple wildcards. I'm not sure how
> simple or complex that will be yet but at a minimum will allow something
> like (Jesus & lov*) which will find love, loving, etc. All of the above
> functions will be useable within one search expression. For example:
> ((one*,"a phrase",two@2) ^ (three & !(four | five)). I'm not certain anyone
> would ever need a search expression of that complexity but it just gives an
> example of what will be possible. I intend this search functionality to be
> practical superset of the existing search types. It won't be exactly a
> superset since it won't have full regular expression support. However, I
> think that with the functionality available, regular expressions won't be
> necessary. If any of you can think of an example of something that you do
> with the current regular expression searching that won't be possible with
> what I described above, please let me know.

I still wouldn't take out regular expressions. There quite powerful and 
facilitate things like searching beginning and ends of verses/lines/whatever 
it ends up being I forget off hand. Additionally, regex syntax is sometimes 
easier for us *nix heads than stringing together a bunch of boolean logic 
strings. ^_~ Plus, it's just useful in language bindings that support regex 
and not that other. For example Perl, python and php all have native regex. 
and I'd wadger with perl at least it would be easier on us perl developers to 
let us use Perl or POSIX compliant regex directly into the functions in the 
bindings and stuff than it is for us to build complex booleans. But I can 
think of instances where both would be useful.

Furthermore I just plain think regex is keen :D

But really I don't see why we shouldn't provide either both or some mix of the 
two as what you've got is pretty powerful too and easier to use than regex 
for the uninitiated. Anyway it's late. I've been coding in Pascal most of the 
day and now I must sleep for Pascal is evil.

-- 
--David's Mailing List and Spam Receiver
    Keeping me (relativly) spam free since 2002