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

Inline code followed by emphasis consumes extra whitespace #957

Open
adigitoleo opened this issue May 12, 2022 · 3 comments
Open

Inline code followed by emphasis consumes extra whitespace #957

adigitoleo opened this issue May 12, 2022 · 3 comments
Labels
wontfix This will not be worked on xranklin-done

Comments

@adigitoleo
Copy link

I'm observing a probably unintended behaviour that inline code followed by either italic or bold emphasis consumes one additional trailing space character:

Something like `this` _will_ be missing a space.

Something like `this` *will* be missing a space.

Something like `this` **will** be missing a space.

I'm on [713c75ef] Franklin v0.10.72 with Julia:

Julia Version 1.7.2
Commit bf53498635 (2022-02-06 15:21 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-12.0.1 (ORCJIT, skylake)

Let me know if you can trivially reproduce it otherwise I'll send a more complete example.

@tlienart
Copy link
Owner

tlienart commented May 12, 2022

Ah that's very useful thanks. It shouldn't be hard to fix, I'll have a look soon

dev note: this is fix_inserts not playing nice

@tlienart
Copy link
Owner

tlienart commented May 12, 2022

ok so actually this is not easy to fix without risking breaking some other stuff. However this is not an issue in the upcoming version of Franklin:

> using Xranklin
> html("abc `def` *ghi* `jkl` _mno_")
"<p>abc <code>def</code> <em>ghi</em> <code>jkl</code> <em>mno</em></p>\n"

source of the problem + why it's hard to fix

The current version of Franklin (and all previous versions) wrap around Base.Markdown and does all sorts of (hacky) things to inject content in various places. At a high level Franklin does the following when processing markdown:

  • find Franklin-specific parts of the markdown
  • form an intermediate markdown where the Franklin specific stuff has been replaced with something like "INJECTSOMETHINGHERE"
  • convert the intermediate markdown to HTML using Base.Markdown
  • replace all the "INJECT...HERE" with the relevant stuff

Now for reasons that are a bit annoying to get into, this injection adds spaces around itself. But this can cause issues with nesting with proper markdown, you might end up with:

foo _ INSERTSOMETHINGHERE _ ... 

but that won't work because _ xxx _ is not valid Markdown (won't be recognised as italic because of the space). The fix_inserts function adjusts this by looking for insert tokens followed or preceded by * or _ and removes the whitespace so that you do end up with

foo _INSERTSOMETHINGHERE_

you found a corner case: code stuff gets handled specifically by Franklin, so gets replaced by the insert token, if immediately followed by _ or * then that whitespace gets removed as per explanation above.

We could add some more logic to fix this further but in the next version of Franklin the whole parsing is done by us (we don't use Base.Markdown anymore) and so this "intermediate markdown" stuff doesn't happen. Given that it'll be brought in fairly soon, I think it's reasonable to leave things as is.

What to do with this problem and Franklin 0.10.x

double the space between the inline code and the italic/bold, browsers won't render double whitespaces.

@tlienart tlienart added wontfix This will not be worked on xranklin-done labels May 12, 2022
@adigitoleo
Copy link
Author

Understood, and the double whitespace is an easy workaround. I agree that it's not worth changing if the markdown parser is going to be replaced.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on xranklin-done
Projects
None yet
Development

No branches or pull requests

2 participants