-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Markdown autoformat italics bug #2388
Comments
I think that GitHub disabled The important thing here would be to not filter out too many scenarios because it may be confusing why autoformatting doesn't work in some cases then. |
I stuck by this underscore-autofomat issue too
I think there is no need for filtering since markdown syntax already has BACKSLASH ESCAPES to escape those auto-format characters( |
Hi guys, |
Hey all, we are running into this issue as well and I just wanted to check to see if there are any updates with this issue? Thanks! |
This works better in GitHub Writer. I think we could make this regexp narrower. |
I checked other Markdown implementations (technical details at the end) and decided to do as below:
Most of the above are based on CommonMark spec. Some key elements of that spec:
|
What about what's after the closing delimiter?
It's a less severe case than the one with
👍
This is a nice catch. It always bothered me that it does not work in our implementation of autoformat. If you could check quickly how big that change would be, that'd help us planning this change for the future. |
Good point. Another reason to treat whitespace as a separator. Also, in the example below, you can see better why punctuation characters should join whitespace as a separator for autoformat:
|
Regarding this, autoformat seems to grab text from the current line, up to the cursor. Without seeing what is after the cursor we cannot solve the problem of stopping the formatting inside the longer word. This also explains why reversed autoformatting cannot work right now. The first idea that comes to mind is to grab the entire text line, then check what is after the cursor. If we can find a matching delimiter, followed by whitespace or punctuation, that's great - let's format that, otherwise stop. Looking ahead only up to the end of the line should stop autoformatting from getting too excited about formatting what's further down in the text :) |
Two things I noticed already:
|
At the moment, we expect to have space preceding the opening delimiter ( Achieving reverted autoformatting starts pretty easy, but, in connection with undo, gets complicated quite fast. To properly format a reverted case, we have to look ahead of the cursor, possibly up to the end of the line. This breaks undo and makes undone autoformatting format again. We could look ahead and behind the cursor up to a certain point, e.g. first opened/closed delimiter, but the implementation of that becomes too complex for the scope of this bug. |
Fix (autoformat): Formatting will not be applied to `snake_case_scenarios` anymore. Closes #2388.
Hello all, is there so any final solution to fix this italic issue with ckeditor5? |
Hello, I have the same issue in the project is there any solution for the same? |
@Echecivuole and @aniketdeotale the issue is already fixed. Please update your CKEditor package. |
Hi thanks! Sorry I would need your help on from where and how update my CKEditor package. I have folder in my vendor locale. thanks! |
The issue still persist for me even after updating the ckeditor to latest version . Please verify once. |
Hi! There is another problem. something But on the client side this text looks like: som_eth_ing It is happenning because in the part of the word it expects only asterisk symbols |
Sorry if this was fixed in
latest
or not, but I wanted to make to discuss this.From a user:
STEPS TO REPRODUCE
EXPECTED RESULTS
ACTUAL RESULTS
Ref: mozilla/notes#595
I wonder if auto-format should only format if there are spaces around
_
or if it starts the line?The text was updated successfully, but these errors were encountered: