{{ message }}

# Escape character (\) is rendered when it shouldn't be#759

Open
opened this issue Oct 31, 2013 · 8 comments
Open

# Escape character (\) is rendered when it shouldn't be#759

opened this issue Oct 31, 2013 · 8 comments
Milestone

### ge0ffrey commented Oct 31, 2013

 In my socialMedia.adoc, I had this peice of code * image:../headerFooter/googlePlusLogo.png[] https://plus.google.com/\+OptaPlannerOrg[OptaPlanner on Google\+] * image:../headerFooter/twitterLogo.png[] https://twitter.com/optaplanner[OptaPlanner on Twitter] (Google\+ mirror)  But it got rendered like this: ... on Google+ .... Google\+ mirror but I am expecting: ... on Google+ .... Google+ mirror gem 'asciidoctor', '>= 0.1.4' The text was updated successfully, but these errors were encountered:

### mojavelinux commented Oct 31, 2013

 I'll look into it. However, this is definitely a case where it would be much safer to use the attribute for +. OptaPlanner on Google{plus} 

### mojavelinux commented Oct 31, 2013

 As it turns out, this is consistent with how AsciiDoc works. Thus, it's unexpected behavior in the spec as opposed to the implementation. You shouldn't need to escape the last plus anyway. This works fine: * https://plus.google.com/\+OptaPlannerOrg[OptaPlanner on Google+] * https://twitter.com/optaplanner[OptaPlanner on Twitter] (Google+ mirror) 

### mojavelinux commented Oct 31, 2013

 I'll definitely add this as a test case so that we can track it no matter what the outcome is.

### ge0ffrey commented Oct 31, 2013

 How would I render "Google+ on Google+" without resorting to {plus}? The implementation should adjust to the spec, not vica versa :) AsciiDoc and AsciiDoctor should both be fixed.

### ge0ffrey commented Oct 31, 2013

 And how would I render OptaPlanner on Google+?

### mojavelinux commented Nov 24, 2013

 The implementation should adjust to the spec, not vica versa :) AsciiDoc and AsciiDoctor should both be fixed. There is no spec...yet. The main issue with the constrained formatting in AsciiDoc is that it isn't constrained enough. I'd like to move towards rules that require constrained formatting (like *, _ and +) to be at the boundaries of a word character, with some exceptions of trailing punctuation. This should make them less greedy for things like this. Having said that, Google is still a chump for selecting the + character, which is already loaded with meaning in IT.

mentioned this issue Feb 17, 2014

### ge0ffrey commented Feb 17, 2014

 Thanks for the comments. I disagree with the last comment "google is a chump for selecting the + char", because a lower level text (such as a link) which is properly escaped for a higher level text (such as adoc) should never disrupt the higher level text (such as adoc). Similarly, adoc text written in an SQL statement's field, properly SQL escaped, should not disrupt the SQL statement. Or a freemarker template noting an SQL statement, which in turn notes an adoc statement which in turn notes a google plus link, should not be disrupted anywhere :) But the plus might be escaped up in level 2, 3 & 4 (and it's level 2 escapes might be escaped too in level 3 & 4).

### ge0ffrey commented Feb 17, 2014

 An example to clarify: Suppose I have this windows file: fooooo\baaar.txt  Now let's generalize that in a regular expression fo*\\ba*r\.txt  Now let's use that regex in java: myString.replaceAll("fo*\\\\ba*r\\.txt", "foo\\bar.txt");  And then describe that java statement in a manual in adoc: myString.replaceAll("fo\*\\\\\\\\ba\*r\\\\.txt", "foo\\\\bar.txt");  We now have 17 backslashes, but no disruption. It does feel like the movie Inception! :)

added this to the discussion milestone Jul 16, 2014
mentioned this issue Feb 24, 2017
mentioned this issue Oct 22, 2017
Labels
None yet
Projects
None yet

Successfully merging a pull request may close this issue.

None yet
2 participants