Make tabs keep the scroll on the tree left panel

[voidplayer]

v 0.42.7

use case

I have several unrelated sets of notes. It wouldnt belong on the same book honestly, but i noticed trilium encourages you to use the same root for all with tabs. And thats what i did

I keep a tab open for different sets of notes. But when you change note the tree scrolls to make the current selected note visible. This usually makes the note at the top/bottom which make it lose the position you want the tree to be on

proposed solutions

• save the scroll and collapse state of the tree node: optimal solution
• make the selected note auto scroll to the middle or at least with some margin, instead to top/bottom: i guess this fix the problem in a way and its probably easier to implement?

Thanks for considering!

[zadam]

Hi, the first option (save the scroll and collapsed state) is not done intentionally for performance reasons. Trees can be huge and performance would suffer.

I added a "scrolling margin" in stable branch as you suggested, hopefully it will mitigate your problems.

[voidplayer]

Thanks! ill report feedback the next release!!

While i understand the performance issues. I have 4 tabs and I rarely change tabs. When im working on one tab thats it. And then i switch task, i use a different tab. So it would be a one time thing. Not everybody will use tabs like i do, but saving this data could be optional and disabled by default

A third option could be to just remember the scroll position without the collapse state. This shouldnt be too much performance heavy (and i think it would work for me)

A fourth option could be an option to automatically collapse everything but the current tree leading to the current note. Many trees in many programs work like this and is a neat way to have everything automatically organized. Changing tabs would always collapse and uncollapse exactly 1 tree :)

Just throwing ideas out there, not sure how feasible are they :)

I would save different books instead of using tabs, but trilium doesnt seem that likes that approach :(

[nbreitkopf]

Zadam, have you considered adding an option to make note hoisting tab specific? It doesn't fully solve the problem of remembering the scroll state, but if each tab can have its own hoist note, you essentially get isolated environments within the same document, which nicely fits the workflow described above. A performance penalty would only occur when switching tabs, as it would automatically trigger a rehoist.

[zadam]

@nbreitkopf yes, I considered that since I would like this feature as well but I still don't like the performance hit. 

You say "A performance penalty would only occur when switching tabs" and that's true, but that might be significant when working with large number of notes (tens of thousands etc.). Especially when you switch tabs with keyboard shortcuts you expect immediate reaction.

I would rather move in a direction where each tab has a separate instance of note tree widget - then at least tab switching remains fast, but at the cost of increased memory usage. Actually most widgets are per-tab, note tree widget is one of the few shared ones (for the memory usage reasons).

[voidplayer]

All these ideas are great

They could be disabled by default with an option for those of us that dont have yet 10k notes :D

[zadam]

Making options such as this essentially means implementing same thing in two different ways, you then have to always test twice etc. Having things configurable is very expensive in terms of effort and future maintenance, so I'm trying to avoid that wherever possible.