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