Latex compile: block creating extra line feeds

MWE…

Scrivener:

```{=latex}
 \begin{minted}[tabsize=4,breaklines]{json} 
"autoload": {
	"psr-4": { 
          "UserManagementPackage\\UserManagement\\": "vendor/UserManagementPackage/UserManagement/src", 
"autoload-dev": {
        "psr-4": {
            "UserManagementPackage\\UserManagement\\": "vendor/UserManagementPackage/UserManagement/src",
\end{minted}
```

Latex file:

 \begin{minted}[tabsize=4,breaklines]{json} 

"autoload": {

	"psr-4": { 

          "UserManagementPackage\\UserManagement\\": "vendor/UserManagementPackage/UserManagement/src", 

...

"autoload-dev": {

        "psr-4": {

            "UserManagementPackage\\UserManagement\\": "vendor/UserManagementPackage/UserManagement/src",

...

\end{minted}

Correct compile behaviour?

Revisiting this because the issue remains in latest Windows beta. Given my original example, am I missing a setting somewhere. Feeling a bit challenged although using Scrivener for 7 years.

The problem restated is that when compiling raw Latex in Scrivener, the Latex compile with Minted and some other Latex packages emits exceptions if there are extra lines. Put another way, Scrivener compiles to incompatible raw Latex code.

Is there a Scrivener setting to stop adding extra lines at compile time, keeping raw Latex wrapped code as-is in compiled .tex file output? For example, this code copied and pasted from Scrivener results in an extra blank line after every line…

```{=latex}
\begin{tcblisting}{
      colback=yellow!5,
      colframe=yellow!50!black,
      listing only,
      title=Listing : This is source code in another language (XML),
      fonttitle=\bfseries,
      listing engine=minted,
      minted language=php
   }
<?php
class Xyz{
   public function something(){
      echo "Do something";
      return $something;
   }
}
\end{tcblisting}
```

It’s a frustrating issue, and one that prevents me using Scrivener for technical books and papers.

With 20/20 hindsight, followed by a significant number of naughty phrases, the answer was simple. As a consequence I feel old, dumb, and my technical confidence spanning 50 years ran out of the window at speed (visualise that, fall, and the cartoon look on it’s way down!).

I’m writing the solution now, and will post today.

I had to poke around this and other forums before the answer dripped into my two brain cells.

My main mistake was to presume this problem lay in the complex way I use Scrivener for producing Latex .tex files. In fact, it’s an in-Scrivener style formatting requirement to stop Scrivener compiling Latex code blocks.

My steps were (Windows)…

  1. In the document page, highlight the block of code to remain untouched by compile, including it’s Latex prefix/suffix tags. From menu Format → Style → New style from selection. Name the style (I called mine Latex Code Block) and check the Highlight box so you can see which parts of your document will not be formatted when compiled. In-page highlighting will not affect compile output.

  2. From the menu select File->Compile. Edit compile format with Select your compile format from Formats list → click capstan dropdown button → Edit Format. If you don’t have your own saved format, copy one and rename — evolving it to your needs over time will save lots of future time wasting.

  3. In the open pane click Styles → tiny ‘+’ dropdown → click your new style name to load your new style into the compile Styles pane.

  4. Select your new style to highlight. Click the Treat as raw markup check-box. Click Save

Beware! You must repeat steps 3 & 4 if you change the name of your style. Name changes cause styles to drop out of compiler formats.

Now apply your style to any Latex code block and text that should be left as-is. Compile, observe your .tex file, and voilà! Ça roule!

…Unless there’s a better way?

Perhaps L&L could improve the next release to make this more intuitive for people writing books and theses. They probably won’t have the same Scrivener ‘flying time’ I have but will find a simplified intuitive process invaluable. I thought it was a bug, not an issue caused by obscurity.

It sounds like you may be using the rich text to MultiMarkdown conversion option in compile which will, unless otherwise stipulated, spread lines apart as the idea for that setting is to allow one to write in a largely word processor oriented fashion, with no double-spaced Markdown paragraphs, etc.

Without that option, Scrivener shouldn’t be messing with your carriage returns for the most part (there are a few common-sense exceptions like around the headings it inserts, adding an empty line at the end of the document to keep footnote/image references valid, etc.).

But when you do use that conversion option, yes, you very much need to tell Scrivener when you intend to use raw markup so that it knows to leave the contents of that area alone.

The best thing to do will be to start from one of Scrivener’s provided LaTeX-oriented compile formats, as where you build from, rather than from scratch or even the basic MMD format. The LaTeX formats have a few conveniences built into them, and they are documented in Appendix D.6 of the user manual. One of these is a stock “Raw LaTeX” style which does exactly what you set up by hand. All you have to do is create that style in your project and use it. Of course if you object to the name, you would need to edit the Format. :slight_smile:

But it’s worth looking through these presets as they may help you out or give you ideas on how to do things. For instance I find creating different styles for different kinds of code bocks can be very handy. I have a “Ruby Code” block, “YAML” and a few others, which I use with Minted as well to get syntax highlighting. The style can insert the fence quotes for you, along with the language marker, and of course be set to raw markup.

I’ve also created a sample project with a full stylesheet that you can import from, in the downloadable extras pack. From this you could create your own starter project template with just the styles you want.

Yes. I decided long ago this was the best way for me. I don’t want lots of templates. I’ve two that produce from theses, articles and scientific papers to booklets and books. Honed over about 5 years! You’ve been a great help throughout the forum.

TBH, I find this approach in Scrivener to be the turn off. Perhaps good upon first introduction of the product, but for my specific case this part of Scrivener is not for me. When I recommend Scrivener it comes with a warning that it will do anything so long as you’re prepared to waste ages down rabbit holes. Developers working for me around the world now use it. My current paper, about an international SARS-CoV-2 threat alert software system, would require several L&L approaches, so I’d rather modify my own and the writing practices that go with it. In particular, I strongly suggest against Scrivener’s provided LaTeX-oriented compile formats because they output Latex junk like Memoir configs only suitable for draft papers — not fully prepared publications. Then again, I have a lot of Latex packages organised and configured to work with each other, so acknowledge I’m a nerd/geek in this respect. Not criticising — you’ve done a great thing providing templates to get me and others up and running.

IIRC it was your template of about two years ago that gave me a good insight to developing my own. Now, though, I predominantly load packages via two front matter and one back matter Latex pages. That way I can call in a gazillion different Latex formats according to the document I’m producing — and pass those pages to others so they can produce documents or part documents for me. I know I can do a lot of it in Scrivener, but for me I’m absolutely sure that my Scrivener is unfettered by any idiotic mistakes I’ve made.

Thanks for responding! Hope you and yours are safe and well in these weird movie-like times! :slight_smile:

To clarify, I was specifically responding to the feedback for making this a little easier to learn, and so approaching the problem from the standpoint of a relatively new user who is looking to see how best to adapt their workflow to how Scrivener works. An experienced user would probably do better playing with some throwaway projects to examine their settings, and mix-in anything useful they find.

Personally I view our project templates and built-in formats as training wheels, fully meant to be discarded or heavily modified once someone has used the software for six months or so. They are there to give you an idea of what the software can be configured to do, but by no means are they ever going to address everything everyone will need or want to do.

The one exception is the basic MMD/Pandoc starter format. I did build that one with the specific notion of it being so dirt basic that it could be a starting point for almost anyone using this workflow, while saving a few obvious steps like having three layouts to handle the heading/text permutations most projects will need at least one of. It’s really meant to be the “New Format” menu option for Markdown users.

Like that, there is only so much one can do with an example. These are really just wrappers for Fletcher’s own stock pre-fab examples of how to build a modular MMD LaTeX workflow within MMD’s automation. And the majority of the baggage they present can be entirely dodged by going into the LaTeX Options compile format pane and setting the document class to custom, or by creating your own .tex framework and establishing its use with the “latex config” metadata key (that’s the approach I take for the user manual—Scrivener only generates what comes between \begin{document} and \end{document}), the rest comes from modular boilerplate I’ve built and have stored in texmf.

By doing so, you still get the framework section layouts and styles that may be of some use in developing a more specific setup. If I were to encourage everyone to just start from “New Format” (which is a decidedly RTF-biased set of defaults that comes with a number of assumptions) then I think it would take people longer to figure out how to do things—like reverse engineer how to make pass-thru blocks for raw syntax.

Thus I think good advice for a new user, on how to develop from one of the built-in starters, would be pointing out where to switch off the document class assumptions. That’s probably an essential step for everyone moving beyond, as you put, the draft proofing stage.

Thanks, yeah, you as well!