AlbertR

Yep - but sorting by tags and displaying/sorting by reminder [done] times in a normal note list is a simple client feature. It never uses any data from within a note (that might be not cached so far). Note titles, tags und other properties are stored in tables that are synced long before note content is available at the clients. So this functionality might be implemented completely without any link to the server - even when working offline. To make a column sortable needs a simple property setting in the gridding tool. Every SW developer knows this. To make a column viewable in a gridding table not that easy - but only because you need the possibility to configure grid columns. EN's SW developers know how to do this because it is done already for other properties.

Because I've defined my tag names with a clear plan (starting with a special character that groups tags by their usage). Some details are described in Tag Editing, Adding now has more friction this makes use of Evernote as a knowledge system weaker Ability to sort by tags is very helpful during research activities to narrow down fuzzy searches. And the ability to sort by reminder [done] times would be very helpful also 😉 Both are not soooo hard to implement because data is available and every gridding tool is able to sort by any column...

OK, works fine - but is not what the OP asked 😉 He/she/we hope to get this result when pasting to Excel (and you know: like EN-L does when copy/pasting to EXL...) But since we are at it: EN-before-L pasted a valid URL ("evernote:///") to EXL whereas EN-L uses the weblink URL ("https://") - but decorated by the note title in both cases. EN-L will not be changed, OK. But EN10 should work as follows: If I create a weblink and paste it to Excel or somewhere else the weblink should come up with note title and https://-URL in behind. If I create an internal link and paste it to Excel or somewhere else the link should come up with note title and evernote:///-URL in behind. Windows (and I strongly believe other OSes also) support this functionality between apps that are enabled to use it.

So, please define "weblink". For me a weblink contains an URL (https://www.evernote.com/shard/...) but shows readable text (title of the note). If I create a weblink in EN and paste it to Excel or somewhere else, only the URL text comes up. Excel changes this to a real URL (hotlink) - but the readable text (note title) is lost. If I create an internal link in EN and paste it to Excel or somewhere else, only the URL text (evernote:///...) comes up. The readable text (note title) is lost. Here's my example: BTW: Legacy works correct 😉

For me it appears as "a bug is a bug". And it shows up only in the Windows-app. Android, iPad and Web are OK (do not list the very old notes...) I'm in contact with support. They told me that they're working around issue(s) around unnecessary touches of "updated" times. Not exactly my incident here - but nice to hear that they're working on it 👍 My opinion: A note change is meant to be a note content change. Changes around the note’s tags, location, creation and reminder dates are no content changes. These informations are often used during research and management activities in EN and must not change the updated timestamp.

I'd like to describe what my standard note decoration is: title: <who> - <what's to or general theme...>[: <amount>] creation date: always adjusted to the event, activity, release or publishing date of the note's content reminder date: until I have to do something (newly set if current milestone is reached...) reminder done time: only set if really all is done... location(notebook): only used to categorize epic sections like "Family", "Work" "Banking", ... tags: to categorize = <what> is content _ <who> is involved @ <where> tooks place ~ <whom> from whome or where it got the initial information < <year> to easily group notes by a year § <location> to describe a physical location where important (non discardable) paper docs are stored > <when> like "1-now", "2-next", "3-next-...-Meeting", "8-wait", "9-deposit"... This allows to use favourite searches like "tag:=bill tag:>1-now -reminderTime:day+3 -reminderDoneTime:*" to list all bills to pay within the next 3 days 😉 And it describes, why the easy use of tagging functionality is such important to me (to come back to the topic of this thread). managing creation, reminder and reminderDone times is basically necessery (but not really useable in EN10 so far)

Did You use the same Windows users whilst installing and using 10.56.9 and after restarting your LT?

I used a favourite search "updated:day-1" which means "list all notes that are changed yesterday or today". This works perfect in Legacy. In EN10 this search pattern lists all notes that changed yesterday or today 👍 all notes that are created yesterday or today 🤔 Legacy does not list those because it distinuises beween "created" and "updated" - once I only create a note - it is not really updated - correct in my mind) many note that have a changed dated long ago in the past 😞 I'm not using EN since 26 years 😉. These days came with my workflow - I change the creation date after a scan to the date an article has been published (before changing title and some other things...). In looks like legacy did NOT change the "updated" information in this case but EN follows its new rule "create implies immediate update" and works incorrect if these dates are very old... I tried to rebuild my local database with no luck. Web-version does NOT show the incorrect list. I'll place a support ticket in parallel. Is anyone there who has seen similar effects?

... and cannot get a friend of the new placement. It's a UI design fail 😞. Hope they'll give us a possibility to change it. And (excuse me for replaying my request): Result list should be sortable by tags! 🙏

Interresting... This means that offline-created notes are stored (correctly?) but are invisible until they have been synced? So EN seems to store those outside its working datasets. We had (and have) similar (but not exactly the same) effects with Legacy: You cannot add an internal link to an offline-created note because creating unique note IDs has been managed by the server... So oneline-created notes have been incomplete in this manner. But they are visible in Legacy all the time. EN10 creates unique note IDs even in offline mode - so I assumed that working completely offline has been enhanced. 🤔

I met this also with newly created notes on one device that take (tooo) long to be available completely on an other. There is no conversion necessary... But it is hard to reproduce 😉

Honestly? To me it was a no-go that tagging changed the updated date because it's often used temporarely during researches (but seems to be fixed now). But simple reading of a note is for sure not a reason to change the updated date! This is for sure a BUG on iPhone and iPad (on Windows it is OK: no change...).

I use Make and can confirm that there is the now known problem with the "RTE room already opened": Within Make you trigger so called "Scenario" by time definition. As a workaround I move execution times to times in which I surely do not work interactively with Evernote. This is not a valid workaround for Filterize: Here I have defined some filters to be triggered by tags that normally come up during interactive work with Evernote 😞

