You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a recent feature of changing the position of a new note using the label newNotesOnTop.
Please implement this feature as a boolean label, not based on the label's presence as it is currently.
This would allow the user to make certain subtrees behave differently by making the label inheritable and specifying a different value.
My use case
I personally like having new notes appear at the top in almost all circumstances, which means I use the current implementation's label on the root with inheritable set. The only exception to this are task notes, where I use new notes as updates and those make more sense appearing at the bottom, as chronological order typically goes from the top down.
Additional Information
Alternative approach to this would be to create a feature where a note can define an "anti-label" which explicitly states that the note should appear as if it didn't have the label defined. This, together with inheritable, would make my use case possible as well. The solution would also allow any label feature dealing with the label presence, not just newNotesOnTop, to be more flexible by allowing to make subtree "holes" in the effect area of a label.
The text was updated successfully, but these errors were encountered:
You can now define #newNotesOnTop=false to negate a #newNotesOnTop set at a higher level. IIRC this pattern has been used in some other cases as well previously.
Describe feature
There is a recent feature of changing the position of a new note using the label
newNotesOnTop
.Please implement this feature as a boolean label, not based on the label's presence as it is currently.
This would allow the user to make certain subtrees behave differently by making the label inheritable and specifying a different value.
My use case
I personally like having new notes appear at the top in almost all circumstances, which means I use the current implementation's label on the root with
inheritable
set. The only exception to this are task notes, where I use new notes as updates and those make more sense appearing at the bottom, as chronological order typically goes from the top down.Additional Information
Alternative approach to this would be to create a feature where a note can define an "anti-label" which explicitly states that the note should appear as if it didn't have the label defined. This, together with
inheritable
, would make my use case possible as well. The solution would also allow any label feature dealing with the label presence, not just newNotesOnTop, to be more flexible by allowing to make subtree "holes" in the effect area of a label.The text was updated successfully, but these errors were encountered: