Open lierdakil opened 9 years ago
@lierdakil Thanks for a great summary of candidate options.
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
@mb21, uh... am I seeing things?
@lierdakil sorry, I posted on the wrong project... (I deleted the comment again) see https://groups.google.com/forum/#!topic/pandoc-discuss/SkVskyUKQiU though..
Okay. At least I can stop worrying about my sanity for a bit :laughing: Thanks for the heads-up.
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?
@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>
)
Thank you for the lightning-quick turnaround!
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.
@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.
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.
There are probably other ways of getting this to work, but I can't think of those.