AlbertR

Just for my understanding: Legacy was able to generate and hold a local index for search. If all note stuff was synced to the local device, it was/is possible to work completely offline (with the exception of generating links to new notes - which is possible only after syncing the new note because the note's GID is generated on server site). Question: Does EN-10 also generate/hold a local index to support offline work in a similar manner? And if so: Why wasn't it implemented to generated backlink information also during local index generation?

Oups - I did and do this every day and it works! Internal links between notes are based on an unique internal ID with no relation to the notebook they're stored in. (See @PinkElephants explanation some posts above...) Yes, of course 🙂 - after a short time that is necessary to update server databases. The new note that contains the copied link has to be synced (which will be done in the background...) (@Scott T. please correct me if I'm wrong with the assumption that backlinking is calcuclated on server site...)

OK, we're ready 😉 - hope they do not forget to make it only a (non-default) option so far. If (partial) syncing fails, it will be a nightmare for their support personal. Syncing problems are not reproducable (in most cases) and may cause big data corruptions. But to be honest: Nobody needs collaborative editing within his notes. Even in Business environments this causes trouble very often...

Have added three exacly because of reasons explained above with "updated with every display of a note". This would reduce server load but offers great possibilities to create TOC (table-of-content) notes where needed. And if "##backlinks##" would have possibilities to format the backlink-URLs like "##backlinks@bullets@upd@title##" it would be a real killing feature 😉 (wheres "@bullets" means "create a bulleted list, "@upd" to insert the update-time of the referenced note, "@title" to insert the title a.s.o.) These formatting possiblities might be defined globally (even better?) to display all backlink-list with the same format (within an EN-account)

Yep - I'm not losing notes. But it's possible to lose changes within attachments if EN-Legacy does no recognize the death of programs that changes the attachment. I've tested it in EN-10 (Windows-APP) and found, that this problem seems to be solved now: EN-10 does not linger for the death of the program to re-insert the changed attachment. It permanently checks like a watchdog for new versions of changed attachments and re-inserts it to the note immediately after it has been saved by the handling program. Example: Insert an .XLSX file to you note Double-click to open it in Excel make some changes type CTRL-S to save it in Excel (without exiting Excel) EN-10 catches the changed .XLSX file and re-inserts it to the note This is a real improvement! 👍🙏 PS.: This is only possible in EN-10-App. Browser-based clients cannot work in this manner because a Double-click simple downloads the attachment. A browser normally has no possiblity to check local file changes. And: You may see syncing problems during such tests. In my case, notes with changed attachments have bee doublicated very often ==> one reason not to work with EN-10 (and continue with EN-Legacy) as long as syncing is not working as expected 😉

Now as it is available, client's should be enabled to open a backlink in a new window copy the list of backlinks to the clipboard to paste it elsewhere 😉 and/or give us a possibilty to insert a list of (dynamically generated) backlinks within the note text (updated with every display of a note) - something like "##backlinks##"

Not exactly 😉: In Legacy attached file is extracted to a "Attachments\" Folder - then edited there and re-imported later to Evernote's DB. If the re-import fails for any reason (EN does not recognize the end of the launched handling program, ...), your edit may be lost... These situations may occur if the lauched program is able to handle more than one data file at time so or it is not terminated after your data has been saved to the Attachments\-Folder.

Yep - that's my reason to pay for a Professional account - as long as Legacy is "supported" (means: able to handle my records for EVER): Up to now all extensions to the internal note representation on server site are implemented with backward compatibility (means: not destroying any records). 👍🙏

I'm completely with you. Long time ago I started to log my requests on a personal web page EN-10 - was mir noch fehlt (sorry, is in German - but many of you will be able to understand it 😉). I think I've to update this page the next time because EN is working hard on EN-10 👍

... or not 😉 On my Android-Mobile I can see the the small little green icon - but not in WEB 🤔 - even after starting it from a completely new Windows system and after the backlinks have been used within the Windows APP. But I think this feature is it worth to wait some time so see it stable on all platforms 👍 PS: Because most functionality is implemented on server site, it should be enabled in Legacy also - as a very last concession to this good old great flowy and heartly beloved program 🙏

Yes - and because of this (as it is server-based functionality because a client doesn't have to have all note bodies locally) I wonder why this feature did take such a long time to be implemented 🤔 Now as it is available, client's should be enabled to open a backlink in a new window copy the list of backlinks to the clipboard to paste it elsewhere

Maybe I'm too gullible - but if a user uses EN for 10 years, he knows the background of the idea and benefits of the architecture behind it. If he is interested in EN, he believes in this and will not waste money for any other reason.

Reaching real support is hard. They try to lead you to help pages, forum etc. to avoid additional work 😉 I rare cases where I need support, I'll go the following way: Open browser and go to https://www.evernote.com, log in and verify that your web interface is working Go to https://help.evernote.com/hc/de/requests/new to enter you request directly

It's common to many programs to have some hard-coded default settings, use system configuration files (that might be overwritten with every update) and in a 3rd step allow some user specific configuration files to overrule internal settings. I expect (hope?), EN uses this mechanisms - but we users do not know it so far... I've found https://dev.evernote.com/doc/articles/enml.php that describes the principles of text styling mechanisms of EN. In chapter "Styling note content" they write "not allowed" sounds like a hard-coded rule to disallow content like "<link rel="stylesheet" href="styles.css">" within note bodies. So please tell us how to overrule this by any hack (in EN10 and Legacy) 😉. I use EN pretty much as it was delivered before years. I've no selection limit - but layout bothers me in some (OK - not vital) cases. I often take news, remove unnecessary typographic art (by selecting text and typing Ctrl-<BLANK>) - but want the result to look fancier around text block distances, table outfit and headline sizes... Use cases are different, I love fellow users who would like a little more flexibility. 👍

@PinkElephantDo you have the following in mind? At the end of this discussion @avernet mentioned a tool to change EN's appearance (as an Electron app) by changing CSS files. I think @svirsky (and myself) is interrested manly in finding a solution to modify CSS defintions of note text only. Do you have a recommendation for that?

#-characters are used withing html:-URLs to seperate a server part of the URL from information that is interpreted on client side (within the browser). EN10 seems to do its best to handle this (over-developed and simply wrong in my eyes) 😞 In file:-URLs #-characters does not have a special meaning, so at least with that, EN10 should not change anything. Evernote Legacy has no problem with this. You may use the older version until Evernote fixes the bug - but be not tooo optimistic 😉

Oups, JavaScript for small-granular syncs with a far-away located server farm? I'm afraid of seeing a not only minor problems coming up...

Normally I'm with you. But in this case (changing sync methodology) I'm afraid of seeing a not only minor problems coming up. How will Legacy work together with new sync in EN10? Legacy's sync based on whole notes worked great for many years. Nothing could be lost because the note history caught every whole note and made it available later after accidents. ==> Using new sync methodology should be a configurable option How will new sync work during note editing sessions? If I move/delete/copy portions of my note text, I do not want to get all my doing synced immediately. It's completely unnecessary to set fire syncing events during such editing sessions. No server and no network on this world will be able to handle all editor's actions immediately... ==> Using new sync methodology should be a configurable option How should a user describe problems to support people and how should they reproduce problems? From my point of view a new sync methodology will be a night mare for the support 😞 ==> Using new sync methodology should be a configurable option (to offer a workaround to those who get problems with the new...)

"new" search method is the same as already known with the exception of the default "intitle:" search. This might be a good idea - but not the tricky "inbody:" mode for tokens after a "tag:" or explicit "intitle:" phrases at the beginning of the search term. Even "-tag:*" is an already known construct to find notes without any tags 😉 This is and was true all the time and has a technical reason: Search operations that are based on internal index tables normally cannot support wildcards at the beginning of a token because calculation an index for any word starts with the first character. Even Google didn't support this for a long time - until they found a better solution for this problem (don't know how - too high for me 🤔)

If Title-Only-Links (or call it "life links"?) would be displayed inline, this is not a problem because inline text will be wrapped along with the window border. To make it easier for the developers at EN: There is no need to update life links in already displayed notes (if the title gets changed in the an other window or in the background by sync activity). It is completely sufficient to use the title at the moment of a display. If a user closes a note window and redisplays it later, an updated (referenced) title will show up updated 😉 And don't argue about any performance problems to display life links: the local cache of all notes is fast enough to deliver note titles. You show this already in tooltips when hovering the mouse cursor over internal links: it always shows the current title of a referenced note 🙂 BTW: If EN needs a non-text object to implement life links, it's a design fail (completely overengineered): To represent a link in HTML (and the base of formatted note text based on HTML), you use phrases like '<a href="evernote:///view/...">Text to be seen</a>'. It should be possible to implement tokens inside "Text to be seen" like "?T", "?D", "?R or "?U" that are to be changed to the referenced note Title, creating Date, Reminder date or Updated date when the text is displayed Example : '<a href="evernote:///view/...">?R: ?T</a>' would display the reminder time and the note title - completely inline with no further useless decoration

I would like to see the current note title of a link inline. BG: I often change titles of notes (i.e. to reflect the current state of an action that is described within the note body). This makes it very easy to show states in note lists. If I refer to such notes from other notes, only the title of the moment I create the link is shown in a text link 😞 New Title-Only-Links do exactly what I need - but their display format is not what I (and hopefully others) want to see 🙏

3) Preview Links (Title Only) should be displayed inline with the surrounding text (like it is already the case with text links). Currently Title-Only-Links use a new line with no possibility to add text just before or behinde the link.

