Jump to content

(Archived) HOWTO: search "[any word]" with brackets? (evernote searches "any word" instead of "[any word]")


Max Zhuravlev

Recommended Posts

I'm using sort of inline tags in text of notes.

If I want to "tag" some part of text i am writting "[my tag]" in text. Then I can find all notes and lines which are tagged with "[my tag]" - it's cool and useful!

 

But I have a problem. When I search "[my tag]", search also matches notes with "my tag" (without brackets).

 

For example, search for "[funny]" will match note with "As my grandfather used to say, - I'm your grandfather. [funny]", as well as note with "He said it was funny, but it wasn't."

 

I tried hard

- basic search - funny //74 results

- basic search - [funny] //74 results

- search with quotes - "[funny]" // 73 results, but yet wrong matches there (check big screenshot)

- search - "\[смешно\]" // 73 results

 

I've readen

 

Please help. How to search "[word]" with brackets?

post-124418-0-60310200-1363455116_thumb.

post-124418-0-77395900-1363455168_thumb.

post-124418-0-10657600-1363455227_thumb.

post-124418-0-56964000-1363455522_thumb.

Link to comment
  • Level 5*

Hmmm, well that's curious.

 

OK, by the rules of the search grammar, punctuation (e.g. '[', ']') are not included in the search. So if you search on "[Funny]" (quote enclosed or not), you should be seeing the same matches as for "Funny". In some limited testing, that's what I found.

 

The weird thing is the highlighting; any actual "[Funny]" strings will be highlighted (including the brackets), and any "Funny" strings without brackets will not be highlighted. I can't explain that.

 

And by my first finding, you cannot search for "[word]" and find only those; you'll get matches for "word" as well. It's too bad -- I believe in being able to do literal searches.

 

You might want to report this in a support request; see the link in my signature.

Link to comment

I don't see the brackets being highlighted here, just the word inside, which is expected.

Punctuation is ignored by the search engine, except the underscore.

Try using your "tag" system with underscores, i.e. _tag_

Link to comment
  • Level 5*

I don't see the brackets being highlighted here, just the word inside, which is expected.

I am definitely seeing the brackets being included in the highlighting (looked closer using old standby ZoomIn tool) -- if I remove the brackets, the highlight moves inside to just the text.
Link to comment

I don't see the brackets being highlighted here, just the word inside, which is expected.

I am definitely seeing the brackets being included in the highlighting (looked closer using old standby ZoomIn tool) -- if I remove the brackets, the highlight moves inside to just the text.
Strange:

http://www.evernote.com/shard/s26/sh/0faf5a30-f12b-461e-a56a-e183a42e3c1b/7fd8187afd6a3c245845630850568c45

Link to comment
  • Level 5*

Strange:

You need to quote the string to get the brackets included:

 

"[word]"

 

not

 

[word]

 

If it's unquoted, the brackets are ignored, as they are punctuation.

Link to comment

Hmmm, well that's curious.

 

OK, by the rules of the search grammar, punctuation (e.g. '[', ']') are not included in the search. So if you search on "[Funny]" (quote enclosed or not), you should be seeing the same matches as for "Funny". In some limited testing, that's what I found.

 

The weird thing is the highlighting; any actual "[Funny]" strings will be highlighted (including the brackets), and any "Funny" strings without brackets will not be highlighted. I can't explain that.

 

And by my first finding, you cannot search for "[word]" and find only those; you'll get matches for "word" as well. It's too bad -- I believe in being able to do literal searches.

 

You might want to report this in a support request; see the link in my signature.

Logic says there should be way to search exact string/pattern including punctuation.

 

I don't see the brackets being highlighted here, just the word inside, which is expected.

Punctuation is ignored by the search engine, except the underscore.

Try using your "tag" system with underscores, i.e. _tag_

 

Thanks for suggestion, this will be my "plan B" for case if I don't find way to search with brackets.

I don't like underscores visually :(

 

 

Inline tags are very useful.

Link to comment
  • 2 weeks later...
