Jump to content
jbenson2

windows (Archived) Different Search Logic used - Intitle: vs General

Recommended Posts

This can be duplicated.

 

I created four test notes. Two notes used the singular word (one in the title / one in the body) and two notes used the plural word (one in the title / one in the body). I made sure the words (morpheme / morphemes) were not in any of my other notes.

 

Note #1 - Singular word in the title only

Note #2 - Plural word in the title only

Note #3 - Singular word in the body only

Note #4 - Plural word in the body only

 

 

Ran a general search for a singular word and
Evernote successfully found all four notes with both the singular and plural versions.

But...

Ran an Intitle: search for a singular word and
Evernote only found the note with the singular version in the title.

The program did not find the plural version in the title.

 

Actual Search Results:

general search for singular word - found 4 notes (correct)
general search for plural word - found 2 notes (correct)
intitle: search for singular word - found 1 note (questionable)
intitle: search for plural word - found 1 note (correct)

 

 

I am using Evernote for Windows 4.6.7.8409 (268917) Public

Share this post


Link to post

Normal search acts as though there is a '*' at the end of the search term, and it searches note content, tags and title.

 

For intitle:, you need to add it yourself; i.e., "intitle:wor*" should find notes with title "world", "word", "working", etc. in the title.

  • Like 1

Share this post


Link to post

Jefito,

Thanks for confirming my finding.

 

I have a lot of saved searches using the Intitle: command. (using the GrumpyMonkey "minimalist approach")

Evernote should document this dual-standard officially in their Knowledgebase and/or their Search Grammar page.

Share this post


Link to post

Does the same behavior exist in v5? There will be no more updates to v4, so any bugs found there will not be fixed.

Share this post


Link to post

Does the same behavior exist in v5? There will be no more updates to v4, so any bugs found there will not be fixed.

 

Heather, thank you for the response.

I won't be upgrading for a couple months, so I'm sorry but I can't supply an answer.

Perhaps someone else with the beta can comment.

Share this post


Link to post

heather, yes, it's in V5 -- that's where I did my testing.

 

The behavior of normal searches (in adding '*' to a search term) is done by the Windows Evernote client, as a convenience to the user, as I understand it -- it's not a property of the search grammar. The change is made before the search is submitted to the search engine. This is evidently not done for intitle: searches, or tag: searches for that matter. I haven't tested other clients (Android or web would be the ones that I have access to) to see whether they have the same behavior.

  • Like 1

Share this post


Link to post

The android client is quite useful to see how a search is submitted to the engine:

http://www.evernote.com/shard/s26/sh/80bb7358-d5ae-4c28-bff4-f42b914c9b3b/0d47c58fa9cf71be14a460cc7356222e

Note: I did not add the wild card to the search.

The Dev pages don't suggest that the clients will append the wild card to standard searches, but allude to the fact that it can be done.

Whereas it also talks about using the literal term used in the search.

(to me that suggests deliberately not adding the wildcard)

 

intitle:[literal] - will match notes with a title that contains the literal word or quoted phrase. Can be used more than once. E.g.:

http://dev.evernote.com/doc/articles/search_grammar.php
  • Like 1

Share this post


Link to post

Thanks for checking that - I'm en route right now so could test it myself quickly :)

 

I'll file a bug on this (for v5)  :)

Share this post


Link to post

Thanks for checking that - I'm en route right now so could test it myself quickly :)

 

I'll file a bug on this (for v5)  :)

 

OK, and you can close out my Support Ticket #144017.

 

Thank you for some amazing support on a Sunday morning!

Share this post


Link to post

The android client is quite useful to see how a search is submitted to the engine:

http://www.evernote.com/shard/s26/sh/80bb7358-d5ae-4c28-bff4-f42b914c9b3b/0d47c58fa9cf71be14a460cc7356222e

Note: I did not add the wild card to the search.

The Dev pages don't suggest that the clients will append the wild card to standard searches, but allude to the fact that it can be done.

Whereas it also talks about using the literal term used in the search.

(to me that suggests deliberately not adding the wildcard)

 

intitle:[literal] - will match notes with a title that contains the literal word or quoted phrase. Can be used more than once. E.g.:

http://dev.evernote.com/doc/articles/search_grammar.php

This is old news, though, right? I remember reporting this wildcard thing for Android.

http://discussion.evernote.com/topic/26036-evernote-for-android-40-beta-4/?p=139064

I am not a fan of it, but at least the wildcard appears. I believe the Mac client automatically adds it in secret. Again, I am not a fan of this, but the workaround is to put quotation marks around the search term. I guess Windows is doing it now, too?

