First, I must admit that I love one thing with this new behavior. In “add note” window, there is far less data lost when you change the note type, since as long as there are more fields in the new note type than filled field in the current note, no content is lost. That’s great.
However, with the new behavior, I discovered the following issue. My second and third field is collapsed. However, the field content was moved to the second, and then third, field. Which mean that I’ve now created a hundred of note where all second fields are identical. And I had nothing ensuring that I discover it since the fields were collapsed, hence I assumed they were still empty.
Maybe just a symbol indicating that a collapsing field is not empty would be nice.
The second problem is simply that, if you change from note type A to B and then B to A, you don’t get a no op. Even if there is exactly the same number of fields and no field name in common. Admittedly, that was never guaranteed before, and this would break in a lot of case (in particular when two fields with the same names are at different ord in the old and new note type). But still, after years, I relayed on this behavior and that’s going to be strange to have to do without.
Obviously, as long as changing note is done in python, I’ll simply be able to change it in add-on, so that’s not as much a problem for me as most other “note editor” problem I relayed previously
This was a simplification of two use cases I really have.
Obviously, voluntarily changing from note type N1 to N2 then to N1 again makes no sens.
However it occurs that I misclick. That I want to change to N3 and click on N2 by accident. With N1 and N3 being similar, having a lot of name in common, lot of fields in the same relative order. In which case, in the previous case, all fields value are almost at the right place, which makes it easier to cut-paste them to the right position. Now, I’ve got to browse through all fields to find back where I wanted to put them originally.
More realistically, it also occurs often that I switch a lot between note type. E.g. I’ve got a note type for “type” and one for “methods”, that I use when I want to learn the most important part of a new language or stack. So I move from “type” to “method”, add a note, and move back to “type” some time later.
Some fields never or rarely change, such as the programming language field, the source URL, and so on. So I was used to the fact that switching back and forth was a no op for all fields that I didn’t touch.
Actually, it is still mostly a no-op since the “url” field has the same name in both note type. The trouble is that, if a field (let’s say “return value”) is present in “method” and not in “type”, it’s content may move to the field “url”. If I don’t notice it, it mean that it’ll stay in “url” until I catch that there is an issue
In short: I wanted to make the feedback about beta that, as a long time user, I found it disturbing at first. But I perfectly understand that finding the best rule is impossible. And anyway, this part is still in python so I’ll just patch it myself when I’ve the time to do it
Appreciate the feedback, and I can see how this would be problematic in that case. I’m not sure how this could be easily addressed though, short of having some option to skip the name-based mapping of fields when switching.
