Could we have preview auto-scroll to emulate synchronized scroll?

#1

On Discourse, the edit preview is synchronized with the edit box, so you never lose your place.

I don’t imagine that that feature would be easy to implement in TW, But would it be possible to have the preview auto-scroll, say every 5 seconds, to the bottom of the panel? A standard work-flow is to add items to the bottom of a tiddler. Being able to continuously see the preview rather than having to switch focus to the 2nd pane and then scroll down would relieve the tedium a bit. And yes, it would have to be configurable so it’s only on when it’s useful.

#2

Some changes to the parser have been pushed lately, that may make it possible to create some relation between input text and rendered output. … BUT … As soon as transclusions are part of the equation the mechanism will probably break down.

I was thinking about a similar mechanism lately, but I didn’t have a closer look. … I thought, it should be possible to sync scroll events between the editor and the preview. …

But implementing these thoughts will be way to hacky, to be part of the core. So whoever make something described here, should start with a plugin and see, how what comes out.

#3

Yes, I recognize that actual synchronization is difficult. But automatically scrolling to the bottom (or top) … that should be doable, right? Sort of a poor man’s auto-synch. As long as you’re working at the top (or bottom) of the tiddler, it would feel like you’re in synch.

#4

I’m not so sure anymore. … I did have a look at the KeyboardManager function in keyboard.js. An event is fired at every key-stroke.

The very first functionality that is checked are “global keyboard shortcuts”. If a shortcut is detected an actionWidget is activated.

So for a proof of concept it would be possible to crate a shortcut, that triggers a “tm-scroll” message. … The problem is, that global shortcuts don’t know anything about the edited text. Especially they don’t know where the cursor is.

Editor shortcuts should know this. eg: CTRL-B for bold needs to know what to do and where. … It has the info about the cursor or a selection of text. …

Text operations would be easy to implement with a pluin. → That’s the good thing. It should be relatively straight forward to create a tm-scroll message and send it …

Since the parent element of the editor and the preview-preview element is the same DOM element it should be able to catch that info. … (So the existing event-catcher may be an option here)

There are 2 problems left:

  1. Finding a consistent name for the rendered DOM elements that we can scroll to.
  2. Rendering the DOM elements with that consistent name.

No. 1 should be simple. We just send the current cursor position and let the receiver find out where to scroll too :wink:

No. 2 Is a bit trickier, since we will need to modify the rendering mechanism, so it adds some meta info to every DOM element at level 1 using the afore-mentioned start / end position known in the parser. …

No promises. … Just some brainstorming for a concept that seems to work, looking at the code and in my imagination. But I would really love that feature myself.

#5

@pmario in the brainstorm mode one thought I had was using line numbers, if you use codemirror with line numbers displayed when editing, you can imagine a preview pane that renders the tiddler but displays the source line number “when available” to the left of the preview content. Providing the ability to move to next previous line number in the preview. Limited to only line numbers that have an identifiable position in the preview.

  • I kind of imagine a set of generated anchors during the preview render process (uniquify with the tiddler name)

The idea would be that a toggle be available when navigating the editor could make the preview jump to the matching line number, where available. In many cases which will be what the user wants, both when writing prose or code. Where the physical line number can’t be “represented” in the preview, they would collapse into one;

09
10 <$list ..
11  content
12 </$list>
13 
14 {{transclusion}}
15 <hr>
16

The preview pane would look something like this

09
10        top of list generated
      01 1st list line
      02 2nd list line
      03 4th list line
13
14       top of transclusion
      01 1st list line
      02 2nd list line
15        ---------------------------------
16
  • In the above example if in the edit pane you are on lines 10, 11 or 12. the preview remains at position 10 because these are inside the list widget, unless you use the alt-down which will scroll to the next virtual line number.

Of course when the code results in multiple lines being rendered such as the result of a list widget the previews line numbering will present multiple lines without a line number. However we could then introduce another mechanism or method for the user to scroll this content in the preview, such as a alt-up arrow or alt-down arrow to scroll the rendered content, up or down key in editor would jump to known line numbers.

We could generate a subset of virtual line numbers in rendered content that can be navigated, based on the rendered HTML.

I imagine the preview would have two left hand columns, one referencing the physical line number in the source code, the second virtual line numbers that appear between physical line numbers. Basically it will then be possible for the user to understand and navigate the difference between physical and virtual lines in the preview.

I have some ideas about the mechanisms to achieve this which we can discuss.

  • Eg an alternative parser that accepts the wiki text with line numbers in the first position of every line, that can be displayed in the previewer when possible, without altering how the text is rendered.

Tones

#6

The problem with line numbers is, that the parser has no idea of lines. It is character based. So theoretically every element like some bold text could get a “scroll to” or “highlight” marker.

In practice, the rendering engine doesn’t use the “start / stop” character positions, to create those markers at the moment.

#7

@pmario I am not sure I understand your point, Perhaps the parser has “no idea of lines” what I am suggesting is creating a preview that is effectively an emulator of the current parser, it acts on the text field we are currently editing.

  • We need a preview developed, not the parser to act differently.
  • We may need the editor to act differently, but I imagine if we use codemirror we may be able to find the line number the cursor is on. After all line numbers can already be displayed.

This is all conceptual speculation, read only if interested in this challenge.

The text field we are editing does contain lines, delimited by \n. The idea is with this seperate preview/parser is, as it parses it takes any information it obtains about line numbers and throws it “out of band” not in the output itself, then when navigating in the editor if we know the line number we can use this to synchronise with the preview. The result is fuzzy, but I expect good enough.

One way to conceive of it is what if every “\n” in the source was in fact a wikitext character, that the parser processes, but does not display inline but in another element, which ends up tied to one or more positions in the output.

I do understand that sometimes the underlying code structure makes something difficult and it is hard to see a way to modify it to do what we want, however there is a strong argument by using javascript, an independant parser in a preview module, that arguably it would be harder to argue “it cannot be done” than to “imagine an approach to do it”.

I must be honest and say, I can envision this, but not necessarily do it.