Technically speaking, as jefito said, the search grammar explanation is correct (http://dev.evernote.com/doc/articles/search_grammar.php#Search_Terms), because what is being submitted for a search is a wildcard. If the app would stop modifying our searches, then the behavior would (in my opinion) act as expected. At the very least, the wildcard should appear in the search field so that we know what is happening.

  • Like 1

Share this post


Link to post

By the way, I believe the logic behind the behavior is this:

(1) Simple searches get wildcards

(2) Advanced searches (anything with search syntax + a colon) does not get a wildcard

  • Like 1

Share this post


Link to post

By the way, I believe the logic behind the behavior is this:

(1) Simple searches get wildcards

(2) Advanced searches (anything with search syntax + a colon) does not get a wildcard

Thanks - a nice clear explanation.

 

It looks like Evernote is in the process of verifying this and will come back with a confirmation.

If not, I'll ask them when they close my Support Ticket.

Share this post


Link to post

I'm a little confused, I thought this was the intended behaviour? At least that was my point before.

Share this post


Link to post

I'm a little confused, I thought this was the intended behaviour? At least that was my point before.

Hmmm.... I am a little confused, too. I thought we already knew about this, and it was the intended behavior (even though I don't like having my searches "aided" like this). That was my understanding last year when it started happening.

Heather's response suggests that it is a bug. If so, that would be interesting. I am guessing that we caught her on a weekend doing a hundred other things and not looking into this too closely -- I think she'll come back and say it is intended.

Let me dig up a comment I remember Seth making about this. I think he and jefito had a conversation on the forums about it...

[EDIT:]

Wait a second. Isn't this JB complaining about the issue back in 2011!? Time flies. I guess this issue is even older than I thought (assuming, of course, I understand this thread correctly).

http://discussion.evernote.com/topic/15040-evernote-api-search-grammar-error/?p=73293

Here is Seth's answer (http://discussion.evernote.com/topic/17028-api-updated/?p=84521):

The desktop clients aren't taking what you type into the search bar and using that as the verbatim search query. Although you can't see it, they're actually appending the wildcard to what you type, such that entering "potato" into the search bar results in a formal search of "potato*". This is done because it's usually what a user wants, and because it simplifies showing results as you type...you'll notice that you don't have to type Enter or click a button to execute the search.

The formal search grammar and the findNotes API, on the other hand, operate as described in the API Overview.

Share this post


Link to post

I'm a little confused, I thought this was the intended behaviour? At least that was my point before.

 

Yes, the dual-search technique might be what Evernote wants.

Heather confirmed my specific issue won't be fixed with version 4.0.

So my solution will be to rely more heavily on tags.

 

If it is an intended feature, it would be helpful to document the differences in easy to understand language for the general user.

  • Like 1

Share this post


Link to post

[EDIT:]

Wait a second. Isn't this JB complaining about the issue back in 2011!? Time flies. I guess this issue is even older than I thought (assuming, of course, I understand this thread correctly).

http://discussion.evernote.com/topic/15040-evernote-api-search-grammar-error/?p=73293

 

 

No, that pertained to another search issue and did not involve the Intitle: search command.

If I did a general search for potato, it would find both singular and plurals which is correct, but did not jive with the original Evernote instructions.

http://www.evernote.com/shard/s2/sh/ed2f64c6-b373-40ff-9adc-0791c39e04b2/d09c6357fbe1533f50f4fbb0ccd9b450

 

Seth's comments sound helpful. They should be added to the Knowlegebase.

Share this post


Link to post

[EDIT:]

Wait a second. Isn't this JB complaining about the issue back in 2011!? Time flies. I guess this issue is even older than I thought (assuming, of course, I understand this thread correctly).

http://discussion.evernote.com/topic/15040-evernote-api-search-grammar-error/?p=73293

 

No, that pertained to another search issue and did not involve the Intitle: search command.

If I did a general search for potato, it would find both singular and plurals which is correct, but did not jive with the original Evernote instructions.

http://www.evernote.com/shard/s2/sh/ed2f64c6-b373-40ff-9adc-0791c39e04b2/d09c6357fbe1533f50f4fbb0ccd9b450

 

Seth's comments sound helpful. They should be added to the Knowlegebase.

However, intitle (and all the other syntax, I think) has always been like this, right? They are exact searches that have to get the spelling, capitalization, and so forth correct. At least, I don't remember a time when intitle worked as if there was a wildcard attached. IF it did, that would single-handedly destroy my notetaking system, so let's hope that doesn't happen!

Share this post


Link to post
However, intitle (and all the other syntax, I think) has always been like this, right?

 

 

It might be. I don't know. I have 25,000 notes so some past searches could easily have slipped through the cracks. Without doing a specific test like this I don't have a way of proving it one way or the other. That is why I posted what appears to be my inconsistent search results.

 

I am not blaming anyone, just pointing out a result I could not explain.

Share this post


Link to post

However, intitle (and all the other syntax, I think) has always been like this, right?

 

It might be. I don't know. That is why I posted what appears to be my inconsistent search results.

Well, it is good to get this out there, because the behavior is certainly not obvious to the casual user.

Share this post


Link to post

My rationale here is that the search should be consistent, so I'm filing it as a bug either way. They may come back and tell me its by design, but since Scott mentioned that the intitle/general search behaves differently on Android that seems to point to an inconsistency with the API.

 

If they're going to add the wildcard one way, they should add it both ways, or update the search grammar to make it more clear.

 

Catching me on a Sunday at the time when you did just meant I didn't have everything at hand to do all the testing myself :)

Share this post


Link to post

My rationale here is that the search should be consistent, so I'm filing it as a bug either way. They may come back and tell me its by design, but since Scott mentioned that the intitle/general search behaves differently on Android that seems to point to an inconsistency with the API.

 

If they're going to add the wildcard one way, they should add it both ways, or update the search grammar to make it more clear.

The way I see it, there is nothing wrong with the search grammar API pages. That tells 3rd party devs that if they want to have a wild card search then they have to pass it in.

We are comparing the EN clients to the API and here this is the wrong idea. As I understand it, it is not the search engine that is appending the wildcard search (because according to the API pages it takes only literal terms) but the clients that are adding the wildcard into the search before passing it to the search engine.

In the potato example, we should expect plural to be found because we know that the client is sending potato* to the search.

  • Like 2

Share this post


Link to post

My rationale here is that the search should be consistent, so I'm filing it as a bug either way. They may come back and tell me its by design, but since Scott mentioned that the intitle/general search behaves differently on Android that seems to point to an inconsistency with the API.

 

If they're going to add the wildcard one way, they should add it both ways, or update the search grammar to make it more clear.

The way I see it, there is nothing wrong with the search grammar API pages. That tells 3rd party devs that if they want to have a wild card search then they have to pass it in.

We are comparing the EN clients to the API and here this is the wrong idea. As I understand it, it is not the search engine that is appending the wildcard search (because according to the API pages it takes only literal terms) but the clients that are adding the wildcard into the search before passing it to the search engine.

In the potato example, we should expect plural to be found because we know that the client is sending potato* to the search.

Yep. I'll let you argue with Heather on this one, though :)

Personally, I'll make do with it one way or another, but (as I have been saying for years now?) there needs to be better documentation, even in the API. Why are there still easter eggs like this floating around undocumented years after they have been sussed out and discussed? I don't imagine this makes the job of customer support very easy (how would you train new staff on secret search modifications?), and it certainly confuses even longtime users.

I'm glad Heather filed her report. Let's encourage her to lie in wait for the developers, grab them when they walk through the door tomorrow, lash them to their chairs, and fix this (the behavior and the documentation) before they go home from work on Monday. Go get 'em Heather!

Share this post


Link to post

I'm with Scott on this. As GM said, this is nothing new. It was well discussed in the past that the Windows client treats the search term toad the same as toad* In the past year, I've been using the web client a lot more as well as Clever & the EN iOS app for my "duet" account. I've simply adopted my search to adapt accordingly. IOW, I don't "assume" searching on 'toad' in the Windows client is the same as searching on 'toad' in the web client. Maybe b/c I'm simply more goal oriented & as long as it doesn't require an act of Congress, I'm willing to adjust my workflow to get what I need. (Which in the end, is the most positive result, no? Getting what I need?)

I can see where Heather may want all the EN clients to respond in the same fashion. I'm not against that. I'm just saying that IMO, this is not new, it's not the end of the world as we know it (cue REM) and it's ultimately up to the parameters any client is passing to the API.

What I will say is if after all these years, if you change the Windows client (and please note, I'm not saying you should not), that there will be pushback b/c there will be Windows only users who will be complaining that searching on the word toad no longer finds toadstool.

Share this post


Link to post

 

The android client is quite useful to see how a search is submitted to the engine:

http://www.evernote.com/shard/s26/sh/80bb7358-d5ae-4c28-bff4-f42b914c9b3b/0d47c58fa9cf71be14a460cc7356222e

Note: I did not add the wild card to the search.

The Dev pages don't suggest that the clients will append the wild card to standard searches, but allude to the fact that it can be done.

Whereas it also talks about using the literal term used in the search.

(to me that suggests deliberately not adding the wildcard)

 

intitle:[literal] - will match notes with a title that contains the literal word or quoted phrase. Can be used more than once. E.g.:

http://dev.evernote.com/doc/articles/search_grammar.php

 

This is old news, though, right? I remember reporting this wildcard thing for Android.

http://discussion.evernote.com/topic/26036-evernote-for-android-40-beta-4/?p=139064

I am not a fan of it, but at least the wildcard appears. I believe the Mac client automatically adds it in secret. Again, I am not a fan of this, but the workaround is to put quotation marks around the search term. I guess Windows is doing it now, too?

Technically speaking, as jefito said, the search grammar explanation is correct (http://dev.evernote.com/doc/articles/search_grammar.php#Search_Terms), because what is being submitted for a search is a wildcard. If the app would stop modifying our searches, then the behavior would (in my opinion) act as expected. At the very least, the wildcard should appear in the search field so that we know what is happening.

 

Windows has been doing this for a long time. I am pretty certain that there was some feedback in the forums from Evernote staff on it. My preference would be for consistency (give me the search that I type), but it's never been that big a deal for me to have it doing the wild(card) thing either.

 

Heather, if you want to file bugs, file bugs against search that make it impossible to use search to make note filters that you can do with the UI. For example, you can get the UI to show you all of your notes, but there's no way to do that via the search grammar. Sort of stuff makes me crazy.

  • Like 1

Share this post


Link to post

I file lots of bugs :) However, that's a feature request, Jeff ;)

 

To be clear, this bug is that intitle: does not add the *, not that general search does.

Share this post


Link to post

I file lots of bugs :) However, that's a feature request, Jeff ;)

 

To be clear, this bug is that intitle: does not add the *, not that general search does.

In my mind it's a bug -- the implied contract was that you could always use the search grammar to replicate what you could do with the UI, with respect to the note list members (though not sort them). That's why you could use saved search to capture whatever filter you got when using the UI; now that's not true. If you do the filter that I suggested, the saved search comes up blank. If that's not a bug, it's certainly a user-goes-huh? feature... :) Anyways, I have made many a suggestion about these matter, I'm sure that dlu is roundly tired of seeing me post about them, at this point.

 

I do understand the bug that you filed, though. It was explained in the forum that it was a convenience to the user, if if I recall correctly. 

Share this post


Link to post

I file lots of bugs :) However, that's a feature request, Jeff ;)

 

To be clear, this bug is that intitle: does not add the *, not that general search does.

I am confused. The system I started with back in 2008 was: nothing gets a wildcard unless you put it there. At least, that is how I remember it. That should be the solution to the current dilemma, right? Then, the API and the behavior all match and everyone is happy.

The fact that Evernote developers for each client have decided to "aid" us by sometimes secretly and sometimes openly having their apps add wildcards to the general searches is the mistake, in my opinion. I think I have expressed this criticism over the years (?) in various ways. Most notably, there was the case of the massive search discrepancies among clients (sometimes 1,000+, depending on the search). In part, this was a problem with the wildcard (or wildcard-like behavior), as I recall. At least, that was my interpretation of the issue.

http://discussion.evernote.com/topic/32709-search-problems-japanese-in-quotation-marks/?p=177496

Now, the rules seem to be:

(1) General search = sometimes wildcard, sometimes not

(2) Advanced search = never wildcard

This is fine with me, because I don't use so many general searches. I don't think adding wildcards will help improve the situation. In fact, I am guessing that it will cause me all sorts of headaches, since I will now have to start enclosing things in quotation marks. I hope it isn't just intitle that gets this new behavior, or that will create another inconsistency to remember.

I'll make do with whatever gets decided here, though, and I appreciate the effort to enforce uniformity, but I really hope that however this gets sorted out, we get documentation.

Share this post


Link to post

I'll make do with whatever gets decided here, though, and I appreciate the effort to enforce uniformity, but I really hope that however this gets sorted out, we get documentation.

 

 

Ditto.

 

Tag searches are more powerful for me. According to BitQwik, I've got 1,400 tags. A few more won't cause me any difficulty.

Share this post


Link to post
Guest
This topic is now closed to further replies.

×
×
  • Create New...