snippets FR: Markdown Snippets

[Chris Messina]

Given my recent discussion about formatting issues with RTF Snippets, it occurred to me that Markdown-formatted snippets could be really useful. 

 

There are some existing Markdown Workflows for Alfred like MarkdownTransform and Alfred Markdown Notes and so while I might attempt to create a Nested Snippets Workflow that allows storing snippets in Markdown and then passing them through a Markdown parser before pasting the results, being able to specify Markdown as another properly support snippet format in Alfred could be very handy.

[Chris Messina]

FWIW, SnippetsLab supports Markdown Snippets.

[vitor]

There’s another request for this (or something similar) somewhere on the forums. Thing is, Markdown is just plain text; that’s its whole value proposition. It exists as a simple way to create HTML, which is itself just plain text; it’s the browser that parses it into something different. That’s what SnippetsLab does, it parses the Markdown in its own app. Meaning the result is dependent on the application you paste to, not the one you paste from (i.e. Alfred cannot have control over it).

The closest we could get to a universal solution would be parsing the Markdown into RTF and then pasting that, which I do with MarkdownTransform. While a possibility, I will point out it’s rife with tradeoffs. The way I do it is by first transforming from Markdown to HTML and then the HTML to RTF, but the bigger issue is the disparity of features. There is a lot that Markdown supports that RTF doesn’t and some things RTF needs that Markdown doesn’t consider, so the question as to what to do in those cases would need to be fleshed out first.

 

Examples: RTF needs a defined font family. Seems easy enough to have an option for it. What do we do about colours? Seems reasonable to ignore those. But then what do we do regarding images and other unsupported things? Do we just strip them out from the snippet’s result¹? Seems unexpected, but then does Alfred need to warn you of whatever will be stripped before you save your snippet?

 

None of those is insurmountable, but it seems the new mode would amount to a plain text box with a Rich Text preview with missing features that removes some of your text. With that in mind, seems to me a superior solution would be to manually convert your Markdown text to Rich Text first then pasting that into Alfred. That way you already see what the result will be and can tweak it to add extra stuff.

You can already accomplish that via MarkdownTransform, right in the new snippet box: write it Markdown, select the text, press the shortcut. I’m open to suggestions regarding the output of my converter. It’s essentially CSS and nothing is set in stone.

 

---

 

1. That’s what I do in MarkdownTransform, but an opinionated Workflow as more flexibility of choice than a native feature baked into Alfred.

[Chris Messina]

59 minutes ago, vitor said:

The closest we could get to a universal solution would be parsing the Markdown into RTF and then pasting that, which I do with MarkdownTransform. While a possibility, I will point out it’s rife with tradeoffs. The way I do it is by first transforming from Markdown to HTML and then the HTML to RTF, but the bigger issue is the disparity of features. There is a lot that Markdown supports that RTF doesn’t and some things RTF needs that Markdown doesn’t consider, so the question as to what to do in those cases would need to be fleshed out first.

 

I hear you and agree that there are many trade-offs to consider. 

 

I didn't want to come in with a specific solution per se, but let me try a few observations:

• Maintaining snippets w/ placeholders in rich text can be a bit finicky, especially if you want to use a text editor or IDE to work w/ your content.
• Similarly, passing RTF formatted text back and forth between workflows or Snippet Triggers seems more complex than Markdown-formatted plaintext.
• Markdown-flavored plaintext is transparent and easier for me to work with given the snippets I use most often.
• I don't use more advanced Markdown features (like tables, LaTeX, or images) so am mostly looking for parity w/ the existing Alfred RTF tooling
• If images are to be used, they could be URL-encoded and embedded into the snippet directly (though not ideal)

The flow would be to run all the content substitutions in the plaintext content BEFORE the step of converting the Markdown to RTF, which would then be pasted into the target — same as what you do and this the approach I wanted to build on.

 

1 hour ago, vitor said:

seems to me a superior solution would be to manually convert your Markdown text to Rich Text first then pasting that into Alfred. That way you already see what the result will be and can tweak it to add extra stuff.

 

Yes, this is possible — perhaps unlike other folks (especially actual developers) I like to keep my content in or as close to the app I use it with or access it through as much as possible... In other words, if my Markdown content is external and I need to paste the RTF conversion into Alfred, that kind of defeats the productivity I'd hoped to gain by making my snippets easier to maintain in Markdown from within Alfred itself.

 

Perhaps a different way to have a go at this is instead to think about the best use cases for Markdown-formatted snippets and optimize for the 80% use cases before rejecting the idea because this method would break in 20% of use cases?

[vitor]

25 minutes ago, Chris Messina said:

I didn't want to come in with a specific solution per se

 

You should, though. Because someone will have to come up with it, and the more work you do beforehand to help, the likelier it is to happen. You’re a designer, coming up with how it should work given the constraints is your strong point.

 

27 minutes ago, Chris Messina said:

but let me try a few observations

 

I’m not disputing in the slightest that Markdown is easier to work with. I made a whole Workflow around it, after all. I’m trying to help you see the obstacles so we can surpass them.

 

3 minutes ago, Chris Messina said:

I don't use more advanced Markdown features

 

But other users do, and if Alfred were to commit to having this feature, those people (and their needs) would have to be taken into account as well.

 

4 minutes ago, Chris Messina said:

If images are to be used, they could be URL-encoded and embedded into the snippet directly (though not ideal)

 

Wouldn’t work. Base64-encoding the image wouldn’t make them show up in RTF.

 

When thinking about this feature, you have to forget Markdown and concentrate solely on RTF, because that would be the output format.

 

8 minutes ago, Chris Messina said:

that kind of defeats the productivity I'd hoped to gain by making my snippets easier to maintain in Markdown from within Alfred itself.

 