Another example of using signs in search: I'm setting title "++" for new small notes which complements some older big note. 

- It is fastest way to mark that note should be integrated in some big one (faster then adding Tag or selecting specific Notebook) - it's unique keyword, it has only 2 chars.

 

But then I can't find notes with "++" because search don't search non-character-signs :(

 

There really should be way for searching with non-character-signs.
Link to comment
  • Level 5*

Curious -- you can search for "C++" and this works fine, but just plain "++" doesn't work, even when there's a note that contains the following strings: "++", "C++", "+++", "-++".

 

Can't explain that one.

 

As far as the fastest way to do this sort of thing, I can't testify to that, but I can tell you that being the fastest doesn't matter so much if it doesn't work. *shrug*

Link to comment

Curious -- you can search for "C++" and this works fine, but just plain "++" doesn't work, even when there's a note that contains the following strings: "++", "C++", "+++", "-++".

 

Can't explain that one.

 

As far as the fastest way to do this sort of thing, I can't testify to that, but I can tell you that being the fastest doesn't matter so much if it doesn't work. *shrug*

 

That's because search ignores ++ and you have no any notes with word "C" except notes with word "C++" which for search engine is equal to "C", because it ignores ++

 

Current version of Evernote really underestimates power of non-character-signs (by ignoring them in search). They are very useful.

Link to comment
  • Level 5*

That's because search ignores ++ and you have no any notes with word "C" except notes with word "C++" which for search engine is equal to "C", because it ignores ++

You might be right there. Funny, though. A search for "C" (or "C++", both with double quotes) turns up a different set of notes than a search for plain old C (no quotes).

A little bit crazy-making, for sure. :)

Link to comment

Search for non-characters was available until version 2.2. It was deliberately omitted (except the search for the underscore) during the shift to the 3.x version.

Many users complained since it is very useful indeed. I remember Dave Engberg explaining the reasoning for that but unfortunately I do not have the reference.
Consequently, while apparently you don't like underscores visually, if In-line tags are very useful to you then sooner or later you will end up using the underscore as suggested above.

 

Addendum:

Just recalled another trick I have considered a while ago for in-text bookmark\tag marking, which is adding a non-obstructive character to the word in case. The best choice was the letter "i" in front of a capitalized tag. Thus searching for iWater or [iWater] will find this tag but not any other water, "water" , [water] in the database. I hope that this alternative could be more appealing than the underscore. Of course, capitalization of the tag is not essential, and the "i" could be added at the end of the tag as well. In any case it should be adjacent to the in-text tag, no space is allowed.

Finally, it is possible to create a multi-level tag hierarchy by using an i, ii, iii system.

 

BTW I have noticed that a computer company based in the US is using this i[Word] combination with much success.. 

 

Good luck!

Link to comment
  • 5 weeks later...

Thank you for not only suggesting to not "indulge in vain hopes" but for a fresh workaround also! 

 

Search for non-characters was available until version 2.2. It was deliberately omitted (except the search for the underscore) during the shift to the 3.x version.

Many users complained since it is very useful indeed. I remember Dave Engberg explaining the reasoning for that but unfortunately I do not have the reference.
Consequently, while apparently you don't like underscores visually, if In-line tags are very useful to you then sooner or later you will end up using the underscore as suggested above.

 

Addendum:

Just recalled another trick I have considered a while ago for in-text bookmark\tag marking, which is adding a non-obstructive character to the word in case. The best choice was the letter "i" in front of a capitalized tag. Thus searching for iWater or [iWater] will find this tag but not any other water, "water" , [water] in the database. I hope that this alternative could be more appealing than the underscore. Of course, capitalization of the tag is not essential, and the "i" could be added at the end of the tag as well. In any case it should be adjacent to the in-text tag, no space is allowed.

Finally, it is possible to create a multi-level tag hierarchy by using an i, ii, iii system.

 

BTW I have noticed that a computer company based in the US is using this i[Word] combination with much success.. 

 

Good luck!

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...