# Thunderbird and ML mode - peculiar indentation
**URL:** https://meta.discourse.org/t/thunderbird-and-ml-mode-peculiar-indentation/86782
**Category:** Support
**Created:** [5월 4, 2018, 7:22오후 UTC](https://meta.discourse.org/t/thunderbird-and-ml-mode-peculiar-indentation/86782 "2018-05-04T19:22:26Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@desrocchi](https://meta.discourse.org/u/desrocchi)
#### Post date: [5월 4, 2018, 7:22오후 UTC](https://meta.discourse.org/t/thunderbird-and-ml-mode-peculiar-indentation/86782/1 "2018-05-04T19:22:26Z")
Hi,
it seems like some of our users who prefer accessing through the ML interface using Thunderbid have this peculiar issue that at the beginning of the paragraphs an indentation of 5 or 6 blank spaces are added.
This would not be a problem if not that Discourse interprets those blank spaces as an “inline code” markdown.
```
This is what happens
```
I suspect that this is a Thunderbird problem but maybe there’s some knowledge to be gained here too 😛
So, can anyone give any suggestion about this problem: either removing the indentation from Thunderbird or the markdown coding from Discourse?
---
### Author:  [@desrocchi](https://meta.discourse.org/u/desrocchi)
#### Post date: [5월 4, 2018, 8:01오후 UTC](https://meta.discourse.org/t/thunderbird-and-ml-mode-peculiar-indentation/86782/2 "2018-05-04T20:01:09Z")
For the moment I solved selecting the whole mssage with Ctrl + A and deleting it all with Del.
At this point, whatever I write is considered body of the message and won’t be added any formatting at the moment of sending.
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [5월 4, 2018, 11:57오후 UTC](https://meta.discourse.org/t/thunderbird-and-ml-mode-peculiar-indentation/86782/3 "2018-05-04T23:57:01Z")
Could you send a couple of these emails to [regis.hanol@discourse.org](mailto:regis.hanol@discourse.org)?
---
### Author:  [@desrocchi](https://meta.discourse.org/u/desrocchi)
#### Post date: [5월 5, 2018, 12:59오전 UTC](https://meta.discourse.org/t/thunderbird-and-ml-mode-peculiar-indentation/86782/4 "2018-05-05T00:59:22Z")
Let me see if it happens by answering your message through Thunderbird.
```
Long sentence 1 Long sentence 1 Long sentence 1 Long sentence 1 Long sentence 1 Long sentence 1 Long sentence 1 Long sentence 1 Long sentence 1 Long sentence 1 Long sentence 1 Long sentence 1 Long sentence 1 Long sentence 1 Long sentence 1 Long sentence 1 Long sentence 1 Long sentence 1 Long sentence 1 Long sentence 1 Long sentence 1
Long sentence 2 Long sentence 2 Long sentence 2 Long sentence 2 Long sentence 2 Long sentence 2 Long sentence 2 Long sentence 2 Long sentence 2 Long sentence 2 Long sentence 2 Long sentence 2 Long sentence 2 Long sentence 2
Long sentence 3 Long sentence 3 Long sentence 3 Long sentence 3 Long sentence 3 Long sentence 3 Long sentence 3 Long sentence 3 Long sentence 3 Long sentence 3 Long sentence 3 Long sentence 3 Long sentence 3 Long sentence 3 Long sentence 3 Long sentence 3 Long sentence 3
```
---
### Author:  [@desrocchi](https://meta.discourse.org/u/desrocchi)
#### Post date: [5월 5, 2018, 1:02오전 UTC](https://meta.discourse.org/t/thunderbird-and-ml-mode-peculiar-indentation/86782/5 "2018-05-05T01:02:40Z")
Seems it happens here too.
A detail I forgot to mention: the line must be longer than 80 characters (it needs to go to a new line) for the indentation to be added.
I will send you the e-mail directly, but the issue does not seem to appear in that case, only when answering to Discourse.
I don’t know if it’s because the other e-mail services get rid of the indentation or because it’s actually added by discourse.
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [4월 29, 2020, 3:32오후 UTC](https://meta.discourse.org/t/thunderbird-and-ml-mode-peculiar-indentation/86782/7 "2020-04-29T15:32:58Z")
지연해서 죄송합니다…
이 PR이 병합되면 수정됩니다 👌
>
>
> TLDR; this commit vastly improves how whitespaces are handled when converting fr…om HTML to Markdown.
> It also adds support for converting HTML \`\\` to markdown tables.
>
> \---
>
> The previous \`remove\_whitespaces!\` method was traversing the whole HTML tree and used a heuristic to remove
> leading and trailing whitespaces whenever it was appropriate (ie. mostly before and after HTML block elements)
>
> It was a good idea, but it was very limited and leaded to bad conversion when the html had leading whitespaces on several lines for example.
> One such example can be found \[here\](https://meta.discourse.org/t/86782).
>
> For various reasons, most of the whitespaces in a HTML file is ignored when the page is being displayed in a browser.
> The rules that the browsers follow are the \[CSS' White Space Processing Rules\](https://www.w3.org/TR/css-text-3/#white-space-rules).
> They can be quite complicated when you take into account RTL languages and other various tidbits but they boils down to the following:
>
> \- Collapse whitespaces down to one space (0x20) inside an inline context (ie. nodes/tags that are being displaying on the same line)
> \- Remove any leading/trailing whitespaces inside an inline context
>
> One quick & dirty way of getting this 90% solved would be to do \`HTML.gsub!(/\[\[:space:\]\]+/, " ")\`.
> We would also need to hoist \`\\` elements in order to not mess with their whitespaces.
> Unfortunately, this solution let some whitespaces creep around HTML tags which leads to more \`.strip!\` calls than I can bear.
>
> I decided to "\_emulate\_" the browser's handling of whitespaces and came up with a solution in 4 parts
>
> \#### 1. \`remove\_not\_allowed!\`
>
> The HtmlToMarkdown library is recursively "visiting" all the nodes in the HTML in order to convert them to Markdown.
> All the nodes that aren't handled by the library (eg. \`\\`, \`\\` or any non-textual HTML tags) are "swallowed".
> In order to reduce the number of nodes visited, the method \`remove\_not\_allowed!\` will automatically delete all the nodes
> that have no "visitor" (eg. a \`visit\_\\` method) defined.
>
> \#### 2. \`remove\_hidden!\`
>
> Similar purpose as the previous method (eg. reducing number of nodes visited), there's no point trying to convert something that is hidden.
> The \`remove\_hidden!\` method removes any nodes that was hidden using the "hidden" HTML attribute, some CSS or with a width or height equal to 0.
>
> \#### 3. \`hoist\_line\_breaks!\`
>
> The \`hoist\_line\_breaks!\` method is there to handle \`\\` tags. I know those tiny \`\\` don't do much but they can be quite annoying.
> The \`\\` tags are inline elements but they visually work like a block element (ie. they create a new line).
> If you have the following HTML "\`\Foo\Bar\\`", it ends up visually similar to "\`\Foo\\\Bar\\`".
> The latter being much more easy to process than the former, so that's what this method is doing.
> The \`hoist\_line\_breaks\` will hoist \`\\` tags out of inline tags until their parent is a block element.
>
> \#### 4. \`remove\_whitespaces!\`
>
> The \`remove\_whitespaces!\` is where all the whitespace removal is happening. It's broken down into 4 methods as well
>
> \- \`remove\_whitespaces!\`
> \- \`is\_inline?\`
> \- \`collapse\_spaces!\`
> \- \`remove\_trailing\_space!\`
>
> The \`remove\_whitespace!\` method is recursively walking the HTML tree (skipping \`\\` tags).
> If a node has any children, they will be chunked into groups of inline elements vs block elements.
> For each chunks of inline elements, it will call the \`collapse\_space!\` and \`remove\_trailing\_space!\` methods.
> For each chunks of block elements, it will call \`remote\_whitespace!\` to keep walking the HTML tree recursively.
>
> The \`is\_inline?\` method determines whether a node is part of a inline context.
> A node is inline iif it's a text node or it's an inline tag, but not \`\\`, and all its children are also inline.
>
> The \`collapse\_spaces!\` method will collapse any kind of (white) space into a single space (" ") character, even across tags.
> For example, if we have "\` Foo \\n\ Bar \\\t42\`", it will return "\`Foo \Bar \42\`".
>
> Finally, the \`remove\_trailing\_space!\` method is there to remove any trailing space that might creep in at the end of the inline chunk.
>
> This solution is not 100% bullet-proof.
> It does not support RTL languages at all and has some caveats that I felt were not worth the work to get properly fixed.
>
> \---
>
> FIX: switched Nokogiri to Nokogumbo for better HTML5 parsing
> FIX: better detection of hidden elements when converting HTML to Markdown
> FIX: take into account the \`allowed\_href\_schemes\` site setting when converting HTML \`\\` to Markdown
> FIX: added support for 'mailto:' scheme when converting \`\\` from HTML to Markdown
> FIX: added support for \`\\` dimensions when converting from HTML to Markdown
> FIX: added support for \`\\`, \`\\` and \`\\` when converting from HTML to Markdown
> FIX: added support for multilines emphases, strongs and strikes when converting from HTML to Markdown
> FIX: added support for \`\\` when converting from HTML to Markdown
> DEV: remove unused 'sanitize' gem
>
> Wow, did you just read all that?! Congratz, here's a cookie: 🍪.
---
### Author:  [@desrocchi](https://meta.discourse.org/u/desrocchi)
#### Post date: [4월 29, 2020, 4:06오후 UTC](https://meta.discourse.org/t/thunderbird-and-ml-mode-peculiar-indentation/86782/8 "2020-04-29T16:06:49Z")
늦어도 나으니까 🙂
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [4월 30, 2020, 10:22오전 UTC](https://meta.discourse.org/t/thunderbird-and-ml-mode-peculiar-indentation/86782/9 "2020-04-30T10:22:23Z")