C-Command Software Forum

False search finds?

One more oddity you may be able to help with.

Sometimes (?) a search of a folder or Library will turn up a number of files in the Record Viewer, but when I then use Find to locate the specific words in the files themselves, they are “Not found.”

I checked on one such file using my word processor and it did NOT have the term.

I think this has happened only with files in Greek. Is this perhaps relevant?

And, no, the term is not in any metadata or in the file name, etc.

I attach a screenshot.

I would need to see an example library to be sure, but my guess is that this has to do with non-ASCII characters. EagleFiler’s indexed search is diacritic-insensitive, whereas the Find panel searches for precisely what you typed.

Yikes. This is discouraging. (I lived in a dream-world in which everything was unicode…or so I thought.)

I get a similar result without diacritics, when using Greek alphabet. Does this count as non-ASCII ?

In any case, may I send you a small Library ?

This is actually a feature. Because the indexing engine understands Unicode, it is able to find matches when you search for a string that looks like what’s in the document, even if it doesn’t use the same Unicode code points. This is also how Spotlight works.

Yes. Besides diacritics, Search Kit also performs a variety of other normalizations.

Sure, please send it to eaglefiler@c-command.com.

When I search for “παράδειγμα” with Spotlight, your file comes up. Same in EagleFiler. When I do a diacritic- and width-insensitive search within the file, it finds “παραδειγμά”. A regular, case-insensitive search does not find this, of course. I’m not familiar with Greek, but looking at the characters this seems to me to be the correct behavior.

Thanks, Michael.

I see what’s happening. The accent (diacritic) of παράδειγμα is ignored (when using the search box) and since the document contains παραδειγμάτων this file shows up.

But of course when one goes to find what the search has found in the document, it’s not highlighted and one can’t locate it. One must guess which form of the word might be there, since the search feature that will actually take you to the word DOES pay attention to diacritics.

I’d be ok with this if the search function would at least show me what it’s taking to be what I’m searching for. That is, I could live with the search returning παραδειγμάτων when I ask for παράδειγμα, if it would show what it finds. But instead it tells me that somewhere in this document is a word that is close; it reveals neither which word nor where it is. With a document of any length, this can cause headaches.

Correct behavior, you say. That’s hard to imagine. The problem, here, it seems, is that we’re dealing with two different search mechanisms that can’t speak to one another…One does want to be able to locate what has been ‘found’ – no?

Thanks for your help–yet again. Your attention to users is exemplary.

It’s correct in the sense that it’s working as designed, and there doesn’t seem to be a malfunction related to your specific library or query. Additionally, this all works the same as in other applications. Spotlight is diacritic-insensitive, whereas searching within a document using TextEdit, Preview, or Safari is not.

I realize it’s frustrating that the two search mechanisms are inconsistent. I think, ideally, the highlighting would match the outer search, and the Find panel would have a checkbox (like it does for case) to control whether it’s diacritic-insensitive. Some of this it would be possible to add in a future version of EagleFiler. However, there are also limitations in the underlying OS frameworks. For example, Web views do not support diacritic-insensitive searching.

Thanks for the clarification.
Yes, it’s good to know that it’s working as it ‘should’.

It seems that EF will not be useful for me when wanting to search Greek texts.
I’ll have to figure out whether I can live with this.

Yes, I’ve discovered that Spotlight gives me the same headache (as does Together, by the way).
All relying on the same technology here perhaps?

(I see that Dthink doesn’t have this ‘problem’ – but it has other ghastly behaviors, of course.)

Many thanks for walking me through this on a beautiful day in New England.


Would it help if I made the changes described in the previous post?

Yes. Together uses Spotlight directly, and Spotlight and EagleFiler use the same indexing engine (Search Kit) which does not allow turning off diacritic insensitivity.

You are more than generous. What can I say?

If EF had auto-scroll and the ability to synchronize these two search mechanisms (by adding a checkbox to the Find panel, as you suggest), I’d have no reason to flirt with Devonthing. Sounds perhaps odd, but this kind of search is a significant part of my reason for using such an app.

I would be delighted.


(And not a small part of my admiration for EF comes–as with others–from your remarkable responsiveness.)

EagleFiler 1.4.5 adds the “FindPanelDiacriticInsensitive” esoteric preference, which makes the find panel behavior match that of the search engine rather than find panels in other applications.