[WIDGET] Outline/ToC widget

[antoniotejada]

I updated #533 (comment) with a simple ToC Widget I wrote, @sigaloid suggested I post it here too:

• The ToC is live and automatically updated as new headers are added to the note.
• Clicking on the ToC navigates the note.

https://github.com/antoniotejada/Trilium-TocWidget

[antoniotejada]

@antoniotejada I think it's great, although I may be a bit biased ;)

[antoniotejada]

I updated to a revision with a few comments about headings nested inside elements (ie inside tables) and malformed html. The short story is that the widget doesn't try to make those right (there may not be such a thing as "right" anyway), the TOC will probably be wrong and the navigation broken, but it shouldn't crash.

I added a .js extension to this revision to get syntax highlighting but unfortunately github thinks it's a new file and it shows as one deleted file and one added file instead of the diffs:

antoniotejada/Trilium-TocWidget@1a82dee

[kaaass]

Love this widget! This is really useful. 😃

Better if it could support scrolling in read-only mode (of which content will be under .note-detail-readonly-text-content)

[antoniotejada]

@kaaass The latest revision works with readonly, auto, and always editable, and when toggled between them with and without reloading the note.

antoniotejada/Trilium-TocWidget@59daa68

Need to check if I can use a single path accessing the DOM directly for both cases, or if CKEditor will complain when scrolled behind its back. Accessing the DOM directly feels brittle, though, and it could break across Trilium versions?

[kaaass]

Awesome! I checked the new version and it looks nice to me!

I guess in read-only mode there's no editor.

Yes, Trilium achived this with a complete different widget by introducing CKEditor's CSS and same note content. It loads CKEditor just for loading same CSS styles.

Accessing the DOM directly feels brittle, though, and it could break across Trilium versions?

I agree. It will be better if Trilium provides API for getting active ReadOnlyTextTypeWidget. However, ReadOnlyTextTypeWidget is just a render-related implementation detail, so providing such a API might not be a good idea. I guess we could only pray for .note-detail-readonly-text-content still being used in the future version lol

[zadam]

Just confirming that CKEditor is not being loaded for read only content. Its main purpose is load time optimization for long notes since CKEditor can get very slow with a lot of content.

[kaaass]

Thanks for correcting that! I thought it was loaded for read only content because this part of code. Seems I misunderstood that.

[antoniotejada]

I don't think you misunderstood, the CKEditor is loaded so it brings up the CSS, but it's not used to render. I haven't seen the performance metrics behind the decision for not using CKEditor to render readonly notes, so I can't tell if that detail makes any difference nowadays or not.

In addition, that also brings up a conflicting point of the currently adopted resolution for #533 (ie waiting for CKEditor to implement TOCs): if readonly notes don't get rendered via CKEditor, then CKEditor can't be tasked to render the TOC either, since it wouldn't work for readonly notes.

Personally, I think offloading the TOC to CKEditor is the wrong thing to do, since you "probably" (hard to tell until CKEditor TOC implementation lands) wouldn't be able to do things like docking' the outline under the tree, which is pretty convenient. Also, the Trilium implementation is barely four lines of code, as the widget shows.

[antoniotejada]

Small aesthetical update to embolden the TOC entry on hover

antoniotejada/Trilium-TocWidget@9a6845a

[antoniotejada]

I think I agree on the TOC resizing being annoying, I may set a fixed size and have it always there even if it's empty, but I really like it under the tree without taking horizontal space from the note editor (I don't think that currently there's support for a second left column anyway) or having to press any buttons, I don't need to see the whole tree.

[MingLin-home]

@antoniotejada What about adding some configuration variables in the top lines of JS script? I do not know how to write JS but modifying configuration variables should be easy enough for me.

I have a wide screen so it is better if the TOC is floating or on the right side. I made a simple fix myself, in case someone reading this thread needs it: in get_parentWidget() function, return 'right-panel' instead of 'left-panel'

[antoniotejada]

I don't think I'm interested in adding configurations, although if I were I would probably use the note labels (eg #tocLocation=left).

Wide screens are even worse for rightmost column, more eye and mouse travelling.

[MingLin-home]

Agree with the more eye movement on the right side. What about TOCwidget on the left side but right to the main tree widget? I not sure whether this is easy to achieve in Trilium. Maybe it is time for me to learn JS :)

[Lolabird]

@zadam you probably don't need this, but I created a fork and placed it on the right side here.

[antoniotejada]

There are two bugs with splits I need to fix:

