Vos commentaires
This adds semantic meaning to headings rather than just style. Interesting.
Confirm fixed in 2.0.2 beta 1.
Related thread: http://cintanotes.com/forum/viewtopic.php?f=6&t=1492
Wikipedia lists 14 lightweight markup languages. Wow..
Thanks for Ctrl+D. And good point. But Alt+Del and Shift+Del are still available (I'd vote for the latter), how do you feel about these?
Good idea to add small colored boxes on sidebar! Got used to it in GMail, and it's not so distracting as coloring the whole tag. By the way, GMail allows setting both background and foreground colors, we could use that.
How about also providing a set of pre-defined eye-friendly colors (or color pairs)?
By the way, in the progress of previous research I've noticed inconsistent date formats in NotesCache table:
Look at records 13-15. There are also some records in dd.MM.yyyy lower in the table. I have one guess - I carry portable CN on my USB drive and have edited it at least on 3 various machines. One has yyyy.MM.dd, another M/d/yyyy tt, and the third one has dd.MM.yyyy.
I've found a way to reproduce it. Seems only 1.5.3 is capable of "producing" .dbs that crash 1.5.5+.
1. Make clean (no .db) portable CN 1.5.3 dir.
2. Start CN
3. Add first note. For example, title="1", no body
4. Add second note. Title="2", no body
5. Delete first note, close CN
6. Try importing produced .db in 1.5.5 and 1.5.6p2-p3.
Result: 1.5.5 fails without crash:
1.5.6p2 and 1.5.6p3 crash with "cintanotes.exe has stopped working" described earlier.
First it felt that the trouble was in NotesData_segdir and NotesData_segments tables, because they were different in failing (from 1.5.3) and not failing (1.5.5) .dbs. But when I minimized the input that causes a crash, these tables looked identically produced by 1.5.3 and 1.5.5, but importing the second one in 1.5.5+ doesn't crash it. The only difference I could find was user_version 151 for first one and 1550 for second one.
1.5.6 prerelease 3 - confirm, it's cool now =)
Service d'assistance aux clients par UserEcho
Thomas, Alex, I think I can rephrase this feature request now.
The idea is to replace this "Internal format" with some human-readable light markup, while keeping the rich WYSIWYG editor on top of it. In the "Formatted" mode, the editor translates formatting commands into markup on the fly and renders it. For markup users, it renders markup elements on the fly as they complete. This takes best from both worlds. People who want just rich text will have it, and never have to look at markup/plaintext. They can always stay in "Formatted" mode. Hopefully they will get some toolbar and keyboard shortcuts. People who prefer monospace plaintext with minimal markup (like me) could use "Plain" mode.
I argue for human-readable markup as a base because I see it much more reliable storage format than RTF-like formats, or anything based on XML.
There's a good related historical case described in a blog post about Confluence merge of Rich Text and Wiki markup editors (scroll down to "Original Post"). Note: I don't think another XML-based underlying format is a good idea unless you want to go for tables and embedded media, which was their goal. But I like the way of thinking to consider both technical and non-technical users.
Alex, I could demo this hybrid editor in Confluence instance of our project in a screen-sharing session, if you feel interested.