Jump to content


Evernote Staff
  • Posts

  • Joined

  • Last visited

  • Days Won


rezecib last won the day on June 19 2018

rezecib had the most liked content!


About rezecib

Recent Profile Visitors

1,852 profile views

rezecib's Achievements




Community Answers

  1. @jefito We are generally moving towards unifying search. I believe business users on Mac currently use a blending of server- and client-side searches, but personal users are purely client-side at the moment.
  2. On the server-side search, resource file names are included in the "all" field, so it's as if they are actually in the note text. You can also manually search for just them with resourceFileName:somefilename. The Mac and Windows clients don't use server-side search right now, though. Google Drive attachments, though, are really just links rather than true attachments, so they're not a "resource". So I don't think there's a good way to search for them, unfortunately. I'm noting it down as an improvement we could look into, though
  3. @Alexak18 My understanding (I don't work on this part of the system) is that normally the client tries to do synchronization as efficiently as possible-- it keeps track of the version of the data it has from the server, and when it syncs it downloads only the stuff that happened after that version. In the case of big updates or local database corruption, an incremental sync like that doesn't work because the local data is broken. What this does is force it to start from scratch and download everything from the server.
  4. I brought this up with the people running the branding redesign, it sounds like there are already some plans to improve the login visibility/flow. @MtneerInTN I can reproduce the button disappearing, it hides at 1100px, possibly a side-effect of the left menu collapsing.
  5. I glossed over a little of the complexity there-- technically the terms dictionary is stored as a prefix-tree of blocks, where blocks are a fixed size. So It can navigate the prefix tree a little faster than a binary search, but terms that share that prefix will all be in the same block. But there are actually two separate structures at play there, there's the term dictionary and then there are inverted indexes for each term. But yeah, a note is indexed by setting up fields, the main text ones being tokenized and then inserted into the dictionary and put into the inverted indexes for those terms. That makes sense for a local search, but becomes a bit more dubious for server-side search (that's what I work on), because expensive queries don't just affect you. So the natural thing that occurs is "well, let's prevent you from doing it too much"-- this touches on rate limiting and fairness, which are surprisingly complicated in a distributed system (they're not unsolvable, but they're tricky enough that you can mess them up pretty easily). Local searches are a bit of a hairy beast as well, but because the different clients have separate local search implementations, much to my frustration. So... in both cases yes, it could be done, but it's not as easy as it should be.
  6. @galaxywarrior search relevance is something we're actively working on. As pointed out by others, the Mac client has relevance, but it should be coming to the beta web client too. It will be a little fancier than just prioritizing titles, but that's definitely a part of it. As far as I know, any case where you can do infix search (like "*term*") is handled client-side. So like the client has already acquired the list of tags you have and may do a local infix search through them to find the tag, and then actually search by the tag's guid. I would like to be able to support infix search, but when you're dealing with a large corpus of data (and searching across all note content in an account can definitely count there), infix search has pretty serious scalability issues. Like it's usually fast to do an arbitrary regex on a single document, but 10,000 of them and it starts to be super slow. In a scalable search system (i.e. one with an index), the way a search works is: Take the user input and break it up into tokens, joined by some operator (in our case, AND) If a token isn't set to a particular field (like "title", "tag", etc), set it to the "all" field If a token has wildcards, check the term dictionary for that field to find terms that match, and expand the token into a search for each of those joined by "OR" Now find the list of documents matching each of those terms by looking in each term's index Join the list of documents and rank them (such as by term frequency) Return the ranked list of documents For the expanding the token wildcard part, a final wildcard is pretty efficient-- you can binary-search to efficiently find the region of tokens that will match (or find that there are none), and then just scan from there until you've got the whole clump of them, because they will all be together. A leading wildcard, however, doesn't guarantee that they'll be together, so you have to scan the whole dictionary. (I have some crazy ideas about how to make this more efficient, but suffice it to say that it's annoying/expensive enough that you'd really need solid ground that people would use it). If you have both wildcards, then... that's an even more complicated problem to solve. Because final wildcards are so easy, and it's pretty common to want that sort of expansion, we add those automatically. So searching "hello" will be automatically converted to "hello*".
  7. @s2sailor Hm, you're right, it's missing there too. You can still do it with ctrl+cmd+k (or via the Format>Styles menu), but it's not in the formatting bar.
  8. I'm guessing it's the non-beta web client (which is using the older editor since the new one broke a while back). Edit: looks like it must be the Mac client, actually @Allison Jaynes You can get those extra formatting options back in the beta either web client, which you can opt into from the settings page. (the beta is missing a few features itself at the moment, but those should get in eventually). You could also try the checkbox lists (and then check completed items instead of doing strikethrough on bulleted/numbered lists).
  9. @llewellen This happens in all browsers at the moment. You can manually go to https://www.evernote.com/Settings.action to change it there. This is supposed to be fixed with the next web beta release, which should be today.
  10. @Mel Matsuoka I believe this is controlled by the OS, you can disable it in System Preferences > Keyboard > Text > uncheck "Use smart quotes and dashes"
  11. Unfortunately searching by emoji is not something we're currently planning to support. I did actually do a little research into how we might be able to do it, but... it's more complicated than it seems
  12. @PDittis If you opt into the beta web client (from your account page), you can highlight there. Highlighting was one of the features of the common editor that got broken in the current web client (so it's now running off of an older web-client-specific editor).
  13. You can get to it by clicking the notebook icon in the sidebar (the one highlighted in DTLow's image).
  14. You're right, this isn't supposed to really be human-readable. It looks like clients can set it, but they're not really supposed to (initially, anyway), in which case the server supplies the current timestamp (a 64-bit integer). But clients could overwrite that with any integer they choose (for example, when rearranging reminders in the list, in the Mac client at least). So viewing it as a date makes... a tiny bit of sense, but is mostly misleading.
  15. @McVitas There's a Google App Engine outage (which we use) that's affecting us. Edit: should be back now
  • Create New...