Skip to content
This repository has been archived by the owner on Jan 3, 2023. It is now read-only.

Sync preview with source position for pandoc backend #106

Open
lierdakil opened this issue Sep 6, 2015 · 9 comments
Open

Sync preview with source position for pandoc backend #106

lierdakil opened this issue Sep 6, 2015 · 9 comments

Comments

@lierdakil
Copy link
Collaborator

So, as discussed in #104, I'm opening an issue for this.

As far as I can gather, there are a few options with how to go about this.

  1. Scroll to percentage, i.e. if source is at x% from top, scroll preview to x% from top. That's what I ended up with in markdown-preview-pandoc. Not ideal, especially for image-heavy documents.
  2. Embed raw html anchors near all block-level elements before passing source to pandoc. This is theoretically doable, but for it to work, you'll need to actually parse source markdown to find block-level elements in the first place. It would have to be pandoc-flavored markdown to boot, so probability of finding a library for this is slim.
  3. Contribute to pandoc. This should actually be rather simple: add a reader option, and then embed some sort of markers (e.g. raw html anchor) into Pandoc's internal representation on each block-level element. That would be passed through to writer, where you could use it to your advantage. I have a general idea of how this should be done, so I could slap together a proof of concept, if needed. Drawback is we'll need to get this into pandoc, and then wait for next release, and this can take a while.

There are probably other ways of getting this to work, but I can't think of those.

@Galadirith
Copy link
Collaborator

@lierdakil Thanks for a great summary of candidate options.

  1. Yeh I think as you allude to scroll % doesn't really work for markdown.

  2. Discussed below

  3. For reference I did find a couple of related google groups posts on source mapping in Pandoc.

    But it sounds like your suggestion would be easier to implement (I really don't know Pandoc's code so I trust you on that ;D) but as you said it would very much be dependent on the Pandoc dev's, which is of course completely understandable.

So (2) would definitely be the option I would think would be most viable. While you say you would need to have pandoc-flavoured parser to properly do this, for most of the block level elements markdown-it identifies them the same as Pandoc. It wouldn't be perfect but at least heuristically good enough to use markdown-it to identify the block level elements and use that as a guide as to where to place anchors. Just a thought.

Definitely some good stuff to think about here.

In terms of design direction, as long as @leipert's comfortable to do so, I would want @leipert to have the final say on any design decision to do with Pandoc related features. @leipert worked hard to get Pandoc implemented in MPP so its certainly not my place to go over his head.

And finally @lierdakil once @leipert brought into the discussion, we've got a lot of stuff to work on for our 2.1.0 release. Its unlikely that I would have time to handle this for that (I don't know about @leipert), probably for a 2.2.0 or beyond. Maybe getting straight back into coding for a markdown previewer is not something you want to do, but if you did and wanted to accelerate this features integration then it would be great if you opened a PR on this, but that's completely up to you :D

@lierdakil
Copy link
Collaborator Author

@mb21, uh... am I seeing things?

@mb21
Copy link

mb21 commented Mar 29, 2017

@lierdakil sorry, I posted on the wrong project... (I deleted the comment again) see https://groups.google.com/forum/#!topic/pandoc-discuss/SkVskyUKQiU though..

@lierdakil
Copy link
Collaborator Author

Okay. At least I can stop worrying about my sanity for a bit 😆 Thanks for the heads-up.

@lierdakil lierdakil added this to the v2.6.0 milestone Jan 29, 2018
@lierdakil lierdakil removed this from the v2.6.0 milestone Mar 4, 2018
@JackElsey
Copy link

JackElsey commented Jul 13, 2020

I'm using this (excellent!) add-on to write my dissertation, but I've had to turn off automatic preview position syncing because of this issue.

If I see something in the preview I want to change I copy a snippet of text and search for it in the source. Would it be feasible to change the behavior of "Sync Source" in the preview context menu so that it finds the correct line in the source by doing a search for highlighted text?

@lierdakil
Copy link
Collaborator Author

lierdakil commented Jul 14, 2020

@JackElsey, I've added a simple search-in-source command in v4.1. The caveat is it breaks on formatting. For instance, in the rendered document you might have "A sentence with emphasis", but in source it's A sentence with _emphasis_, hence searching for literal A sentence with emphasis will fail. And it's in general impossible to reconstruct the original source given only the rendered result (consider for instance that Markdown will render both _text_ and *text* as <i>text</i>)

@JackElsey
Copy link

Thank you for the lightning-quick turnaround!

@JackElsey
Copy link

JackElsey commented Jul 20, 2020

If automatic preview position syncing is turned off, it would be nice if the preview remained in approximately the same position when the document is rerendered. When I make an edit that results in a rerender the preview window is often moved back a few sections and I have to scroll down to see the changes I made. I am using version 4.3.0 and can provide an example .md file if needed.

@lierdakil
Copy link
Collaborator Author

@JackElsey, define "the same". The preview is updated using a differencing algorithm, so it doesn't completely re-render (or at least it shouldn't), instead the changed blocks are replaced. So the vertical position in the preview generally should stay "the same" in terms of pixels scrolled from the top of the document. If I'm misunderstanding something, please open a new issue and include the example there. Thanks.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants