Remove/trim/delete extra trailing spaces

Use case or problem

This is such a standard editor feature that I am amazed that:

  1. it was not implemented yet
  2. (based on a search) I am the first one to request this feature/fix.

There is a lot of reasons why trailing spaces should be removed, be it in a programming context (I do use Obsidian to document code and I use git to sync the changes) or just in a general writing context. Here is one of the discussions:

Proposed solution

Start deleting extra trailing spaces at the end of the lines. I don’t know why would anybody need those extra spaces, thus I can’t think of a reason to have a setting toggle to disable trimming.

Current workaround (optional)

This plugin GitHub - Benature/obsidian-text-format: Format seleted text in allows the trimming of extra spaces except that:

  1. it trims all the extra spaces, not only the trailing ones. Sometimes this is not what is needed.
  2. it is not automatic; it requires the selection of the text and manual application of the plugin.

Related feature requests (optional)

1 Like

Please don’t, because two trailing spaces mean something in Markdown!

1 Like

But what exactly does it do? Are you personally using it? Could you please explain how?

I have read the guide, but I am still unsure what this feature (double-space + Enter) is supposed to do that the ordinary Enter doesn’t already.

Here is how the trailing spaces are currently treated in Obsidian and Typora:

So they don’t even do anything…

Or does it mean that both Obsidian and Typora have a bug and are not treating the trailing spaces like the Markdown standard instructs? That would speak loudly about the badness and unusefulness of this trailing space specification; the fact that nobody misses this feature enough to report and fix it.

Which is a good thing - it means that nothing stops Obsidian developers from taking the practical approach and implementing the common trimming feature.

There are different format standards/specifications, most of them having some sort of weaknesses. Markdown is no different. It is a good standard, but also has problems of its own - this double trailing space is clearly one of the design-choices-that-shouldn’t-have-happened. If anything, it sounds like a purposefully badly designed thing, a homage to the Whitespace programming language. This is terrible.

After extensive researching, I found out that:

  1. Most people agree that this is a bad/unnecessary specification
  2. The trailing space syntax is not commonly used
  3. Different software are not supporting it or are trimming the trailing spaces by default. Including the VSCode and JetBrains editors. And basically nobody minds.
  4. The whole “trailing spaces” thing in Markdown is badly specified and implemented. For example the official implementation of Markdown strips leading and trailing whitespace in code spans and people are fine with it.
  5. The biggest effort to unite the Markdown standard CommonMark (a standard, unambiguous syntax specification for Markdown) tells not to use the trailing spaces.
  6. The original description does not specify the syntax unambiguously and there have been many different implementations of Markdown. So it’s ok to make changes to Markdown to fit the unique situation (e.g. Github flavored Markdown, or the practical approach the Obsidian developers took so far - to generally embrace the Markdown, but with their own additions/removal/changes when necessary; officially removing support for the unnecessary trailing spaces syntax should be one of those).

Just ran into this problem today, where my frontmatter wouldn’t parse, causing Live Preview to fail, because I had trailing whitespaces after my closing ---.

We’re not talking about leading whitespaces here, e.g., Python where indentation denotes lexical scoping.

From a usability standpoint, it is evil to be cut by invisible wounds.

1 Like