Already it's very useful! And thanks for your goodwill in sharing!
A killer feature for me in the latest version was the ability to collapse headers in rendered view. That's a feature I never found elsewhere. I went back to the stable version, as code rendering in the blocks was mis-rendering as markdown.
Still daily using your Copy-Span and Collapsible-Blocks, very nice additions to Joplin!
Could you give an example of what was causing this bug? I wasnāt able to reproduce it just now, but it sounds similar to a bug I remember encountering a few months ago, that I forgot to write down and then forgot how to reproduce I may not be the most organized.
I do have plans to make the headers (have the option to) remember whether they were opened/closed, as was requested by someone in another thread. I havenāt started on that yet though, and Iām expecting the solution I have in mind to only work on desktop, not mobile, which I donāt like but itās better than nothing. Iād also like to make the headers collapsible in the editor. Honestly I canāt say Iām super pleased with the current state of the plugin, and Iāve considered just starting it over from scratch - but that seems like a good way to make sure the next release just never happens at all.
I meant in your dev version in the webview the little arrow added to right of headers, giving the ability to collapse header content by clicking on the headersāthat was an excellent aid in navigation long notes in the reading view!
The bug seems to be caused by any header appearing before a code block with content bounded by your fences. Here is a note to demonstrate:
@johano Thanks for the test note Iām on the wrong machine to test this right now but it should be super useful later on. Iām thinking I might release the next version as a bugfixed version of the dev version you tried so something is out, then see if I can get through some major rewrites after that. Maybe I should finish up letting headers collapse in the editor and remember their state, as well.
@executed Thatās not quite what I meant about issues with mobile - I use Android and donāt have an iOS device. But the solution I had in mind for remembering if headings were left open or not, without adding any extra data to notes, was to save an external file that stored that information. I remembered earlier in this pluginās development that the API offers some functionality like that, and I very briefly tested it out, before finding it didnāt work on mobile, at which point I moved on to other things.
But⦠Rereading the API now, I donāt think I noticed the joplin.data.userDataGet options before, and they seem perfectly up to the task - Iāll have to test out if that works on mobile.
I've pushed another dev release, the first in a while. As a reminder, no special care is put toward making these releases stable.
Changelog from previous dev release:
Makes headings collapsible in the editor (they already were in the webview) (this doesnāt yet have its own setting, but can be toggled with the āAllow collapsing blocks within the markdown editor as wellā setting)
Fixes the bug reported by @johano where lines starting with # within code blocks appearing after headers were interpreted as headers in the webview
Fixes a different bug where collapsible sections could be formed within code blocks in the editor
Fixes a different different bug where headers with just text above them would get swallowed by the paragraph rule in the webview
I'm a little hopeful that I might continue with it this time - most of the remaining work is on the collapsible headings. I'd like to connect them up between the editor and webview the same way the regular collapsible blocks are, and add the capability to remember if they were left opened or closed. It probably needs a lot of bug testing too. After this update is complete I do still plan to freeze any future feature releases until Iāve had a chance to majorly refactor basically everything to a state that doesnāt make me sad.
Let me know if you find any issues The note you sent about the last bug was instrumental. I donāt want to promise anything but Iām hoping to keep the momentum up and finish things relatively quickly now that Iāve started again.
It's working very well with the desktop app. Even with complicated long notes, I haven't seen issues. With the improvements over the last stable version, this is workable day to day for me. I will leave it installed unless some unforeseen bug comes to light. I've given it a bit of a stress test and it's held up well!
I used to use a lot the closing }:}: fence, but am finding it redundant now as the in-development plugin does a very job at respecting collpased/expanded state, and remembering that stateāwhether set in the markdown editor or the webview, and keeps it across quitting and reopening Joplin.
This are the settings I'm finding optimal for now:
Settings
ā Color blocks in the editor
ā Color blocks in the webview
Start and end tokens: defaults
ā Remember when collapsible blocks are left opened or closed in the webview
Editor Block indentation level: 15
Number of nested layers: 5 (in practice I've never used more than 3)
ā Enable header-based collapsing
ā Allow collapsing blocks within the markdown editor as well
ā Match editor folding to webview folding on initial note load
ā Keep editor and webview folding in sync
With the Android app (on Pixel 7) in the markdown editor the collapse and expand arrows show, but:
When clicked they raise the keyboard and remain in the same state
If the states are changed in the webview, on returning to the markdown editor the arrows indicating state have not changed to reflect the state in the webview
Simply disabling the Allow collapsing blocks in the markdown editor as well allows continued use without any other issue so far. Being able to collapse the headers in the webview definitely make it worthwhile keeping it installed instead of the last stable version.
Great work!
Joplin Desktop Details
Joplin 3.5.6 (prod, linux)
Device: linux, Intel(R) Core(TM) i3-7020U CPU @ 2.30GHz
Client ID: 615c7880d02145c5a89371d6264bdcb9
Sync Version: 3
Profile Version: 49
Keychain Supported: No
Alternative instance ID: -
Iāve pushed another dev release - as a warning, I would consider this release more feature-complete than the last one, but probably less stable (I mightāve even missed removing some testing code - I tried to get it all though). Things have been progressing and I see no reason to expect a multi-month delay this time around.
This update connects the headings up to three new options in Settings to control whether they appear in the editor, whether they appear in the webview, and whether their open/closed state is remembered. They do not have their own option to sync between the two views, and will instead follow the pre-existing option for that. This is mostly because I wanted to avoid overcrowding the settings page and I figured nobody would want to have one type of collapsible sync but not the other type.
I also removed the option for regular collapsible blocks to sync between the editor and webview only on initial note load. There was honestly no real reason I removed this other than that it seemed super niche and the settings page was kinda crowded - if anyone used and really liked this option just let me know, but Iāve got a feeling probably literally nobody used it.
The main blockers at this point are the mobile issues @johano reported - thanks for how thorough you were. Iāve spent a lot of time investigating those issues and havenāt fully figured out or solved them but I have made some bits of progress.
I also havenāt done the promised recoloring yet for when colors are enabled.
Once I fix the mobile issues I intend to move on to polish and bug-seeking for a bit then release. I am aware thereās a little bit of jank in some situations when closing headings in the editor, and for whatever reason the setting to remember heading states doesnāt 100% update when changed, until Joplin is restarted.
@ntczkjfg, using your latest dev version for the last several days, on both a phone and Linux desktop. All options are enabled on the desktop, but with the collapsible feature in the markdown editor disabled on Android.
In the mean time Iāve actually (mostly) fixed the Android issues, but doing so required a surprising amount of changes so now Iām working on fixing some regressions. But I think things are trending in the right direction for sure.
I'm finding your plugin extremely useful day to day.
It was a pleasant surprised to see in the markdown editor, that markdown headers also could be collapsed and expanded within your fenced blocks (I don't think that was in the previous dev version, if I'm remembering correctly)āthat their state is not remembered is of little consequence, it is of good help when editing rambling notes with long collapsible blocks embedded.
The state of the fenced blocks created by your plugin are remembered well and that seems pretty solid.
Thatās actually not something I coded in on purpose, nor is it something that occurred to me - and on testing it out, doing so actually seems to break the containing block in the webview
That said I like the feature too so Iāll aim to polish it up for sure - including making sure the collapsible heading does not extend beyond the bounds of the collapsible block itās contained within. I could see a lot of edge cases here, hopefully they wonāt take too long
Itās getting close now. This fixes a lot of inconsistencies and off-by-one errors that existed previously, and fixes the issues with headings inside of collapsible blocks. It also changes the color scheme for nested blocks.
I am aware that on mobile, headings currently donāt work in the webview at all unless you first open then back out of the editor. I am also aware that a couple of the settings donāt function properly - like if you have the option to remember the state of blocks enabled, but the option to keep the webview and editor in sync disabled, then it wonāt remember the state of blocks. Any issues beyond those, I am very eager to hear about.
I donāt have colors enabled myself, so Iām open to feedback on the new default color scheme. Iām also somewhat considering removing the option to not keep the editor and webview in sync with each other⦠Kinda feels like I made a web of options that keeps getting tangled.
Iāve learned my lesson about giving any sort of ETA - I know whatās causing the mobile issue but fixing it in an adequate way may prove challenging. And then just trying out every combination of settings to make sure everything works how it should will take a while. And the readme will need a huge revision. Then thereās my extremely inconsistent cadence on working on this. But this is definitely feeling close to me.
Looking forward to installing this today. Thanks for your continuing work on it!
For me at any rate keeping the two views in sync is not a key feature. And if it untangles your code and makes it easier to maintain and work on, it does seem a good way to go?
Welcome Itās actually the opposite I was considering - keeping them in sync by default with no option to not keep them in sync. Itās an option that only mostly just matters on desktop in split view. But a good portion of the code I consider jankiest is there to support that feature in particular, so removing it would probably be easier - but something about opening or closing a section in one view and having the other view mirror it just feels really good to me.
Iāll figure that out when I start trying to untangle the settings web though - itās mostly an issue because I focused on getting things to work without connecting them to the settings until now. Maybe it wonāt be so bad?
The mobile issue, on the other hand, I still donāt even have a plan of attack for yet
Ah! I missed that crucial word not! I don't use split view here, but keyboard shortcut back and forward between markdown and rendered view. I can see how the mirroring would be a nice thing for users of split view, probably not critical since they can still collapse either view easily. I'm not sure why anyone would set the sync preference to 'don't sync' (unless to resolve an issue)?
A final thought, headers inside blocks are not essential, as nested collapsible blocks serve organisation within blocks very well? Headers outside are already collapsible with your plugināso it might not be a great loss if it was specified for the plugin not to use headers within the blocks, possibly might simplify the complexities you encounter?
The previous dev version I've been using day to day, and it works pretty well and is extremely useful. I'll see how I get on with this latest.
All good stuff, thanks for all your work!
(Oh, the change in colours of nested blocks is for the better and seems a good choice)
Headers inside of blocks are actually already fully fixed in this update so far as I know Though that particular fix is what led to the current mobile issue. I do really like that capability, in any case - it lets each block kind of act like itās own little note in some sense. Itās definitely here to stay.
I might have a fix in mind for mobile at this point. Iāll test it out at some point in the coming days, unless I think of a better way in the mean time.
This one fixes all of the known mobile issues - all thatās really left on the todo list is sorting out the issues with settings, and redoing the readme. I would have skipped this dev release and waited until those things were done for the full release - but itās been so long since desktop and mobile both worked all the way at the same time, I didnāt want to risk the remaining changes breaking one of them again. Enjoy!