Side-by-side editing fails if Preview significantly longer than source; needs smart, vertical locking!

[klein@…]

The side-by-side editing is rendered useless, if the Preview is significantly longer (due to large text, tables and inline images) than the source code. You might end up in a situation where the related source code to what you currently see in the Preview is 1 or 2 pages up the screen and it is currently impossible to see source code and related Preview together at once. This is a serious issue in my opinion.

You can make a simple test by positioning a few large images using [[Image(XYZ.jpg)]] underneath each other: The source code only takes a few lines, whereas the last image might by two screens down the window scroll bar.

A solution should look like this: The preview get dynamically positioned in such a way, that it (optionally) aligns vertically with the cursor position in the source code window, so that one really sees what one's editing.

[Christian Boos]

Sure, that would be a nice improvement. But to say this defect makes the side-by-side editing useless is a bit exaggerated: by the same measure, it would mean that the "normal" preview (vertically stacked edit on top of preview) is useless, as you also can't see both what you type and the preview in that mode, except for very small texts.

Implementation idea: send the cursor offset; (WikiDom) have a function to retrieve the node corresponding to that offset, find the closest previous node with an id, send back the preview + that id; in the browser, update the anchor to that id.

[Christian Boos]

(and btw., the workaround I use in this situation is to disable the macros while doing the bulk of editing i.e. [[xxxImage(...)]]; not optimal but works well most of the time)

[klein@…]

Replying to cboos:

Sure, that would be a nice improvement. But to say this defect makes the side-by-side editing useless is a bit exaggerated: by the same measure, it would mean that the "normal" preview (vertically stacked edit on top of preview) is useless, as you also can't see both what you type and the preview in that mode, except for very small texts.

Well, side-by-side is definitely an improvement over the normal vertically arranged preview, but still: I soon as you begin embedding pictures or a formatted structure with headlines etc. you are entering the scroll-wheel hell and as longer the page becomes, as more difficult it becomes to find what you want to edit (it also would be nice if we'd see paragraph-limited editing similar to Wikipedia).

[anonymous]

It would be great if the preview automatically aligned to what you are editing, but, simply, adding scroll bar to the preview area may work so that user can operate independently the source and the preview.

[anonymous]

Solving this issue would be a very useful and time preserving enhancement!

[Christian Boos]

As this was also a feature request from coworkers, I had a try, and as I was quite pleased with the results, I committed the fix in r11109.

Either the textarea or the wikipage preview expands to its natural height (whichever is shorter) and the other adapts accordingly and gets a scrollbar.

Tested with all browsers at my disposal IE9, Chrome 21, FF 13, Opera 12 and Safari 5.1.7 (Windows).

[Christian Boos]

Note that this still doesn't work correctly in the presence of images (or other kind of delayed content)…

[Christian Boos]

Replying to cboos:

Note that this still doesn't work correctly in the presence of images (or other kind of delayed content)…

​SO:910727 → ​http://api.jquery.com/load-event/ (the Caveat about img) and ​https://github.com/desandro/imagesloaded or ​https://github.com/alexanderdickson/waitForImages. Need to experiment a bit…

[Christian Boos]

And even with no images, you can still have a "jump", moving your cursor out of sight. For example, when editing at the bottom of the text area and you delete some content.