Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The thing with the tab replacement by four spaces #508

Closed
Nerdmind opened this issue May 31, 2017 · 3 comments
Closed

The thing with the tab replacement by four spaces #508

Nerdmind opened this issue May 31, 2017 · 3 comments
Labels
Projects
Milestone

Comments

@Nerdmind
Copy link

Nerdmind commented May 31, 2017

Hello. I would also (#363) find it good if tabulators remain tabluators. Especially for the indentation of code one has actually only to use tabulators (everything else is semantically wrong and inflexible). What would happen if I defined in CSS that a tab should be displayed in the HTML pre-tags like 12 spaces (tab-size: 12;)? This does not work because the CSS does not find any tabulators, but only four hard blanks. If the user places a tab anywhere within its text or source code, the tab should always remain a tab. Especially within HTML pre-tags where I may post my source code which is semantically correct indent with tabs! If the markdown parser replaces my tabs, the code isn't anymore THE code I've inserted.

If this is my original code which I want to put into my markdown (tab indentation) …

class Foobar {
	protected $propertyA = 1;
	protected $propertyB = 2;
}

… Parsedown will make this, which is not my code anymore:

class Foobar {
    protected $propertyA = 1;
    protected $propertyB = 2;
}

If you compare the two code examples, you'll see that GitHub also retains the tab indentation in the first example and uses a width like 8 spaces for displaying them (8 is the default width in HTML pre-tags for tabs). And this is EXACTLY the same code I entered in the issue editor. The second example is not my code because tabs were replaced by spaces. This is inflexible if someone would copy the code into his IDE in which he uses, for example, a width like 15 spaces for displaying tabs.

Shortly: Tabulators should remain tabulators. :)

@Nerdmind
Copy link
Author

Nerdmind commented May 31, 2017

In the meantime, I've hacked the library to keep tabulators present in the output and it seems to work fine. I'd to change code inside 3 methods: lines, blockCode and blockCodeContinue. In the line method, I've completely removed the if condition which checks for tabulators and deletes them.

Within the last two methods, I've modified the if conditions to check both against four spaces and a tabulator. The patch is for the release version 1.6.2:

Patch: parsedown-keep-tabs-1.6.2.patch.zip

Nerdmind added a commit to Nerdmind/Blog that referenced this issue Nov 4, 2017
…om being converted to spaces:

For example, if you had used the markdown syntax for displaying source code in your post, Parsedown had replaced your semantically correct tab indentations with hard spaces. This behavior meant that the code that was displayed after parsing was no longer exactly the code you inserted into the content editor. If someone had copied source code from your post into his IDE, then your tab indentations were gone because of the spaces.

That's why I hacked the Parsedown library and created a patch:
erusev/parsedown#508
@petk
Copy link

petk commented Dec 29, 2017

Hello, this would be a very useful addition. Usually I don't like tabs anywhere but Makefile, for example, by default requires to have tabs... And having a Makefile code in Markdown makes the HTML parsed code nonfunctional. For tutorials etc :)

@aidantwoods
Copy link
Collaborator

I know it's a while later, but this should be fixed in the 2.0.x branch, which goes to quite a bit of effort to track not only tabs, but correct indentation offsets through sub-parsing of blocks :)

Screenshot 2019-04-07 at 16 12 54

@aidantwoods aidantwoods added this to the 2.0.0 milestone Apr 7, 2019
@aidantwoods aidantwoods added this to To do in 2.0.0 via automation Apr 8, 2019
@aidantwoods aidantwoods moved this from To do to Done in 2.0.0 Apr 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
2.0.0
  
Done
Development

No branches or pull requests

3 participants