More smart multimarkdown editing features

fbb · August 27, 2017, 5:34pm

I love that scrivener handles some of the multimarkdown … marking for you (headers on export, and footnotes, for example). I’d love to see more of that.

Examples:

Add a toggle to the formatting bar that causes it to behave normally, or as a multimarkdown marker. When in markdown mode, any styling that we apply shows up in the form of multimarkdown code.

For example: When text is marked as bold in markdown mode, the “**” symbols will be applied before and and after the selected text.

Otherwise, in “normal” mode, it is bolded visually, and you can then optionally convert that normal bolding to markdown in the compile process.

I’d like to see the same functionality for italics and lists

The same markdown toggle button could be used to apply blockquote marking to a selection of text (spanning multiple paragraphs for example) and mark them as a single block quote, or a block quote per paragraph (need another option for “per element” or something).

Otherwise, in normal mode, the blockquote formatting would be applied visually and, seeing as stylesheets will be coming soon (I presume this will supplant the formatting templates), can be converted to multimarkdown as a post conversion.

give the user the ability to add an html wrapper to a selection of text.

I imagine a workflow where I select some text and then choose a wrapper, such as

, from a list and the opening and closing tags are added before and after the selected text (perhaps with an option for whether to have an empty line between the wrapper and the selected text)

I’d also like to be able to create my own custom wrapper where I designate my own open and closing tags, and save these settings as custom presets. If you make this generic, I could add a div with a custom class like so:

.

Or I could add a multi-line wrap such as:
Opening tag:

Closing tag:

Or I could add something completely arbitrary, such as:
Opening tag:
A bunch of Nonsense blah blah blah (maybe an empty line would be more useful)
Closing tag:
goodbye (this is your closing tag)

A feature that enables you to specify a specific or set of specific markdown or html tag type/s, and have it/them automatically removed from the selected text, the current doc, or a selection of doc/subdocs.

So, if I choose

as the html tag I want to remove, it will remove both the opening and closing tag of any div within the selection (if the opening tag is selected, but the closing is not, both will be removed. Same thing if the closing is selected, but not the opening). This will work on every div, no matter whether it has a class or id etc within the opening tag.

The same sort of smart deletion would apply to markup such as the bold “**” marks before and after a selection - if one half is within the selection, both are removed.

This one isn’t exclusively useful for markdown, but it definitely applies: In the separators section of the compile settings, make it possible for someone to make more than one rule per scenario, such as a blank line and a page break.

Also, when a custom rule is used, make the entry capable of supporting more than one line of text. One way I would use this is to automatically add one or more html wrappers, perhaps followed and/or preceded by a blank line.

nontroppo · August 28, 2017, 8:29am

The first part has already been wished for and answered before. I am pretty sure L&L stated that Scrivener is built around a rich text editor and for various reasons are very unlikely to add an MMD mode during editing.

I personally do not see the need to toggle mmd-markup on or off during editing, and am happy to use the markup as I would in a plain text editor. Scrivener 3 is coming with a full styles system, and one thing that would be really cool is if we could use styles to convert text to specific markup, i.e. you use [strong] character style in the editor, and during compile you can ask Scrivener to replace it with text. You could create lots of styles and the transformations would apply at compile time. Lets hope the styles system will be flexible enough for this kind of use…

Regarding your part 4. — I think compile replacements should be able to do part of what you want? Some of these features requests are quite hard to achieve even with regexes, and I really think you should think about doing some of this using Pandoc filters[1]. Pandoc converts documents into a semantic AST, and this enables you to robustly make such kinds of conversions. Pandoc 2 will expand support for block and span classes and should enable very complex transformations in a way the editor could not easily do (though perhaps Scrivener 3 has some smart things to do regarding styles).

[1] my preferred tool for this is Paru.

fbb · August 28, 2017, 8:55am

Sooo… you don’t see value in saving time marking your doc up? I’m thrilled that you’re happy with things as is, but I’m completely baffled as to why you would stand in the way of other’s getting the advantage of a pretty straight forward time-saving toolset - this is a wishlist after-all.

Re-reading my suggestions leads me to wonder if the scenarios where my suggestions really would save time aren’t so obvious. The blockquote, suggestion, for example, is especially relevant to scenarios where a quote spans mutliple paragraphs. Right now, to the best of my knowledge, the only way to have all paragraphs included as part of a single block quote is to add one > character in the line between each paragraph. This is, at times, a nuisance. Similarly, manually creating lists is much slower than using the lists feature in the formatting bar.

Thank you, BTW, for your suggestions about compile replacements and paru - that might be useful, though it really wouldn’t fill the gap left by my unfulfilled feature wish, #4.

nontroppo · August 28, 2017, 1:31pm

