Is there any chance that a future version of Scrivener will include a choice for the editor to work with styles as it currently does, or to use a Markdown editor instead?
Greetings,
Thomas
1 Like
Scrivener’s core editor uses rich text. That is unlikely to change, both because it would require completely rewriting the editor and because plain text users are a relatively small (though vocal) part of our user base.
However, there’s certainly no requirement that you use styled text in your own workflow. If you prefer Markdown, go for it! See Chapter 21 in the manual for guidance.
2 Likes
But styles are one of the things that set Scrivener apart from the 1,001 Markdown editors out there! If we were to hypothetically get rid of all of that and just do like everyone else does, it would be a massive downgrade in my opinion.
That’s just styles (as a formal feature), there are other things more loosely related to formatting that you can’t do in most text-driven Markdown writing tools: revision tracking, freeform multi-colour highlighting, sensible annotations and sidebar comments/footnotes (and having those footnotes sequenced for you automatically), links that are purely editorial, and really the possibilities are endless and freeform once you switch to the perspective of looking at “formatting” from the angle of it being a writing and editing tool, rather than something you need to use to make things look a certain way.
Besides you already essentially have the choice you state you want: it’s just not a toggle somewhere that would destroy your project if you turned it on without realising the implications. Instead it is a matter of simply not using what you don’t need. Turn the Format Bar off, set your preferences to work more like a text editor, and get back to work. 
At any rate, this has been discussed many times before, and if none of the above is compelling, feel free to search the forum for feature requests for “syntax highlighting”, “markdown mode” and so forth.
3 Likes
I understand the point and agree with you. Of course, I am aware that you also introduced the style system with version 3.0 to make it easier to switch from text programmes. I didn’t want to ask you to discard it with my question. The question was aimed at a switchable additional function, but I also understand the difficulties that this brings for the app concept. Users don’t have to use styles if they don’t want to, and I’m fine with that. I love Scrivener anyway and still. 
1 Like
Automatic styling (while typing or pressing enter at the end of line) is a feature that one can find in some other editors. For example, Ulysses dims down hashes and boldifies the titles (Markdown semantic). Similarly, Emacs can do the same with Latex syntax (recognizes standard sectioning macros), and of course most of code editors have similar theming feature for code (well, they have easier time with tokening).
It will be good if one can write in Scrivener in Multimarkdown or Asciidoc and things get styled automatically, making the text more readable, letting more focus on the content.
I am specially interested in a customizable and language-agnostic feature, so one can tune it for other lightweight markups, such as Asciidoc. At the moment my workflow is like this:
- I write in Asciidoc in Scrivener (as large as book size).
- I compile to text and the shell command invocation of Scrivener lets me to run a script.
- The script uses Asciidoctor to convert to HTML, also my self-developed extension convert it to Latex (and eventually PDF).
- I heavily rely on roles in Asciidoc that get translated into classes in HTML (and Marcos/Environment in my Latex extension) to stylize the final output. Those roles in the main text are somehow distracting when wants to focus on the content.
I’ve merged this with a very recent discussion that touches on some of the same factors. Here is an older discussion on syntax highlighting, specifically. But there have been several over the years that can be looked up.
@shahryar: I heavily rely on roles in Asciidoc that get translated into classes in HTML (and Marcos/Environment in my Latex extension) to stylize the final output. Those roles in the main text are somehow distracting when wants to focus on the content.
On this matter, this is actually one of those things that goes back to what I discussing above, with regards of how a style engine in the editor can be used to reduce procedural syntax clutter in the writing environment. One of the big advantages of this approach, which I touched on in the first link of this post, is that by deferring precise syntax declarations to the compile phase, we obtain centralised control over that syntax. If hundreds of references to that look (or role) merely abstractly define themselves in that fashion, changing our minds about the particulars of its execution can be done in one single place rather than hundreds.
That’s all getting into details perhaps outside of the scope of this discussion though, so if you’re looking for particulars, I’d do some searching for “styles” in the Markdown board.
This actually sums up the existing style mechanism pretty well!!! Styles are semantic labels that are totally agnostic as to how they get converted at compile time, and their look in the editor can be fully disengaged from any output. You choose the translation. This is a unique feature for any editor, is more flexible than general syntax highlighting, and a hugely powerful Scrivener feature.
You can use multiple different compiler formats, using different style⇨markup translation rules; and/or you can use a general markdown compiler format and named attributes (equivalent to asciidoc roles IINM) as the one-true-ring to enable Pandoc to use its abstract-syntax-tree system to generate asciidoc / HTML / LaTeX / DOCX and a zillion other output formats…
1 Like
Thank you @AmberV and @nontroppo ,
I admit that the feature of style->syntax in the compile is a very powerful feature, where translation to a markup language is one of them. Actually, I was tempted before to use this feature, however it did not match the requirements precisely (I still use it to bare the text from syntax punctuations).
The point I want to make is:
1- In my latex package (for PDF typesetting), or alternatively in my CSS file ( HTML based typesetting) I have defined tens of roles/classes. For any inline or block element, multiple roles/classes might be applied simultaneously. So, I might say a block should have both myDropCaps and myRed to make a red paragraph with an initial drop-caps. However, this is not possible with styles, since only one style can be applied to a piece of text at a time.
2- Roles cannot always find a good formatting counterpart. For example, I have defined myTwoPagesFigure role but there is nothing in formatting that matches this meaning. Some roles can take extra attributes, let’s say myIncludePDF can get another attribute as the name of the file to include. This is not possible to be implemented by styles.
3- Because of 1 & 2, I think I need to keep the syntax (in my case Asciidoc) in place, but it is good to:
A: Automatically dim them down to make them less interfering with the rest of the text (eg grayed == in a heading)
B: For few cases that a styling can represent the syntax to apply them automatically. So typing ==The Heading would result in a kind of bigger font size for that text.
It is possible to use style shortcuts for feature A, but it is not as much convenient as automatic styling. Similarly, one can manually apply styles for B, but that still interrupts writing.
I should also express that the RTF feature of Scrivener is quite instrumental in writing any markup text (even without compiling to anything). Using colors, font size, … (in addition to lots of internal features of Scrivener, such as notes, ….) adds an extra layer of meta information to the text, making it a workshop for the final product.
Scrivener can nest inline styles inside paragraph styles — so in several use cases where you can validly specify the semantics as inline and block (like a dropcap and custom style for a paragraph) that will not be create a problem. In other cases, a slight readjustment of the semantics by using “conjunction” styles. For example you can have inline strong and inline emphasis, but you cannot apply strong and emphasis inline styles together classically; but with a single strong emphasis style you get a semantically valid style that the editor can now handle. If you are using large numbers of such conjunctions then you may face a combinatorial explosion using this route, but Scrivener can handle a large number of styles and I don’t see how this can be worse than manually nesting lots of markup inside each other in the editor (and I imagine robust syntax highlighting of nested blocks is not trivial and doubt any editor handles this well)!!!
Scrivener’s compiler doesn’t care about this as it is agnostic to the meaning of the style, I think this shouldn’t pose a problem, that is problem for the tool that actually makes the final document…
Indeed, this is a clear case where a style cannot fully encompass the requirements (except given some tricks like using Pandoc filters which can take metadata and rewrite the document, or an intermdiary script). There is nothing stopping you however from making a “hybrid” document by generally using styles where they make sense, and in the cases where a style cannot easily substitute then using markup.
I understand you are a user who is already used to manually writing your markup into your document, and for you this is currently “easier” than toggling a style.
But it is pertinent to remember that manual input of markup is not a free operation, and can take time typing the markup and adds distraction from actual writing. Appropriately named styles can be bound to keyboard shortcuts and so can arguably be said to be objectively faster than manual input proportional to the amount of markup the equivalent markup requires (unless you are using a snippet / macro manager or something to “expand” the markup from some minimal trigger).
All of this is not to detract from your wish, you have a valid workflow and given your current workflow I’m sure syntax-highlighting would be a clear benefit. We’re pointing out an alternative workflow that is also valid and certainly more flexible across multiple markups. I’m only an end user so can’t predict what L&L will do in Scrivener V4, but I am pretty sure it will not become a plain-text syntax-highlighted editor (that has been stated multiple times by L&L staff at least), and even if it did I wonder how it could satisfy the panoply of different markups like asciidoc along with all things like custom roles / environments etc. (well unless it built on top of something like VS Code)…
1 Like