eric99

Completely agree, the very agile development process combined with transparent and continuous communication with the community is a real winner 👍👍👍

10.63.3 is great for me: fast note list scrolling with arrow keys, normal note loading 👍

Of course, legacy keeps working because nobody is trying to "improve" it 😉

I've had it frequently on my Windows client last days, and it's even permanent today. Is this a known problem on version 10.63.2 @Federico Simionato ?

Yes, it should be another folder as a relative path. But I agree, that should be covered by the HTML export. Unfortunately there is still an open issue with hyperlinks (for years now), that's why I wrote my own enex to html converter, it supports : working hyperlinks (not working in V10 HTML export) relative note links to other html notes (not working in V10 HTML export) backlinks to notes (in progress) all image types are embedded or navigable, also tiff etc (not working in V10 HTML export) same image sizes as in note (not working in V10 HTML export) all note info is shown in info table (not working in V10 HTML export) create and update time source location, full address where the note has been created and corresponding URL to google maps (not even working in the V10 desktop clients) tags list, starting with '#' to allow search for specific tags encrypted text decrypted with pw dark theme option (in progress) very compact and readable HTML: a single line note is converted to 1 KB HTML while this takes 355 KB in V10 HTML !!! My converter generates a report about enex file consistency problems such as Untitled notes etc The result is a folder structure containing html notes and it's resources, similar as the V10 HTML export folder with that difference that notes may link to each other and their attachments. So it acts as a mini website on your local disk, or you can even host it on your private server if you like...

maybe no "wrapped" files but the pdf format does support hyperlinks to other documents

this is indeed what I see now, but before it was different, every single arrow click was instantly highlighted in the list (without waiting for note loading), so you could type many notes ahead and see it stepping through the list, no need to press blindly the arrow enough times in the hope it will finally arrive at the proper note

As I tried to explain, this is different behaviour than before when you could scroll ahead, no counting needed, you just clicked the arrow key very fast to the desired note and then wait until loaded.

Yeah, but when we had huge RTE delays before, it didn't affect the scrolling through the list, you just could scroll ahead to the required note and then wait until it was loaded completely.

What has happened with note list scrolling? Previously the note was selected immediately in the list, now it waits until the note is fully loaded. This makes scrolling through the list with the arrow keys very sluggish and counter-intuitive...

might be, we are neighbors...

hmm, I get a spinning circle on that link, maybe they want to warn potential customers that this is a popular GUI feature these days 😉

It's definitely a bug. If they tried to fix it, I don't think they would need the export of the untitled notes, but the note itself. But I'm tired of submitting tickets that never get resolved. If they tell me they are seriously considering fixing it, I can provide a problem note. Then they should be able to solve it within 5 minutes.

Are you sure you didn't accidentally create a new account on your new tablet instead of logging into your existing account?

have you already tried to set an AI search sandbox first by selecting the tag in the left side bar and then search for a specific topic? Do the 8 notes belong to the tag then (if they are shown)?

This would be possible if you could constrain the AI search to a specific tag or notebook, specified in the search string or selected in the side bar before searching.

Thanks, but my question was more directed to Federico. Now that they've found the problem, maybe they can describe more precisely the circumstances under which it went wrong?

I exported your note to PDF with numbering intact. I don't see the problem ? Which pdf viewer do you use? edit: Sorry, I was mislead by the message that all numbers were zero, this is not the case (anymore) but your issue is that the last number is wrong (3 instead of 4). I can reproduce that too. So there is still a problem with numbering...

It was CalS' idea for Directory Opus, he's the expert...

Thanks, glad to hear this 👍 In what situations was it possible to lose data?

I exported all my notes now with the latest EN and I can convert all of them with my own enex to HTML converter without any problem. So the import problem could be caused by the import software. On Github I've seen several crappy enex converters that use regular expressions instead of normal XML parsers to process the enex file. This makes the converter very fragile and sensitive to insignificant differences in the enex file that are otherwise ignored by XML parsers. I also noticed that these implementations are forked into several projects, so more importers can be affected by the same bug.

I have written my own Enex to HTML converter and see no problems with pdf or any other attachment (so far).

Yes, but my question was even simpler than that: will the 8 notes for the AI always be limited to the specified notebook or tags in the query string (or possibly set via the side bar)? That would help a lot to gradually explore and build trust...

Can Document Opus search pdf and word documents and is textual search fast?

Can the AI search be limited to a specific notebook so that sensitive notes are never sent to the AI server?