Done. See 😉

OK, if there is no space between "tag:" and "English", you really specify "only tagged with English". This works as intended. But if you use any token with "tag:..." or "intitle:..." before the word "English" (i.e. "intitle:* English), EN will search "English" in all note bodies. I assume this will find much more notes in your case 😉 Yep, strange... A <TAB> should move the input cursors from one input field to the next field. A list of lines is a field, so <TAB> should move the focus to the fields below the list (and <SHIFT><TAB> should lead back to the input field).

You know, I'm a Legacy-fan - but to be honest: Ctrl-Alt-K is a really nice feature of V10 👍. To summarize what I've learned in some other discussions around this (mostly off-topic in these other threads), I start this new one to concentrate on this. Here is what I like: Within my >9k notes database it opens immediately and shows all top-level notebook stacks and notebooks (no notes - and this is OK). 🙂 If I type simple words every single keystroke fires an internal search cycle that narrows down the result list of notes below the input field 😀 Without other options, only note headlines are searched - but in a somewhat intelligent mode: similar words (with some spelling difference or german "Umlaut"s like ÄÖÜäöüß are recognized in parallel to exact matches.👌 If I'm looking for exact matches (to ignore EN's intelligence), I've to in insert "intitle:" before the word to search for (i.e. "intitle:buch" finds only notes with "buch" in title - an not "buck") 👍 If I'm looking for notes that are tagged, I can insert "tag:" just before my tag name I'm looking for (i.e. "tag:=rechnung" finds only notes tagged with tag "=rechnung" (the german word for a bill 😉) All these things can be combined like "bol tag:=rechnung" (which means "list all notes with something that sounds like 'bol' and are tagged with '=rechnung") 👋 But there are (as everytime) some things that should be enhanced in future: If I use any search options like "intitle:" or "tag:" as tokes before normal words, EN searches text bodies of notes for the normal words. These is awesome and seems like a unintended or not fully implemented feature 🤔 EN should offer a search option like "body:" to force full text searches... If I type <TAB> to select a specific (found) note as a result of my search, the arrow-buttons (<UP> and <DOWN>) will scroll the whole result list up and down. 👎 I expect <UP> and <DOWN> to move the cursor within the list up and down to be able to select a specific note with <ENTER> EN should change the keyboard mapping within the dialog to follow common standards (use <PG-UP> and <PG-DOWN> to scroll and <UP> and <DOWN> to move the cursor)