MMD or LaTeX rendering, semi-live

Well, I already know what the answer for this is, but it doesn’t hurt to ask…

Is there any interest in building in the functionality to render MMD or LaTeX tables and such, inside Scrivener? I don’t imagine it would be possible to do “live” rendering, but maybe semi-live, such that you push a little button and it parses the code on the page, throwing up a split-pane or something with your finished/rendered output. Sort of like a preview, perhaps not a complete feature set for really complicated code, or perhaps someone like LaTeXiT or TeXShop has some API hooks that would simplify this.

Just planting seeds.

That would be swank beyond belief. :slight_smile:

Fat chance, though. Have you tried mucking about the multimarkdown2latex.pl file? You could integrate the pdflatex (or whatever program you use) command into it, and then an open output.pdf & command with will load it up in Preview or Skim automatically. I haven’t tried it, but in theory that should work. Then you just compile to LaTeX. The only real issue is when you don’t want to do that. It’s pretty easy to add your own meta-data. In that same Perl script, near the top, you’ll see a function call (which is defined at the bottom) which looks for the LaTeX XSLT meta-data and falls back to a default. You could insert your own meta-data line, like No PDF: true, that temporarily suppresses the automation part of the script.

I’m not sure if a LaTeX preview is really necessary (the LaTeXit Services work with Scrivener), but what I’d love to see in Scrivener is an HTML preview feature for MMD. Not for the complete draft, just for the active document.

That would be much more realistic, and could probably run “nearly live” with a bit of delay, say at the auto-save interval. Editing in TextMate or something is always an alternative (and getting a LaTeX PDF there is easy, too with Cmd-Opt-L / Cmd-R), but I often rely rather heavily on annotations and other formatting tools for syntactic purpose, making round-trip very impractical.

Blimey, I think that would be way out of Scrivener’s remit! (It would be a very cool feature for MMD users, though, of course.) I know TextMate allows for LaTeX rendering somehow, but I believe I’d have to use third party frameworks or something… It would be a lot of work and something I can’t see myself embarking upon, I’m afraid.

Part of me does think that there could be a very cool MMD program that could be written one day… A bit like Coda with the preview pane showing the rendered MMD. A Scrivener-style hierarchical binder showing the hierarchy of documents.

If anyone has any idea how TextMate renders LaTeX, or how it could be done from a(n easy) development angle, be sure to point me in the right direction, though, if only because I am curious about the idea of an MMD app that would do this sort of thing. (Which in no way means I’ll ever write such a thing given other commitments, but I do think there could be something in it and would be interested in exploring options off in the future.)

All the best,
Keith

Hi Keith,

Textmate does not render LaTeX directly, the “Typeset & View (PDF)” feature just calls pdftex and displays the resulting PDF in a separate window (the latter is probably some very basic Cocoa function). I’m afraid there’s really not much to it. :wink:

If you still find the time to add another MMD feature to Scrivener, go for the HTML preview. I can imagine that this would be relatively simple to implement. You just have to send the contents of the active text file through multimarkdown2XHTML.pl and display the XHTML output with a Cocoa WebView object in a popup window.

Bild 2.png

Interestingly, I was working on such an application for MMD when I discovered Scrivener, and emailed Keith to see if he could make a few small :slight_smile: tweaks to make it more useful for me as an MMD application. I was pleasantly surprised when he wrote back to say that his users had already requested this, and he was interested in supporting it.

My app was a native Cocoa project, with a three pane window (IIRC):

First pane was a tree controller for the document structure (allowing you to navigate between sections and rearrange them as desired)

Second pane was for editing the text within the selected section (I hadn’t figured out how to combine the text from multiple sections like Scrivener does - it was a one section at a time app for the moment)

Third pane was a “live” preview. Actually, I think this may have been a separate preview window.

I hadn’t been working on it too long when I discovered Scrivener, and at that point ditched the project. Scrivener was a much better app, and it could do 99% of what I needed from my app. Whereas mine could only do a small fraction of what Scrivener could do. Second, the performance for live preview was horrendous. It was quite slow, and despite being built around native Cocoa bits with minimal code of my own, it was prone to not working, and the preview window would need to be closed and reopened.

I think such an app is possible, but would benefit tremendously from using a faster rendering program than MMD (written in perl, and not particularly well optimized). It would probably be ok for smaller documents, and when only rendering one section at a time. But currently, it would take processing the entire 200 page document to add one “the” in the middle of a paragraph. Using a native C interpreter, or perhaps the Haskell implementation of pandoc (I believe it is supposed to be pretty fast), might allow the performance to approach being useful.

F-

The performance issue is definitely something concerning. For single doc and small E.S. edits, having the thing render whenever you pause for a few seconds would be feasible; consider how quickly a 2,000 word document can be XHTML previewed in TextMate. Another thing to consider is that much of the time this preview window would be displaying nothing terribly interesting. In the contrived example above, there is a lot going on, but for me anyway—vast tracks of text are nothing but paragraphs with maybe an italics here and there. That’s a lot of CPU going on to do what is essentially nothing more than changing the font and ruler settings. Something that can be done, with no ill side effects, in Scrivener.