I understand that. Though note my suggestion works today, and what you’re asking for may never come. Anything is more productive than nothing, and the anything we have right now isn’t bad.

 

9 minutes ago, Chris Messina said:

Perhaps a different way to have a go at this is instead to think about the best use cases for Markdown-formatted snippets and optimize for the 80% use cases before rejecting the idea because this method would break in 20% of use cases?

 

I fleshed the idea at length, explained the manners in which it couldn’t work, came up with ways it could work, introduced questions that need to be resolved before implementation, suggested an interface for it, offered a workaround, and volunteered to take your input directly to improve what already exists and is within my power to change.

 

Sincerely, I have no clue how you take “rejecting the idea” from there. Everything in my post was in good faith and is about trying to make your idea a reality in any form.

 

I give up.

[deanishe]

48 minutes ago, vitor said:

But other users do, and if Alfred were to commit to having this feature, those people (and their needs) would have to be taken into account as well.

 

This. Your suggestions can be focussed very tightly on your own specific needs, @Chris Messina. The all-important question is how well or poorly a change or feature would work for all Alfred users. Vítor and I give your requests a bit of a hard time because we're measuring them against that bar.

 

1 hour ago, Chris Messina said:

Perhaps a different way to have a go at this is instead to think about the best use cases for Markdown-formatted snippets and optimize for the 80% use cases before rejecting the idea because this method would break in 20% of use cases?

 

But what leads you to think what you're suggesting is the 80%, especially when you're implicitly excluding everybody who'd rather use something other than Markdown from the get-go? Why aren't we talking about the ability to run snippets through any processor? The same end result as far as you're concerned, but also useful to people who don't want to do exactly the same thing as you.

 

1 hour ago, vitor said:

When thinking about this feature, you have to forget Markdown and concentrate solely on RTF, because that would be the output format.

 

You'd want to put HTML on the clipboard as well (or perhaps instead), imo. That's the "proper" representation of something like Markdown, and some apps (yeah … Firefox) accept pasted HTML, but not rich text.

 

I think the ability to put multiple arbitrary types of data on the clipboard is more interesting in general, tbh. Without even getting into anything semi-complex like rendering Markdown, the ability to put a URL or file:// URL (or even a file list) on the clipboard would be broadly useful. It's a pain to do in code.

 

[Chris Messina]

17 hours ago, vitor said:

Sincerely, I have no clue how you take “rejecting the idea” from there. Everything in my post was in good faith and is about trying to make your idea a reality in any form.

 

Apologies @vitor, I think we're mishearing each other again. I shouldn't have used a word like "rejected" when you were offering good-faith feedback. I retract that characterization.

 

 

17 hours ago, vitor said:

You should [come in with a specific solution per se], though. Because someone will have to come up with it, and the more work you do beforehand to help, the likelier it is to happen. You’re a designer, coming up with how it should work given the constraints is your strong point.

 

You're right. I need to spend more time fleshing out my particular needs to make this request more concrete. The origination was frustration with the formatting idiosyncrasies of RTF and wanting to be able to use something in between plaintext and RTF for my snippets, so I could find more reliability and transparency.

 

Since I've become more comfortable with Markdown, it seemed like a suitable answer. In my mind, I just seemed like if I could store my snippets in Markdown within Alfred and then choose whether Alfred converts the Markdown into HTML or RTF based on the targeted application, I'd have a solution that would meet my needs.

 

But I need to go deeper and develop test use cases to demonstrate why the current solution is insufficient to meet my needs.

 

 

12 hours ago, deanishe said:

Why aren't we talking about the ability to run snippets through any processor?

 

Actually, I appreciate that suggestion — but I'm also hyper sensitive to the tension between overfitting to my own needs (and thus reducing the value of my original proposal) and exploding scope such that the amount of work required to achieve the desired outcome would be unreasonable.

 

There's certainly leverage to be found in building a frameworks that benefits the many (i.e. an Alfred-native mechanism to enable any text processor for Snippets) vs building a one-off solution, especially if the pathway is more or less generalizable (i.e. if you can support processing via Markdown, you could also support HTML, LaTex, etc).

[deanishe]

17 hours ago, Chris Messina said:

the tension between overfitting to my own needs […] and exploding scope such that the amount of work required to achieve the desired outcome would be unreasonable

 

The difference in the amount of work isn't significant, imo. Andrew wouldn't include a 3rd-party (Markdown) library in Alfred without a lot of research and due diligence. The bring-your-own-processor model doesn't require any 3rd-party bits on Alfred's side.

 

The question marks are around its usability, imo, because it won't work out-of-the-box if it requires external processors.

[Chris Messina]

6 hours ago, deanishe said:

The question marks are around its usability, imo, because it won't work out-of-the-box if it requires external processors.

 

Hopefully this week I'll get to try something out with a Workflow and Snippet Triggers, which I haven't explored yet. I'm thinking maybe I can take parts of @vitor's MarkdownTransform and combine them with snippet substitutions to achieve dynamic, multi-variable insertion, while storing the snippet template in Markdown.

[deanishe]

Yeah, it's not so difficult to do already. Just somewhat finicky because you'd have to define the snippets in a workflow, not a snippet collection, plus there'd be a fair bit of machinery.

 

If I wanted to use Markdown (or whatever) in snippets today, what I'd probably do is write a workflow that you point at a directory of Markdown (or whatever) files with all snippety metadata defined in the frontmatter (or the filename is the snippet keyword), and it automatically creates the corresponding snippety gubbins in its own info.plist. (That's how Searchio! works.)

 

On the one hand, it's a bit ghetto vs the sort of built-in support we've been discussing. On the other hand, you would be able to manage your snippets in your editor of choice, rather than in Alfred's UI. Also, it's doable today.