On Wednesday 29 Elul 5771 12:20:33 Jean-Francois Dockes wrote:
> David Baron writes:
>  > On Wednesday 29 Elul 5771 09:35:41 Jean-Francois Dockes wrote:
>  > > This is probably from recollrunner with only 'default query language'
>  > > checked: there is excessive quoting, but it doesn't hurt much because
>  > > this is a full text search and the quotes get eliminated. I don't
>  > > know why recollrunner returns few results, but as you mention that
>  > > these are only the ones without spaces in the file name, I'd suspect
>  > > a problem parsing the output from recoll.
>  > 
>  > I am no longer quoting filename searches.
>  > 
>  > I have changed the stdout line parsing to
>  > .....[ --> mimetype after trimming
>  > [......] --> URL/path
>  > [----]  --> name, title, etc ...
>  > 
>  > Spaces are not used for anything (except removed from the mimetype). I
>  > can see filenames with spaces.
>  > 
>  > krunner seems to be not including every match I feed to it. In other
>  > words, I know I am getting three filename results into the program but
>  > only one of them (first one?) actually gets displayed. This may be why
>  > Denis only still sees three of his gazettes (unless this is still the
>  > space problem). In any event, I may post next week a new version on
>  > kde-apps.
> 
> Ok, I don't know enough about krunner to be of real usefulness here.
> 
> We should be aware that the recollq/recoll -t output is not fully parseable
> at this point (a file name with ']' in it would break it). If you can get
> the krunner part to behave, and if you decide that the current approach is
> the sensible one (as compared to using an API), I could easily be convinced
> to provide a fully and easily parsable output format (for example by
> encoding the data parts in base64), we can talk about this.
> 
> Cheers,
> 
> jf

I do think that a fully, consistently parsable output is desirable. This would 
enable various scripting options, not just for my little krunner. Also, using 
%20 instead of spaces and appropriate codings for other illegal characters 
would make thie [URL] canonical/legal. "File://...." implies URL. Was it done 
this way previously (why space problem did not show up before)?

On filename searches, simple text used as *name* makes sense. Capitals are 
sometime automatic, many times ignored, and are language specific.
Name queried as Name* might make sense. "name" would imply no wildcards. This 
stuff is easier than regex but regex might be desirable as a query alternative 
for text and filenames.

Using an API? Is there one in the works?



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to