Synchronous scrolling of the editing area and preview area

#1

If the editing area and preview area do not have a fixed height, you will often encounter the following situation, which is unacceptable

image
image1743×1103 193 KB

If the height is fixed, how to automatically scroll to the corresponding area simultaneously becomes a problem, otherwise the user will have to scroll back and forth every time. This is very tedious.

image
image2220×1385 303 KB

Is this possible for further optimization in tiddlywiki? Although tiddler advocates brevity, more often than not, we will get long text.

PS: The editing experience in tiddlywiki doesn’t seem to have received a lot of attention. I’ve been trying to optimize it recently, but it’s still missing some of the effects I expected.

1 Like
#2

I’ve mentioned this before. I guess the presumption is that your tiddler will be small enough that this never becomes a problem. That would fit with the Philosophy of Tiddlers.

Even having a preview that automatically refreshes to show the top, or bottom, would allow you to work at the top (or bottom) and see the results.

One work-around for longer documents is to use Mohammad’s sections editor.

It’s interesting that the editor here on Discourse auto-synchs to show you where you’re working. So that gives an example of how TW could work.

#3

See also Most wanted Features 2023

#4

In fact, this function is relatively difficult to implement, especially for tiddlywiki. Because it needs to analyze the height of the corresponding area, I have not written a similar function, but here is an example for reference.

GitHub - imzbf/md-editor-rt: Markdown editor for react, developed in jsx and typescript, dark theme、beautify content by prettier、render articles directly、paste or clip the picture and upload it...

#5

Just to be clear, it isn’t that there is a presumption that a synchronised preview isn’t required, it is just that we have not so far managed to find an implementation that is viable.

@oeyoews mentions another project that does something similar, but I am not able to see enough details to determine how they address this problem. I note that it is a Markdown editor, which I think would mean that they wouldn’t run into many of the issues that would make it difficult in a TiddlyWiki context.

1 Like
#6

When I have time, I will take a closer look at the implementation details. I hope to have the opportunity to implement this function in tiddlywiki.

I only discovered this feature when I saw this commit today.

1 Like
#7

I do believe there is a valid approach to a semi-synchronous scrolling between edit and a custom preview.

@oeyoews I did feel a compromise was posible through a Custom preview that displayed a line number when one was available in a “left hand column of the preview”.

This may be hard to express, but I think this may be possible with codemirror line numbers.

  • Of course one line of code can result in many lines rendered, so many lines will not have a line number matching the code
  • Often also a number of lines in the code result in a single rendered element eg a list widget code using 10 lines displays one list rendered. S we may only see the first line number in the code in the preview. Eg the line number where a widget is opened eg <$list
  • I think it would be ok if not all line numbers are represented in the preview, only those that can be identified. As we change the active line number, in the editor, it will jump to the relevant position when that position is available.
    • However I expect blank lines and those contain comments will always be able to obtain a line number in the preview.

But you could see how the line number in the editor could be used to track where the editing is taking place and when it is possible to manifest a line number in the preview, make the preview scroll to that position, in jumps.

I believe the above can be made to work, and be of practical use, but it may need a new way to parse a tiddler, so I am unsure how complex it would be to implement.

  • One way I Imagin it is what if every blank line was itself considered wiki text requiring a line number to be displayed.