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 https://github.com/atom/language-gfm/issues/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? :trollface:

[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/language-pfm#5 OP should just insert <!-- markup clean* --> for now. (Replace the * with whatever emphasis you have your problem :+1:

[sampsyo]

Independent of runaway italicization, it seems like the grammar should disable all normal Markdown syntax inside of code blocks. (That's what leads to the nasty business in C code listings that use stars.) Should that be considered a separate issue?

[nycdotnet]

it seems like the grammar should disable all normal Markdown syntax inside of code blocks

That makes sense to me.

[jgopel]

I'm encountering this issue with pointers in C++ and I agree with @sampsyo that normal markdown syntax should not apply to code, either inline or in blocks.

[ralyodio]

https://www.dropbox.com/s/8bvox1c3vgmkvdn/Screenshot%202015-08-29%2013.43.06.png?dl=0

If my markdown code block contains *.log the rest of the markdown file formatting is messed up.

[MadLittleMods]

:+1: Running into single *

[z3ntu]

Any update? I have the same problem as #126

[bobrocke]

@z3ntu I've had pretty good luck with an alternate Markdown language package - https://github.com/burodepeper/language-markdown

Give that a try?

[z3ntu]

@bobrocke Thanks, it looks much better! I hope normal Atom will display it correctly soon!

[mercmobily]

@bobrocke @z3ntu I can also confirm that the endless problems I was afflicted by went away once I installed https://github.com/burodepeper/language-markdown

[ilg-ul]

in the attached picture here it is another example of broken behaviour.

initially I reported this to the wrong repo (https://github.com/atom/atom/issues/12166).

I'm not sure it is the same problem as originally reported, but it is related.

the problem seems to be the same as reported by @Victorystick

any solution?

[Alhadis]

There's only one possible fix for this, but it would mean this is no longer possible:

Regular *ItalicItalicItalic
ItalicItalicItalic* Regular

When TextMate/first-mate highlights a document, it operates on one line at a time. It has no way of knowing what's on the next or previous line. The best thing we can do is add a lookahead to assert that further along the line, there's a matching character that closes the formatting.

Personally, I'd take this...

... over this:

Thoughts? :)

[brainscript]

@Alhadis

I think inside

code sections

the (markdown) syntax highlighting should be either disabled ... ... or replaced by the syntax highlighting of the specified language, in your example "C".

[ilg-ul]

replaced by the syntax highlighting of the specified language

+1

replaced, if possible, disabled otherwise.

[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 ?

[kartsims]

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

[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, notifications@github.com 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 https://github.com/atom/language-gfm/issues/44#issuecomment-383130075, 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)

[krestenlaust]

How is this still an problem in 2018

[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". :confused:

[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.