• Navigating the TOC when both splits have TOC, navigates both splits (one of them with the wrong navigation).
• TOC doesn't always go away when TOC changes from a split where TOC is enabled (text note) to a split where TOC is disabled (eg code note). This also affects the tree failing to switch to the code note branch, so it's probably not a TOC bug. To reproduce this one:
  1. open a text note on one split
  2. open a code note on the other split
  3. click on a blank line of the code note, this should hide the TOC and focus the code note branch of the tree
  4. click on a line of the text note, this should show the TOC and focus the text note branch of the tree.
  5. click on a brace/parenthesis or on a word of the text note, this causes a highlight of the other opening/closing brace/parenthesis/whole word but causes the tree not to focus on the code note branch and isEnabled not to be called, so it doesn't hide the TOC (this reproes around 90% of the time, could be an async/timing issue).
     When the bug happens you also get in the javascript console
     [Violation] 'setTimeout' handler took 64ms
     [Violation] Forced reflow while executing JavaScript took 34ms

Splits are probably another minor reason to put the TOC under the tree, since (when the second bug doesn't happen) they both change when you change to a different split and makes it clear that the outline is for the active split not for the rightmost split.

[antoniotejada]

Opened #2804 for the second bug.

[antoniotejada]

The other split bug is related to something I've found with the FindWidget, which is that there can be multiple html nodes that match the eg "note-detail-readonly-text-content" jquery (hidden in this tab, hidden in other tabs, visible on another split, etc).

What's even worse,

• getActiveTabNote() returns a single note when in split mode
• but getActiveTabTextEditor() calls the callback once per split when in split mode

Looks like the split architecture is not fully thought out, eg the tab label doesn't change when you focus from one split to the other.

One idea I implemented for the FindWidget is to get to the component HTML node and filter by noteId, but this doesn't work when both splits are showing the same note. Probably won't work either when a hidden tab is showing the same note, but for that case visibility can be checked.

All in all, what is really needed is a way of getting to the active HTML element of the active note.

[antoniotejada]

Updated

• split bugfixes
• changed showDebug to use the script's #debug label

antoniotejada/Trilium-TocWidget@737c030

[antoniotejada]

Deleted gist, moved to https://github.com/antoniotejada/Trilium-TocWidget and added scroll to the table of contents.

antoniotejada/Trilium-TocWidget@6ab61f3

[MingLin-home]

This widget is really awesome! I have been struggling with ToC for a very long time!

[ysslang]

Hey, this widget is fantastic.
I try to modify this widget with this PR. So the widget will be able to adjust its height and be collapsable.
I did find a way to adjust the height with the embed Split function, but I didn't find an official API to inject a button into the floating tree actions bar. Do you have any idea?

[FluffMe]

Hi @antoniotejada

Thanks a lot for your work on this and other widgets! Big fan.

One question on the current implementation:

• Is it (or will it be) possible to hide ToC for a particular note by adding an attribute to a note, for example.
• Same question but in reverse. Is it possible to make it off by default, but enable it by adding an attribute to the note.

The thing is my personal workflow consists on many small notes that don't require ToC, so it's a wasted space on screen. However, some huge notes require ToC. If this particular workflow would be supported without tinkering manually with the divs and hiding them in my personal CSS, that would be amazing.

Thank you very much!

EDIT: I guess making it collapsible would also solve it for me.

[Omega-Void]

+1 for collapsible like the main sidebar

[antoniotejada]

@FluffMe there's actually an attribute you can set to disable toc, noTocWidget see https://github.com/antoniotejada/Trilium-TocWidget#configuration-attributes
You will also need to set the tocWidgetHeightPct to zero (dynamic).

You can set attributes in a note template so you don't need to set them on each note.

There's a nice pull request by @ysslang to allow collapsible TOC antoniotejada/Trilium-TocWidget#3 I haven't gotten around to it yet.

[FluffMe]

@antoniotejada it seems that in the current release version with the inbuilt widget #noTocWidget has no effect.
Quick source code search doesn't result in any matches either. :(

Maybe, it's unimplemented?

[antoniotejada]

@FluffMe

Hmmm it's there,

https://github.com/antoniotejada/Trilium-TocWidget/blob/2a5f36ddffe9f843955c2a3ddd1944eee0be153b/TocWidget.js#L197

I just tried and it works, you don't even need to set tocWidgetHeightPct. As soon as you set #noTocWidget in "owned attributes" and press enter, the TOC disappears.

[FluffMe]

Oh, my bad.

I meant in the implementation of your widget in the actual trilium that comes prepackaged with it now.

Which I suppose is this.

https://github.com/zadam/trilium/blob/master/src/public/app/widgets/toc.js

Can't make it work and it doesn't seem to include it in the source code.

If i am correct, shall I suggest improvements to zadam via issues instead of pinging you all the time?