Removing / overriding inherited attributes

[b3taman]

Not quite sure where to place this, but here goes. There might also be a bug — at least there is unexpected behaviour and confusion — and a feature request.

By default I have all nodes sorted by applying #sorted to the root node and making in an inherited attribute. This is all well and good but there are corner cases where the automated sort results in a semantic mess and I need to have manual sorting.

The problem comes in when I try to remove the #sorted label from a sub-tree. I used the "Search in subtree" method with an action to remove the sorted label (no #: if I include it nothing works) and it sort of succeeds but not really, as though I can move nodes around the results change.

It appends an asterisk to those nodes which I have moved around. They are only appended to the names in the tree view, not the main view:

If I collapse the tree view and then open it up again, my ordering has disappeared and all the nodes now have asterisks:

But closing and reopening Trilium restores the manual sorting and removes the asterisks:

Adding a new node sorts it again (no asterisks) and this sorting survives closing and reopening Trilium:

If at this point I try to drag a node around I cannot. Instead I need to execute the search again and then the whole dance repeats itself.

Regardless of the (in)action of the search, at all times the inherited attributes list contained #sorted, so I'm not sure what is going on. I dare say that being able to amend the inherited attribute would sort [!] this out.

My intuition tells me it would be helpful if something like the following could be implemented regarding inherited attributes:

• #sorted: Apply sorting here and below.
• -sorted : Disable sorting only for this level.
• !sorted: Do not applying sorting from here and below.

The "only for this level" would refer to the direct children of "this level". In my above example, setting it for Miscellaneous would mean that I could set and retain the DAG ordering and be able to insert E to result in DEAG, but everything below that would again be sorted. For example, if I created a level below A and entered (in this order) bgac the result would be abcg.

[zadam]

Hi,

The problem comes in when I try to remove the #sorted label from a sub-tree. I used the "Search in subtree" method with an action to remove the sorted label (no #: if I include it nothing works) and it sort of succeeds but not really, as though I can move nodes around the results change.

Could you explain this a bit more? You have inheritable #sorted at the root, you can't really remove it with "Search in subtree". There's currently no way to override or disable inherited attribute.

[zadam]

So I looked a bit more on two issues:

• appearing/disappearing asterisk - this indicates that note has clones (notes with multiple parents), but this was also counting search results as clones. This is probably confusing so I added filtering so only real clones will get an asterisk.
• it's possible to drag & drop notes but this gets resetted - the bug here is that it shouldn't be possilbe to drag & drop such notes at all since they should still be kept sorted.

[b3taman]

Thanks for the explanation and changes; I'll try to explain the requirement as well as share some ideas I had for how it might work out.

Requirement

Ordering is obviously important for most lists, especially when humans are involved, as we don't do hash functions in our heads too well. Some kind of lexicographical ordering is usually sufficient, but sometimes it won't work, as is the case here.

I am happy to apply #sorted almost everywhere, so inheritance is obviously the way to go. There are times that I need to override it though, as with object definitions in programming. A simple example: node names starting with Roman numerals. In such a case I need to be able to override the inheritance of the #sorted attribute to enable me to order the nodes by hand.

Currently the only alternative is to apply #sorted by hand almost everywhere just so that its absence in about 0.01% of the cases will have the desired effect.

The rest of this post is a first stab at how to improve this.

Ideas

I don't know how the node lists (tree levels) are implemented but am guessing that each is some form of linked list. Perhaps the easiest would be to sort each level by calling a function which is pointed to by the parent node. If it is null, then the initial order is as inserted, allowing nodes to be moved around at will.

In such a scheme those in the know can create really complex sorts as SQL statements (or whatever) while others could (like now) choose the ordering via the Search in subtree approach, but with the addition of Unsorted as described.

The above is specific for sorting. A more general approach is overriding inherited values and then something like this idea might work (it is expanded from the example in my previous post). The general principle is that local definitions override general values. The flexibility comes in with how that is done.

• #attrib=v1: Set attrib to value v1 and propagate it unless one of the following is encountered.
• -attrib=v2: Set attrib to v2only for this node.
• !attrib: Disable attrib from here and below.
• +attrib=v2: Set attrib to v2 for this node and its immediate children.

Let's look at a structure of Grandparent -> Child -> Grandchild -> Great Grandchild -> Great-great Grandchild (called A -> B -> C -> D -> E for brevity).

The #attrib=v1 case: straight inheritance

This is the simplest. Because inheritable attrib has no local override, B simply passes its value on when creating C, which does the same when creating D, etc.

The -attrib=v2 case: local override only

When B is created, it gets value v1 for attrib, as well as an indication that it is an inheritable attribute. Some time later attrib is overridden at B and set to v2 with modifier -. This makes the new value applicable only to the node B. Thus when C is created, B sets attrib to the original value it got when it was created and passes it on to C as an inheritable attribute. Thus as far as C is concerned, attrib has value v1 and because it is an inheritable attribute, it gets passed along to D at its creation in the same way, etc.

The !attrib case: kill the attribute

When B is created, it gets value v1 for attrib, as well as an indication that it is an inheritable attribute. Some time later attrib is deleted at B. I'd say that's where it gets left. As it is no longer in B's "genes", it can't pass it on and its children won't know about it. Should a child later get moved to another part of the larger tree structure, then it would inhered what is applicable at that point (and this is where the genetic approach breaks down). Using !attrib is simply a notation to indicate what happened and is as such useful for undoing changes. If attrib is required at B but no further, then simply create it as a non-inheritable after deleting it (simpler: change its type to non-inheritable).

The +attrib=v2 case: me and mine

In our example, attrib would have value v2 at B and all its children as well (C1, C2, C3, etc.), but not below that. Thus when C and siblings get created, each is told attrib=v2, with modifier - as well as what the original value is. Then D is simply told attrib is inheritable, has value v1, and it propagates in the usual way.

[zadam]

Hi, there's actually an existing way how to achieve that. When some algorithm expects only one attribute of a given name, then in case there's more than 1 (e.g. through inheritance) then the "closest one" will be used. In practice this allows local overriding.

I just implemented #sorted=off - if you use that on a subtree then this will become "closest label" and will be thus in effect, thus disabling the sorting (for the given note, if you set it as inheritable then for the whole subtree).

[b3taman]

Perfect! Thank you so much!

Using Trilium is already impacting how I work — in a very positive way. Though this relates to academia, I echo the sentiment in this context:

An idea kept private is as good as one you never had.
— Sönke Ahrens

Quoted in How To Take Smart Notes: 10 Principles to Revolutionize Your Note-Taking and Writing, which I am working through to see how I can both improve and use Trilium in the process.

[b3taman]

[Just discovered one cannot mark part of a thread in a discussion as being the answer, so am trying this approach.]

Hi, there's actually an existing way how to achieve that. When some algorithm expects only one attribute of a given name, then in case there's more than 1 (e.g. through inheritance) then the "closest one" will be used. In practice this allows local overriding.

I just implemented #sorted=off - if you use that on a subtree then this will become "closest label" and will be thus in effect, thus disabling the sorting (for the given note, if you set it as inheritable then for the whole subtree).