John in Michigan USA

OK here's what I posted on FB re this video. First comment: I was very encouraged by @Ian Small's prompt reply:

Maybe it could attach the original headers (or even the full source!) to the note as a text object? That way they'd be preserved, and searchable. I like the idea of being able to forward something by email to EN without having to save the original in my email system in case EN mangles it when turning it into a note.

I just made some feedback I'm quite proud of on the Facebook version of this announcement. Should I re-post my feedback here, or are people able/willing to follow the link and tell me what I got wrong over on Facebook?

Must have missed that. Got a link?

Thank you for all that detail. My thoughts: In EN for Windows, restoring the database files themselves (everything under C:\Users\<userid>\Evernote\Databases) does preserve note history, it restores the database to exactly where it was when the backup was made. Can restore to a temp location and tell EN client to use that location while you restore what is needed. I looked quickly at the enex format spec and didn't see anything about history. Are you saying the enex format preserves note history? Good to know. Also, I just re-ran a test that I haven't done since Jan 2017. Turns out EN for Windows does preserve note history after you move the note to a different notebook. Great news! I wonder when that changed? Will it change back? Anyways, thanks for pointing that out.

I forgot to say, I haven't tried exporting a note, or saving it in enml, but I doubt either of those formats keep note history.

An advantage of keeping your own backup of Evernote is, when you move a note from one notebook to another, the note history doesn't come with it, and is therefore no longer available to you. Evernote will NOT restore this note history, even if you undo the move. But, if that note history was important, you could restore (or extract) from your backup of the local EN database.

So far we've seen mostly UI presentations. IMO the improvements with the highest return, BY FAR, are to be found in the area of code quality, regression testing, operations, etc. I hope that gets covered.

Have you opened a ticket? If you get a chance, can you post the version info (from the activity log, not the settings) here?

That kind of backup is secure vs. equipment failure (yours or theirs) but the most common use of backups is to recover from user or admin error, e.g. accidentally deleting something or discovering a bug that causes corruption. In which case, unless you are lucky and discover the problem before sync happens, relying on Evernote's backups to help you recover is no good. They will only 'restore' your account to the most recent version of it, which would be the corrupt version in this scenario.

Hi @NanetteK, I have this type of problem too. Unfortunately, Evernote's text editor has many issues, particularly with cut-and-paste. I use the Windows and Android apps, and sometimes the Web, but the iOS folks have similar problems. Cut-and-paste that involves checkboxes are particularly a problem. They've been promising fixes for ages, and there have been a few, piecemeal fixes, but there have also been new bugs introduced into the editor. To make your problem more clear, at minimum, you should include information about what device you are using, and the version numbers of all relevant software/apps, including the Operating System. Additionally, it looks like the problem you are having is the kind that is hard to describe in writing. Perhaps you could try making a video of the problem happening on your device? Upload the video to YouTube, then post the link here in the forums. I can't say if that extra effort will result in a fix, but it will make very clear exactly the problem you are having.

Had to factory reset my Pixel 2 XL for reasons unrelated to Evernote. After re-installing all my apps, I am running EN 8.9.1. The saved search problem is back. Exact same symptoms as ticket #2804215 which forum users can read about at:

My saved searches have also gone missing, except for some (not all!) of the shortcuts that point to saved searches. HATE THIS.

If I read correctly, the OP has access to both Mac and Windows clients. The GIMP has Linux, MacOS and Windows flavors. Re the Applescript approach: you would probably have to include a step to access the EN API, in order to tell EN to sync the changes?

Hi, I think this is a windows problem. But the image capture started on Android, so I've included that info too. EN 8.9.1 on Android 9 on Pixel 2 XL. EN 6.17.7.8474 (308474) Public (CE Build ce-62.1.7539) on Win 7 To reproduce: EN for Android: Use the plus icon to create an new image note. Capture 1 image, include a few lines of text if you like. After sync, the note size reported by EN for Windows is 923 KB Using EN for Windows, right click the image and rotate counter-clockwise. The note size is now 1.1 MB. Using EN for Windows, right click the image and choose Annotate. Using Annotate tool, crop the image to about 50% of it's original size. Apply the changes. On the menu, pick Save and Exit to return to EN for Win. The note size reported by EN for Windows is now 2.4 MB! I definitely recall this being a problem in the Windows client several years ago, but I've searched the discussion forums and can't find any mention of it. Is this a known issue? Time & mood permitting, will open a ticket...

The GIMP has nice features for batch editing, and fully supports command-line options. Perhaps there is a way to use the API, or (!) a screen scrape from the Web client, to automate the process of correctly sizing images and sync'ing those changes.

Please can there be coverage of the effort to: address the backlog of bugs (real acknowledged ones, not necessarily complaints about how things are designed, or feature requests) improve regression testing tighten up the beta process so changes aren't released straight into production better version control

Yeah there are different display modes (not just formatting of results, there are different controls available) depending on how you search. In most cases, there's no clear UI design rationale for using different modes. For example: I'm very thankful for reminders, but they weren't part of the EN design concept. They were shoe-horned in shortly after I starting using EN. That would date them to 2011 or 2012. Some search results modes were updated to deal with reminders intelligently, other modes were not. With well designed code, search results are rendered by the same object (block of code), regardless of how you search. So, changing that code to handle reminders would have solved the problem in all search results. This is more evidence the EN code base needs to be re-worked. No wonder it is so hard for them to make changes without introducing more bugs!

We've been asking for better communications. Here is a start

Shouldn't it sort properly, whether it is sync'd or not?

Several people here point out that, although search is now working again (huzzah!!!) the fix appears to have triggered some other problems, like search string highlighting, clever release notes that are now too clever, and more sub-version confusion / fly-by-night updates. I also found that they took away a feature that displays items with current reminders at the top of the results. I wrote about that here.

@Shane D. Thank you very much for following up! I say cautiously that it appears to be fixed. It appears that the fix was accomplished by removing another, possibly less important feature: the ability to highlight reminders in the search results. I've detailed this in an update to "EN support ticket #2804215 screen shots and annotations" (look for the paragraph dated 5/17/2019.) If I had to chose between saved search working and the reminder highlight, I'd chose the former. Ideally I shouldn't have to chose. Thanks again for your excellent follow-up Shane.

Well, it looks like the problem is more complicated than I thought. @Hermitapp it does look like some EN behavior changed. Unfortunately, based on recent history, Evernote is unlikely to restore that earlier behavior.

Did you give it time to sync? If so: what device, what version? Get this info and open a ticket, support should be able to help.

I don't think this is a bug. The code you selected is plain text. The color is added by the SAP R3 editor (IDE?). Unlike a word processor, which copies rich text (text with font, size, color info) into the paste buffer, your code editor copies plain text. So when you paste into Evernote, there is no color. I am guessing that OneNote has a feature that auto-detects code and colors it for you (just like your code editor does). In other words, the color isn't copied, it is re-created by OneNote after the paste completes. That is why the color appears when you paste the same selected text into OneNote. In some Evernote clients, after you paste you could tell Evernote to format the text as a code block using the ``` syntax. See https://help.evernote.com/hc/en-us/articles/360001758468. I only have EN for Windows and Android, so I can't tell you if Evernote will color the code block for you. Did you look to see if there are third-party add-ons to Evernote that will make Evernote auto-detect code for you and color it? Or, you could copy a screen shot into Evernote. This would preserve the color. Evernote would use OCR to make the text in the screen shot searchable, but it wouldn't let you easily select the code in Evernote and paste it someplace else as plain text code. Finally, there might be a setting in the SAP code editor that tells it to copy/paste code as rich text, instead of plain text. Hope this helps.