eric99

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?

Hmm, not sure about that... have you tested this recently? edit: I just tested this on my Windows client: I exported a note to Enex and re-imported it, the update and creation time did not change, the imported note is an exact clone, except for the unique note-id of course

Don't blame the OS vendors, the real culprit is the Linux community itself: there are over 600 active Linux distributions and counting 😵. To the outside world there doesn't seem to be such a thing as one 'Linux OS'

Have you tested with natural language queries to see which query it is translated into by the AI? Typos and the use of synonyms are also an interesting test.

If it doesn't have all access to the data, is it more processing the query string then (natural language, synonyms etc) ?

I think it will be backwards compatible since it's ENEX XML format. New XML tags for tasks or other new stuff will be ignored by the legacy enex readers. I already tested that by adding a note-id and notebook name. Legacy importers still work fine, they just ignore these two new attributes...

And to make a consistent and complete backup of it, please add the note id and notebook to the ENEX file.

So you mean the note export functionality 😏 You can make as many and as frequently as you like...

Fully agree, so not the misleading optimistic message in the bottom right corner that everything has been synced when it's not... (in desktop clients)

Which is of course the favorite excuse for developers who don't know about concurrent programming techniques to handle race conditions properly 😏

I don't think it's the nbsp char, I inserted it in a title and the title still exports properly. I then searched the content of the whole local database for a note which I know is converted to 'Untitled' by enex, checked the title with notepad++ hex viewer but can't find anything special. It's a challenge to reverse engineer the database structure from a bunch of files, maybe I missed it

Perhaps the odd character is nbsp, which sometimes appears in enex files, making life harder for xml parsers and maybe for the enex generator as well when inside a title? I don't think it is valid enex character according the dtd file. I look further...