Jump to content


Evernote Staff
  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by rezecib

  1. @njgould On Mac this sort of login would not be very meaningful from a security perspective, because it has an index locally on the disk that could be used to reconstruct the contents of notes. This is necessary to allow for local search (when you have no internet connection).

    If you prefer the other behavior, I'd recommend trying out the new web client, which has most of the features of the Mac client aside from that local storage/search, and would require you to authenticate regularly.

  2. That's a really cool system, I'm taking notes :P

    Some other symbols that seem to work, with some potential uses I came up with just now:

    %status  // percent progress, status?
    =title   // like wikitext formatting, == Title ==
    $finance // cash money
    `code    // like the markdown `code here`
    <input   // something to process?
    >output  // something that needs to be sent out?
    ~misc    // I couldn't think of anything


    • Like 2
  3. @laird I don't think there's another way to nicely access the edit/remove controls for links (although the link button at the top is... okay I guess), but here's a Tampermonkey script to hide them:

    // ==UserScript==
    // @name         Evernote Link Hover Controls Disabler
    // @namespace    https://www.evernote.com/
    // @version      0.1
    // @description  Disable hover-over link controls
    // @author       rezecib
    // @match        http*://www.evernote.com/*
    // @grant        GM_addStyle
    // ==/UserScript==
    (function() {
        'use strict';
            #gwt-debug-FloatingLinkBar-root {
                visibility: hidden !important;


    • Like 2
  4. I feel your pain on this. I don't work on anything client-side, but for what it's worth I gave it an upvote.

    For now, cmd+A, cmd+shift+K (or corresponding ctrl commands for Windows edit: ctrl+A, ctrl+R) should strip out all links pretty fast. I know it's not the same, though, especially if there are a couple of links you do want.

    Also looks like on Mac client selecting some text and doing cmd+shift+K actually removes all links from the document rather than just the links touching the selection. Bug report time...

  5. Tagging features are a little different between the clients, but all of them should have a Tags sidebar entry / section where you can view all tags, set hierarchy for them, and rename them.

    You can do bulk-tagging in the note list of the desktop apps.

    There is a... "hidden" index that supports search, but I guess doesn't quite replace the scenario of skimming an index to see what's there. I don't know of anything we have for that right now.

    • Like 1
  6. 8 minutes ago, janstet said:

    Still no updates on the "blank note list" bug that has been present for over 3 months now. No mention of this issue in any of the release notes. 

    The case that I found for this (do a search for an invalid stack name, then search for the valid one) seems to be fixed in the current nightly. If you have another set of reproduction steps I can check if that's fixed too.

  7. @fornix @cynthiayeung Hmm, I would've expected code blocks to be in the app store version. There's an option in the app's preferences for it-- in the app, Evernote > Preferences... > Software Update > Enable code block (at the bottom). Maybe they're saving config in different places and it happened to be disabled in the app store version's config? Edit: Software Update tab doesn't exist in App Store version, which I guess makes sense. I submitted a bug ticket for this and it seems to have caught some attention, yay.

    @sgtsunshine I would love to be able to tell you otherwise, but I haven't heard anything since, I think the plan is still to "fix" it by releasing the new web client as soon as it's ready. It's possible that third-party wrappers of the web client like Tusk may still be able to support it (if they are using an older version of a browser embedded), so that's something to look into if you want it back sooner.

  8. So exact phrase searches do work in general (this is part of our integration test suite; but if you do find a case not covered by the explanation below, definitely let me know). However, the case described in the original post has a bit of a wrinkle to it: "stop words".

    TL;DR: common words don't get indexed, so you can't search for them

    Long explanation:

    The way searching works is that when a document is created or updated, it's added to several "inverted indices". Each index maps terms to documents and their position within the document. So there will be an inverted index for "object" and one for "oriented", and a search for "object oriented" will first check these indices, and then remove any documents where "object" and "oriented" aren't in adjacent positions in that order.

    However, some terms are really really common, like "the" and "in". If you were to make an inverted index for them, it would contain basically every document-- with 200 million users with lots of notes each, that's a LOT of documents. The standard approach to handling this is to just not index these terms; this is called "stop word filtering". This means that these terms can't be found by the search, even in an exact phrase match; it can't do the first step of finding the documents that contain the stop word. It can, however, do mostly-exact matching on phrases with stop words in the middle, like "money in the bank"; in this case it will still ignore "in the", but it knows that it's looking for an offset of 3 rather than 1 or 2 between "money" and "bank". So it would match "money in the bank" and "money hello world bank", etc.

    It would be possible to filter the list of results after they have been returned, in the client, because they actually have access to the note content. So if you want this feature (I can definitely see the use of it), make a feature request for "Filter search results by exact phrase matches in the text, including stop words".

    Edit: Ah, meant to include our current stop word list:

    "a", "an", "and", "are", "as", "at", "be", "but", "by",
    "for", "if", "in", "into", "is", "it",
    "no", "not", "of", "on", "or", "such",
    "that", "the", "their", "then", "there", "these",
    "they", "this", "to", "was", "will", "with"
    • Like 5
    • Thanks 1
  9. Unfortunately no excluding notebooks as DTLow mentioned. You can bulk-add a tag to the entire notebook (go to the notebook, select all notes in the list-- easiest to do in one of the list views-- and then add tags in the bulk actions thing in the middle) and exclude the tag. It's an extra step, but currently the only way to do this. Or you could just use the tag and not put them in a notebook.

    • Like 2
  10. One of the major issues with regex at scale is that it's pretty easy to unintentionally write regex with exponentially scaling runtime with the size of the document. Standard regex libraries also don't usually support safe early termination (e.g. if it runs too long, kill it). So in the realm of possible search improvements full regex is quite unlikely to be added. Even Google doesn't support regex in their search, as far as I can tell.

    We do, however, allow a final wildcard on search terms (and this gets added automatically). So for example "list*" will match "list", "listing", "lists", etc.

    I did have a hack week project to add a more powerful search mode, but unfortunately it ended up being blocked by some clientside query processing. But hopefully that can be circumvented eventually...

    • Like 1
  11. @Limehouse Looks like the highlighting works as expected in the Mac client (highlighting both occurrences), but not in the web client (and I guess not Windows and Android, which I don't have test setups for myself). So this is a client bug, not something you're doing wrong.

    To give some more insight into the mechanics of this, search retrieval and highlighting are done separately-- so in terms of search indexing/retrieval, both "to do list" occurrences will be tokenized into "to", "do", and "list"; searching "to do list" will match both because they both have the same tokens in the same order. Highlighting is implemented separately by each client, done on opening the note with the search context still active. And it looks like some clients are not using the correctly tokenized terms to do that highlighting.

    Edit: a workaround you can do is to add some redundant terms to the search, such as:

    "to do list" to do list

    this will obviously over-highlight, but at least it will catch the cases that are being missed here.

  12. @DTLow I'm not completely sure how clients are determining relevance, but on the backend relevance refers to a score that the search cluster returns, which is mostly based on how many times search terms are matched.

    @emil_a We are working on improved relevance. I see that its current iteration uses a field prioritization kind of like what you describe. No guarantees on timing or rollout, but my guess is that the soonest it would become available is when the new web client comes to personal.

    • Like 1
  • Create New...