Possible bug: search/adding tags not from the start of tag-name

[MartinM 4]

I have several tags with the same prefix, eg TRC_Issue, TRC_Document, etc. If I try to add tag (Click to add tag) and type the tagname without the prefix, eg 'Issue', surely enough the tag is offered by the quick search:

(tag "Issue" does not exist in my Evernote)

 

When I hit ENTER at this moment, a new tag 'Issue' is created and the note is tagged by tag 'Issue' and not 'TRC_Issue'. The same happens if I CLICK on the offered TRC_Issue tag.

 

Now I removed the tag Issue from the note (but didn't delete it) and I'll try again but type the word 'Issue' only partially: 'Issu'

 

Pressing ENTER or Clicking on the offered tag Issue tags the note correctly with tag Issue. However clicking on TRC_Issue will create a new tag 'Issu' and tag the note with it.

 

(now I've deleted the tag 'Issu') And I'll try to type 'Issu' into search box again, this time will use arrow keys to select either Issue tag or TRC_Issue tag. This works for Issue tag; the rest of the tag's name will appear in the search box in selected manner and hitting ENTER adds the tag Issue to the note.

 

However doing the same for TRC_Issue, pressing arrow-down key to select it in the suggestions list and then pressing ENTER (or clicking) will again create and add 'Issu' tag to the note.

 

 

I don't know if this is bug or working-as-intended (or if it was reported), but certainly clicking or selecting an existing tag in the search bar should add this tag and not create a new one.

 

 

[JMichaelTX 4,117]

Looks like a bug to me.

 

I suggest you Submit a BUG report via an EN Support Ticket. In the Support Form, select "Report a bug, crash, or data lost", and start the Ticket Title with "BUG:  " to make it clear.  Reporting a bug should be available to all users, including Free Account owners.

[MartinM 4]

Thank you. I was looking for the best way how to report a bug but didn't think submitting a ticket was appropriate.

[dconnet 529]

This bug has been fixed in the current (5.7) release.

[jefito 5,589]

I don't know if this is bug or working-as-intended (or if it was reported), but certainly clicking or selecting an existing tag in the search bar should add this tag and not create a new one.

As far as I know, this behavior has changed with the latest Windows release (5.7.0.5492). Infix matching is disabled now, so you won't get matches on "TRC_Issue" when you type "Issue" as you did in your examples. I actually liked that behavior when it arrived not too long ago, but I didn't like the bug, for sure.

[dconnet 529]

 

As far as I know, this behavior has changed with the latest Windows release (5.7.0.5492). Infix matching is disabled now, so you won't get matches on "TRC_Issue" when you type "Issue" as you did in your examples. I actually liked that behavior when it arrived not too long ago, but I didn't like the bug, for sure.

 

 

Yes, this was changed. The infix match was causing a minefield of issues. (Personally, I know of no other auto-complete that did that, so it was weird when I tried to implement it. So many edge cases...)

[jefito 5,589]

 

 

As far as I know, this behavior has changed with the latest Windows release (5.7.0.5492). Infix matching is disabled now, so you won't get matches on "TRC_Issue" when you type "Issue" as you did in your examples. I actually liked that behavior when it arrived not too long ago, but I didn't like the bug, for sure.

 

 

Yes, this was changed. The infix match was causing a minefield of issues. (Personally, I know of no other auto-complete that did that, so it was weird when I tried to implement it. So many edge cases...)

 

Interesting. Thanks for the explanation  -- I wondered whether that was the reason the behavior got yanked. It wasn't a big deal for me, but I would think that the folks who do hierarchical tag names (like the case presented here), would like it. I hate it when a seemingly simple feature turns out to be not so much...

[MartinM 4]

Thank you all for clarification.

 

Well I guess I will have to type those prefixes, then...

 

Just for the record, auto-complete boxes are often tricky for some reason. One would think how hard can it be?, but we had a good deal of "fun" with our auto-complete search on our project.

[Rob Freundlich 146]

 

 

As far as I know, this behavior has changed with the latest Windows release (5.7.0.5492). Infix matching is disabled now, so you won't get matches on "TRC_Issue" when you type "Issue" as you did in your examples. I actually liked that behavior when it arrived not too long ago, but I didn't like the bug, for sure.

 

 

Yes, this was changed. The infix match was causing a minefield of issues. (Personally, I know of no other auto-complete that did that, so it was weird when I tried to implement it. So many edge cases...)

 

 

I use IntelliJ for Flex and Java coding, and it does Infix matching for its code completion feature.  In fact, it takes it a step further: suppose I've got a class called FooBarBaz.  If I type FBB and hit control-space, it'll show me FooBarBaz as one of the choices.  It'll also show it as a choice for BB, and possibly even Bar.

 

I believe that Eclipse will do something similar, although it's not quite as fully-featured.

 

I got to this thread because (not realizing you'd had Infix matching), I had posted feature request for it (https://discussion.evernote.com/topic/79700-feature-request-tag-fuzzy-auto-complete/) and someone pointed me here.  If you go to that thread, you'll see all the reasons having Infix back would be really useful.

 

So may I request that you take a look at those tools to see how they work? (at least from a user perspective - obviously you can't peek under the covers)   It'd be great if that gave you some insight so you could bring back this feature!

[Frank.dg 1,385]

Interesting thing is that infix matching works when accessing the neighboring notebook suggestions list within the note itself and the note list. So tagging must be a whole different kettle of fish coding-wise, I imagine.

 

A weird sort of positive side effect of infix matching not working for tags at the moment: I have prefixed my "placeholder" tags in the tag list (those tags that have zero associated notes, which serve as parent tags) with a select few simple Unicode symbols, which visually indicate whether I'm mirroring a stack or a notebook. I have a few other uses.

 

The point is that these Unicode symbols are "impossible" to type in accidentally (and kind of difficult to do intentionally) - and so we really have no way of them presently showing up in a list of suggested tags when we begin typing. I have several placeholder tags prefixed with Unicode symbols which would otherwise show up in the list during my tagging process. I quite like it that way - the fact that they never show up when I want to tag... *neither in the Web clipper tag list nor  in any of the clients I use. Very useful and keeps things simple and uncluttered for me. 

 

So I guess my workflow would be a teeny bit less convenient (or a teeny bit more cluttered) if Evernote had to get infix matching for tags right. 

 

EDIT: Curious thing is that I just noticed in the Web clipper dialogue box that infix matching for tags does in fact work. The good thing is that my tags prefixed with Unicode symbols appear at the end of the list... so that's not too bad of a deal. Plus, since they have a Unicode symbol, I know at a glance not to use them.   

 

[Rob Freundlich 146]

I love your use of Unicode characters!

I think the best bet if EN were to put Infix back would be to provide an option to turn it on or off. I tend to make the default value for a new option be to follow the old behavior (UI shouldn't surprise people), so my suggestion would be to make it be off by default.