html -> markdown -> html

[fredcallaway]

I wanted to use this plugin to write emails with sublime text. But when I activate GhostText within a gmail compose box, I get html in Sublime, and I don't want to write my emails in html.

Would it be feasible to integrate GhostText with pandoc? Necessary additions would be

• new setting "use_pandoc" defaults to false
• detect if source is html
• add pandoc -f html -t markdown filter between chrome and sublime
• add pandoc -f markdown -t html filter between sublime and chrome

pandoc is very fast, so I don't think speed is a major concern here. If you're interested in this addition, I can implement it and make a pull request. (If you can tell me where the filters should go, that would be very helpful)

[Cacodaimon]

It might be possible, but I would try to build a more general way with custom filters.

But I would need some time finding a way implementing custom filters.

[fregante]

We might want to keep this in the browser part so it can be easily shared.

Edit: maybe not for size reasons

[gruns]

Any progress on this front? Or best practices to use GhostText to compose emails in Gmail?

[gruns]

Bump -- Gmail compose windows remain ungainly HTML. Any progress on this front?

[subnut]

Select Plain text mode in gmail. Problem solved!

https://useplaintext.email/#gmail-web

[albert-ying]

Select Plain text mode in gmail. Problem solved!

https://useplaintext.email/#gmail-web

@subnut Hmmm, I tried to set my Gmail to plain text mode. The decorative elements are removed. However, it still sorts of HTML formatted and requires the <div> tag to start a new line.

[luisherranz]

I have started playing with this in my site-transformations branch in case anyone else wants to try.

https://github.com/fregante/GhostText/compare/main...luisherranz:site-transformations

For the HTML<->Markdown transformation I'm using unified (remark/rehype).

The goal is not to get only HTML<->markdown but also a way to do other replacements, because sites that use HTML don't play 100% well with the plain markdown converters. For example, the markdown quote (> Text) is not being transformed to the Gmail HTML quote, which means that we also need to do some replacement with RegExp.

Even sites that use Markdown, like Slack (with markdown turned on), need other replacements, like for example turning Slack's bold text (*bold*) into markdown bold text (**bold**) and vice-versa.

Finally, this type of site transformations/integrations, if ever accepted by @fregante, probably need either:

• Some kind of code-splitting (probably using dynamic import()'s) so the required for a site is only loaded when loading that site.
• A user interface to configure RegExp replacements and activate HTML<->Markdown conversion per site, so hardcoded site transformations are not needed.

Anyway, it's too soon for that, for now, I'm just going to explore what type of transformations are needed for the different sites. If anyone else wants to work on this, please send a PR with your transformations/replacements in my fork, with site-transformations as the base branch.

[fregante]

You raise good points, this transformation is going to be lossy and likely a complex feature:

• when a contentEditable field is selected, the user should be asked:
  • HTML
  • plain text (flatten to .innerText)
  • markdown
• even before sending, the original content will be irrevocably lost if the user picks txt or md
• we probably don't want to support anything but Markdown, this already requires a large library and substantial effort to implement, let alone if we were to offer custom replacements with options. Definitely no to that part.