This is interesting. What are we driving at here? A single user? That doesn't make sense to unless you want to flag certain things as they construct the document. Or else why don't they know what is in their own document? There must be other ways apart from Lucene. It seems to me you want each line parsed as soon as entered and matched against some criteria. I would look at plugins for Open Office first. Or any other text editor. But not sure you have given enough information. Sent using BlackBerry® from Orange
-----Original Message----- From: "Sean" <spaceh...@foxmail.com> Date: Wed, 29 Dec 2010 15:35:17 To: java-user<java-user@lucene.apache.org> Reply-To: java-user@lucene.apache.org Subject: Re:Using Lucene to search live, being-edited documents Does it make any sense? Every time a search result is shown, the original document could have been changed, no matter how fast the indexing speed is. If you can accept this inconsistency, you do not need to index so frequently at all. ------------------ Original ------------------ From: "software visualization"<softwarevisualizat...@gmail.com>; Date: Wed, Dec 29, 2010 06:06 AM To: "java-user"<java-user@lucene.apache.org>; Subject: Using Lucene to search live, being-edited documents This has probably been asked before but I couldn't find it, so... Is it possible / advisable / practical to use Lucene as the basis of a live document search capability? By "live document" I mean a largish document such as a word processor might be able to handle which is being edited currently. Examples would be Word documents of some size that are begin written, really huge Java files, etc. The user is sitting there typing away and of course everything is changing in real time. This seems to be orthogonal to the idea of a Lucene index which is costly to construct and costly to update. TIA