[@PinkElephant] > EN would need to support long term 2 different syncing methods. In the clients, on the servers. My proposal is not to have different methods: YJS is OK - but should be narrowed down to a short timeframe - as a workaround for users that meet problems with foreign services for some time. > If there is a sure way to ruin any company, it is this sort of half baked strategy. It means loading addition cost on top of the core functions, without a significant gain. Sure - but IF there are strong problems on service provider sites, delivering RTE without having seen this, the timing was a fail ("half-baked" 😉) Now RTE is out, the only sustainable strategy is to work out the glimpses, and shut down the old code base ASAP. Yep - and ONE strategy might be to find a workaround for the next time. [@Boot17] > Seems like (1) ... and (2) .... and (3) ... ... or (4) EN tries to charge $$ for (full) API access to specific accounts 😉 (like Twitter a.o. do meanwhile) But even if so - it's half-baked to release RTE as a must with a simple update.

Not really. If you... add tags ("January", "February", ...) add tags ("2023", "2022", "2021", ...) select all notes with tag "May 2023" apply tags "May" and "2023" and remove tag "May 2023" from all these notes in one operation do this for all of your old tags This seems a lot of work either. But you will save much time in future (after having solved your syncing problem first 😉) Regarding your syncing problem: Sorry - cannot reproduce your effect on my machine(s) 😞

Sure - but where's a problem? Every account has a set of options (properties) that define functionality that is allowed (supported) for that account (i.e. #of clients, upload limit, support of spaces a.s.o.). It's no problem to add a flag "RTE enabled" internally to an account dataset. First you need a possibility to manage the flag from user's site. They've to extend "personal settings" of your account page (like "Web client V10+ active" - simply a flag within the account dataset). Any client that see "RTE disabled" opens the RTE room only in well known situations (after an editing window of a note is closed or on request with a sync button), sends changes (only if there are any) and immediately closes it after sync is done. This minimizes time slots with open rooms to an absolute minimum. There is no need to change anything on server site.

You may use Legacy only 😉 Or (sorry @Scott T. for citing myself): Wouldn't it be a solution to offer an option to disable RTE for specific EN accounts? All clients (including EN10 before the switch on all platforms) are able to work without it... And for these accounts, your servers have no additional load with converting notes to and from the formats...

OK, sorry. In that case it's the right answer 😉 I can image that implementing Document Updates in a brand new (and up to now not documented) API will need some time and resources 😞. But as and @Scott T. mentioned that EN uses YJS as a Conflict-free Replicated Data Type (CRDT), edits in EN should be possible simultaneously to API changes. An app has to be able to enter an already opened RTE room... 🤔

You are talking to end-users here - so "evalutate your retry logic" is not really a good advice. IFTTT, Make, Filterize and others are sitting between EN and us and we have nearly no possibilities to affect the retry logic. Example: Make simply deactivates a scenario completely after (too much) fails 😞. Only users that access the API directly with own apps may check for closed RTE rooms and wait some minutes before re-executing the failed request. It's a hard job to get all the service providers to fix their interfaces now. I'll keep my fingers crossed...

It's not Windows - it's a problem of the apps 😉. Windows allows to copy information in many different formats to allow consuming apps to choose the best to match best results. In this case EN has some problems... If you try to copy&paste note text that contains embedded PNG-pictures, you will see that EN itself receives embedded files (PNG and|or XLSX or whatever. But at least the pictures will come as attached files (not embedded pre-viewable picture). Other apps (like Word) do not understand EN-written clipboards completely -> EN does not write it correct because other exporting apps are able to copy text and pictures to have Word understand it.

Ok, THX. Now it's time to add EN to the list of "Who is using Yjs" 😉

Hmm. This is my Help menu: But then I tried STRG-Help (CTRL-Help, a nice trick known from Legacy 😉) and found So THX But "Problemlösung" ("troubleshooting") kept available only until EN has been restartet 🤔. And: they forgot to translate this submenue 😁 - I think it's not really supported...

Sorry (don't laugh): Where can I find this dropdown?

We hope your client (UI) development team will come to that an open discussion job like You do here, @Scott T. 🙏 Around my workflow/usecases: I collect information with IFTTT and Make, have defined workflow helpers with Filterize and Make and organize my daily work with tags, reminder times and saved searches. Up to now, EN10 UI causes some trouble with fluidy operations. RTE might help in future. To find the right time to switch from Legacy to EN10, I try to use it in parallel - but often get syncing problems in Legacy ("RTE room open..."). OK - my suggestion so far is not to use it in parallel. But for my helper applications (that rely on the API) there is no workaround as long as they itself cannot "wait for RTE room is open". They simply fail in unexpected situations. My example: I set a tag ">4-in-a-week" on a couple of notes, Filterize collects the notes, sets an appropriate reminder time and removes the tag. This workflow did a good job for a long time. During the last weeks it sometimes failed for some notes - maybe because they're locked by RTE? Nobody knows ... 🤔 Wouldn't it be a solution to offer an option to disable RTE for specific EN accounts? All clients (including EN10 before the switch on all platforms) are able to work without it... And for these accounts, Your servers have to additional load with converting notes to and from the formats 😉

@Magnus Lidbom: Yes clicking on an internal link from within a separate EN window should open the target note in this window (like in Legacy) and surely not in the main window. I will add this to my list... But there is workaround: If you CTRL-click on the link, the target not opens in a new window (like SHIFT-click does in Legacy). Nobody knows why this behavior has been changed and|or will be re-changed in future or will be configurable 🤔 And regarding support: I also have met novices - but I've been moved to second line and even development for some (OK, rare) times in the past - so you must not give up 😉