fbb: I’m sorry if I sounded negative, this is a wishlist and you of course are welcome to your wish . Scrivener 2 does not currently have any system to define the semantic blocks necessary for this feature, and I’m not so convinced by your usecases how toggling this ON and OFF in the editor really saves time. I do agree Scrivener should convert lists by default, though it can easily be done with a couple of compile replacement regular expression[1].

I am being pragmatic in that a markdown-mode has been wished for before. Now, Keith may have changed his mind, or decided that the new batch of Ulysses converts deserve a markdown toggle in Scrivener 3.1, and you will get a nice gift. But I’m skeptical. And the reason I alluded to is:

Scrivener 3 is going to have a styles system. Imagine if you use custom styles in the editor (blockquote, figure legend, emphasis, superscript), you now have the semantic blocks and spans necessary for any kind of transformation; you have given a semantic structure to your text. Critically, compile has the tools and mechanisms to replace and transform text, and I’m sure it would be easier to do here. If the user feels pressing ⌘+B is easier than ** then he uses this when writing. Compile then converts styles to markdown. This is much less complex than having two editor operation modes in an already complex program. IMO of course!

For #4 I don’t understand your reason for needing UI in the editor for this, why don’t replacements do what you want?

r.e. #6 — I agree that more flexible and multiline separators would be cool!

[1] This makes bulleted and numbered Scrivener lists convert to markdown lists:

fbb · August 29, 2017, 4:12am

The value of the markdown mode toggle is that it allows people to work in their preferred manner. I suspect that even with the styles-to-markdown at compile-time features that you describe (which were also among the features that I asked for in my wishlist), some people will prefer to work directly with markup in the document. For example - I’ve noticed some people report that they use styling within the editor as part of a system of making notes for themselves. I’m not sure why they don’t use the comments and highlighting features instead, but I allow that there might be a legitimate reason to do this. In such a scenario, one would rather not convert visual styles to markup, and would probably appreciate the sort of time-saving features I proposed.

The toggle itself would be an inefficient feature if one had to turn it on with every use, but I expect that those who use it will turn it on once and leave it that way (I would expect the last state of the button to be retained between sessions).

Frankly, this seems like a feature that ought to be fairly trivial to implement - I’d swear I see much more complicated stuff achieved all the time. But - I am not aware of all the technical in’s and out’s involved in implementing this feature, and I appreciate the need for pragmatism, so, having submitted the idea, I suppose I’ll have to trust that the developers will do what they can and apply their time to those features that will bring the greatest value for their efforts.

With regard to item #4: I’m wondering if we may be failing to connect on what it is that I’m actually asking for - your suggestion of using replacements at compile time or in post wouldn’t suit my purposes at all. A search-and-replace methodology would only be useful in cases where there was a consistent, repeating, set of text to be replaced. What I’m asking for is the ability to quickly add an html (or other) wrapper to any arbitrary selection of unique text. A search-and-replace-in-post methodology would be far less efficient than just adding these wrappers manually, seeing as I’d have to then maintain a separate list of one-off text selections, and the version I want to change them to, in order to run a replace execution on them.

Also, implementing this idea should be very easy. It’s really just a shortcut way of doing a search and replace on the selected text, the replacement text being identical to the original except for the text added before and after the text selection, as determined by the preset. The logic required would be extremely straight forward. A = the text to be added to the beginning of the output text (obtained from the selected preset); B = the selected text; C = the text to be added to the end of the output text (obtained from the selected preset). Add them together, A+B+C = output text. Search and replace (within selection) the original text with the output text.

To make the value of such a feature more clear I will describe a scenario that I have encountered more than once where I would use this feature if I could, namely one where I have a list that I want to make, where one or more items in the list actually consist of mutiple paragraphs. The usual markup for lists doesn’t seem capable of supporting this scenario, so I’ve taken to using html to create the list. With the features I asked for in item #4, I could select the whole text and choose the html

wrapper to the body of text for each item of the list. This would both speed things up and reduce the risk of manual error in creating the opening and closing tags (Incidentally - using html for lists is also useful in that it makes it possible to easily add additional markup or html within each list item).

Another scenario where this would be useful is one where, for reasons of my own, I want to add a

wrapper to a selection of text, with a custom class
that will allow me to treat this selection of text in some special way in a blog post. I may want to do this to multiple selections, on more than one post. Being able to create a custom preset where I specify this wrapper provides a quick way to add this wrapper and it reduces the risk of typos in creating the class name etc, or forgetting to add the closing tag.

BTW - thanks for the tip about how to use replace to convert scrivener lists to markup - I may just use that until scrivener 3 comes out… wait - my interface doesn’t have a regex option. I’m on windows - is that the reason?