We should try to synchronize text input scrolling with the rendered preview area

[pmario]

We should try to synchronize the text input scrolling with the rendered preview area

In: https://groups.google.com/g/tiddlywiki/c/FW574e2rUGA/m/pcDHSODRBQAJ TT wrote

2 - But, I do sometimes wonder about whether we could use the live Preview Pane in the Editor better.
Like get it to co-scroll with the edits?
Since preview is live in TW I do wonder if we could do better harmonizing its showing with the typing, broheem?

My response:

Yea, That would be a nice feature. ... The main problem is that the rendered output doesn't have any knowledge about the wikitext that created it. eg: A {{transclusion}} doesn't produce a wrapper around the transcluded content, because it would add a lot of redundant elements to the TW UI and slow it down.

A list widget wikitext may only be 4 or 5 lines, but it's output may be 50 lines. .. We would need to add additional line info to the "parsetree" which would need to produce some meta data in the preview, where we can scroll to.

As I was writing this, I did have a very hacky idea. .. But I need to think about it. .. I'll create an issue at github.

The idea was temporarily create a heading H1. Which will be scrolled to the top of the preview erea. ...

The underlying mechanism that I thought of, would be a "line parser" that is active in the text editor.

• If the user activates a hotkey eg: CTRL SHIFT 1 it will create a H1 element in wikitext, but with some detectable info in the rendered output. The "scrollable widget" and the "tm-scroll" event should be able to scroll the new element near to the top of the preview.

At least that was the idea.

[CodaCodr]

There might be something in the CodeMirror API that allows you to use a specific CM line number to map to a visibility:hidden "token" in the rendered output.

[pmario]

I was thinking about CodeMirror too, but I also want it to work with the default editor, because it is part of empty.html.
I know, the idea is a bit hacky but I think everything that makes an improvement is valid atm.

[CodaCodr]

Yes, I understood that. I was just wondering how to avoid the inevitable jerkiness that might result with the H1 injection(s).

I did stumble across this, but not sure it helps much: https://stackoverflow.com/questions/19611688/determine-if-codemirror-is-scrolled-to-bottom
And this (see the quoted text in the OP): https://stackoverflow.com/questions/31024191/ace-scroll-sync-with-preview-get-line-height-of-wrapped-lines

Aside: As you use Discourse more which also tries to keep the editor and preview scrolled in-sync, you'll notice it's far from perfect -- large fonts, in-lined link-previews and large images throw it out of sync quite easily. Due to these issues, after using Discourse's editor for a number of years, I wish I could turn it off -- it's just annoying. :/

[AnthonyMuscio]

Mario,

One idea for previewing output that may be longer that the wikitext source may be to add to the preview, the source line numbers ahead of rendering. Now if for example in the you clicked inside the content generated the list result (below), the source window would jump to line 5 in the source. Basically tie the output back to the source line, even when additional rows are generated. Clicking on the line number in the preview would keep the interface simple. The scrolling would be to the top of the result in the preview source line number in the editor. Not ideal but 90% of the required functionality. Any line in the preview without a line number is a "synthetic line" generated from the rendering.

The preview may look something like this.

1 text
2 
3
4
5 * item1  (the line where the list was opened) 
   * item 2
   * item 3
9 the first line after the list (5-8) contained the list code.