Not to marginalise the idea. When I write in TM, I nearly always have a preview on the side which I use to read the content comfortably using my favourite CSS file. There is something to be said for putting content into a “pseudo-print” layout; it causes problems in prose and technicality to come to the surface in ways they might otherwise disappear. This is true for RTF users as well. Moving your content to a slightly different presentation format forces your eyes to lose their habitual blind spots.

Here is one way that could boost performance: the preview split (or window; whatever) dumps the render to the disk using ID.html where ID is the Binder node’s number. It stays on the disk as a cache for the rendering engine. This solves Cmd-[ and ] lag issues. It also solves problems with massive E.S. sessions. The E.S. preview would stack ID.html files in accordance with the selected Binder items in the session. When the user edits document #41, only document #41 changes in the preview; the rest of the stack doesn’t get re-rendered. In this sense, it is a non-editable E.S. session of its own; so it could probably use the existing stacking code for doing this, given that Scrivener can already handle having a hundred RTF files open at once without turning the system into molasses whenever you type ‘the’ in the middle.

So, Scrivener checks mod-stamp on RTF to mod-stamp on HTML file when clicked in Binder. If there is no discrepancy (which their shouldn’t be unless the user was editing with the preview window turned off) it just loads the cache file. This means lag the first time you create a large E.S. session with new files. Threaded rendering with a progress bar of sorts embedded in the top of the window (roughly rendered by number of files remaining in the render queue) “solves” that. Even large documents will take only a few seconds to appear; and of course by large documents I mean entire parts of books; tens of thousands of words, nothing trivial or average in terms of E.S. sessions. For the most part, edits are small file changes. Average Scrivener Binder chunk is under 1,000 words which means nearly instantaneous rendering of that portion of the cache stack. Only exception is very large Find and Replace in E.S. while the preview window is open. This would require another few seconds and progress bar. But again, not a common thing.

There is the matter of elements which depend upon other Binder items to properly function. Two examples: 1) Footnote rendering, and 2) Referenced style linking. It is very common for me to keep URLs very lightweight in order to keep the file nicely human readable. I tend to keep URLs in a separate Scrivener file called links down at the bottom in a preserved format Binder file. It’s essentially invisible to the Compiler process. With the described cache system the MMD system working locally on a single space would not be aware of referenced links outside of the rendering space. Also, footnotes would appear at the bottom of the rendering space and not at the bottom of the “document” when multiple files were in an E.S. stack. I think the latter problem is less of an issue. Is it really that disturbing to have footnotes somewhat contextually located? I think not and in fact for the writing process, that is preferable. Referenced image and URL links are more of a problem.

In fact, images raise a number of problems all around. Right now Scrivener nicely collects everything for you when you compile so all the image links are valid. In this proposed system, images are sometimes not even in the main project area, but tucked inside of RTFD files with conflicting names.

So I don’t know. Given the complexities raised here, and the above fact that 90% of the time the preview window is just going to be displaying normal paragraphs, might this be more work than it is worth?

As someone who encouraged Keith to add MMD support( and perhaps underestimated the time requirements for some of that effort…) I would tend to agree with this. But that’s just me, and naturally I would welcome any application that improves integration with MMD!

F-

Pray, tell more

Apologies for the topic switch, but while I see Fletcher here … is MMD likely in the near future to have any way of annotating around a multi-block-level chunk? Something roughly equivalent to:

block 1

block 2

  • b1
  • b2

Thanks

Not sure what you mean by annotating in this context, but you can wrap a div around MD/MMD content by including the attribute markdown="1" inside the div tag.

F-

Ooooo; that markdown=“1” is just the kind of trick I’ve long been wanting. :slight_smile:

By that I meant, I use Scrivener’s formatting tools to form a bit of an ad hoc mixture between syntax colouring and annotation. Since I don’t have to worry about format changes bleeding out into the final product, there is a full and quite rich set of features for making documents look like stuff. Might as well use that to enhance the appearance or draw attention to areas of the text.

If I use the TextMate round-trip method, I lose all of that and my documents essentially just become plain-text in Scrivener. That includes losing images, annotations, and footnotes, all of which I prefer to typing in MMD syntax by hand.

Ah, great to know that.

Any plans to have direct MMD markup for this in the near future? e.g.

:::my_annotation
stuff

more stuff
:::

becomes

[code]

stuff

more stuff

[/code]

Thanks - Sophie

Sophie,

There are no plans for something like that in MMD - there were talks of attributes of a sort in MD by Gruber, but I haven’t heard anything lately.

F-

Thank you, Fletcher.

I am considering making quite heavy use of

(via some a pre-process script that deals with my :::: markup).

It will need some custom XSLT templates. If my_annotation will not be any of: bibliography, footnote, glossary, do you think it is likely to cause conflicts with standard XSLT processing?

Thanks!

It shouldn’t cause a problem, as best as I can tell without testing it.

F-