Wrong syntax highlighting when one line contains a single * or _

[nanne007]

If one wants to write a * as a normal char, not as a bold or italic start char, things will go wrong.

Even,when there is no newline after the line contains the *

When the * is the last char of one line, everything is ok...

[maherbeg]

Looks like this is the same as #45

Closing my issue.

[zhuochun]

Same problem when there is a single _.

[bobrocke]

This appears to be fixed in v0.151. True?

[lee-dohm]

Nope ...

[Victorystick]

Another example of the broken syntax. The placement of * within the C code block affects the highlighting of the surrounding Markdown

Without space after *.

With space after *, highlighting works again. Both *s require spaces for the highlighting to work.

[mauricerkelly]

@Victorystick thanks for raising this - been bugging me for a while as well. Maybe it doesn’t bother people who write code in a bad C-style?

[phillipholmes]

I came across this issue when trying to use target='_blank' in html href tags given the default markdown url references do not specify 'open a new window/tab' for links.

To solve this specific issue (this is a bad hack imo!) I have modified the existing local gfm.json file on line 40 to use the following regex:

      "begin": "(?<=^|[^\\w\\d_\\{\\}])_(?!$|_|\\s|blank['\"])",

I was going to do the same and submit a pull request, but as the main repo is actually in cson and I'm still learning coffee (and don't have an easy way to test) I haven't submitted that and instead created an updated fork ( https://github.com/PhillipHolmes/language-gfm/commit/3f91d731347f902b5e04a4c0eae492ac1aeca7cd ). As the syntax is slightly different and I'm not sure if I have escaped the quote or doublequote correctly within coffeescript - the line number changed to 39 and I'm guessing should look like this:

    'begin': "(?<=^|[^\\w\\d_\\{\\}])_(?!$|_|\\s|blank[\'\"])',

I know this isn't what most people are after (personally I don't have to care about * as I don't have that issue in html links within markdown files!), but hopefully this leads the way for a more permanent fix that helps all of us...

[ryan-p-randall]

+1 for fixing this, even if only for the _ case at first.

I often write blog posts using Jekyll. If I put a {% include _toc.html %} at the top of a post the entire rest of the post becomes italic. Sadly, that mean this otherwise awesome package doesn't do much good unless I comment that line out with <!-- --> while editing. That's a reasonable workaround, but I'd love to not have to do it forever.

[juh2]

Yes, please fix this bug. It makes atom unusable for me.

[leipert]

Hey there. I am the maintainer of of language-pfm, a package for pandoc flavored markdown which shares a lot of code with this package.

I've spent a ridiculous amount of time trying to solve the bold / emphasis problematic for good.

The grammar can either recognize inline styling like this beauty
(?<!\\$)(\\$)([^$\\s][^$]+[^\\\\$\\s]|[^\\\\$\\s]+)(\\$)
or block styling with a start (\\${2}) and a end \\1.

The first way actually works really good and produces almost no errors.
The second one is problematic as you can see in these examples:

__bold__
__this
is
bold__
__actually
not

bold__

bold
this
is
bold
__actually
not

bold__

The problem is that you cannot tell the grammar parser that an block environment is not allowed to contain new lines. So at the moment I only see two solutions.

1. Easiest: Ignore multiline emphasized text. Only the first of my examples will actually work.
2. Uglier: Create a second rule that finds bad formatted multiline blocks which will get an additional css-class named "bad-formatted"
3. Best solution: Add possibility to atom to have constraints like that a newline should not be inside an block environment

Currently there is also a workaround I had not thought of, but was mentioned here:
leipert#5
OP should just insert <!-- markup clean* --> for now. (Replace the * with whatever emphasis you have your problem 👍

[elinx]

I meet the same problem in c code blocks and add espace charachter('') before each asterisk which is so ugly.

[kartsims]

No update on this issue... How can I help ?

[diesire]

Still broken in 1.16.0-beta0

The same for backticks

Not just applies bold/italic/inline style, it also breaks the headers

[orodbhen]

@kartsims's solution of switching to language-markdown fixes it for me.

[timedreamer]

I'm using {:target="_blank"} in my Markdown. The language-markdown works great if there is only one {:target="_blank"} in a line. However, if there are multiple, it still doesn't highlight correctly.

Atom version 1.20.1 x64 Windows 10
Language-mardown version 0.25.1

Any ideas?

[vsemozhetbyt]

This also affects GitHub diffs. For example, the _ character in the link URL here causes all the rest code to be italic.

[Juni0rF]

Related, I've found that if I leave a space after the underscore in target="_ blank" for example, this retains the correct syntax highlighting in markdown and has the intended outcome of opening a link in a new window.

[jpasholk]

@Juni0rF's solution fixed this for me. I was having the same exact bug with target="_ blank".

Cheers!

[mercmobily]

Sorry but that's hardly a solution...

…

On Fri, 20 Apr. 2018, 11:18 pm jpasholk, ***@***.***> wrote: @Juni0rF <https://github.com/Juni0rF>'s solution fixed this for me. I was having the same exact bug with target="_ blank". Cheers! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#44 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACB7XuyCVjtZ1d-GIxcYQ6fljcmUP5j9ks5tqfxOgaJpZM4Catzc> .

[mischah]

This issue makes Atom pretty unusable to write markdown 😢

[bertday]

I'm having the same issue. Would love to see this get fixed!

[merlinstardust]

Just came across this issue as well when I add a link with _blank. Very frustrating.

[steveroot]

I came across the same problem using Atom as IDE and Jekyll with markdown and Kramdown.
I wondered if i could create my own simple helper so instead of calling [link](url){:target="_blank"} I could call [link](url){:targetblank} or some such construction.

Unfortunately I've ran out of time to read and learn and solve, but in case it helps anyone i did discover that I could replace the underscore with the html code for underscore and (so far as I've tested) it renders perfectly in the final html and I no longer have the purple italics (I had the same view as @mischah 's example)

{:target="_blank"} instead of {:target="_blank"}

[PDunham113]

Not to add fuel to the fire, but:

Putting s**o**me emphasis on **l**etters *i*n wor**d**s breaks ***everything***

Putting some emphasis on letters in words breaks everything

(This is kind of a terrible thing to do with Markdown anyways but it's still frustrating)

[nihalgonsalves]

I found a similar issue, probably related:

Code to reproduce:

If I put a single bracket in a shell code block,

```sh
(
```

the following text is still treated as code.

[fschrempf]

I just switched to language-markdown package that is intended to be a replacement for the "core" language-gfm.

One of the most useful comments here (by @kartsims) has been marked "off-topic". 😕

[lucasfalcao3d]

I just switched to language-markdown package that is intended to be a replacement for the "core" language-gfm.

This fixed the issue I was having with {:target="_blank"}, making all text italic before the target.