mfm.js icon indicating copy to clipboard operation
mfm.js copied to clipboard

Italic text is not recognized when "/" is present inside

Open outloudvi opened this issue 3 years ago • 11 comments

  • Normal case: *a*
[{"type":"italic","children":[{"type":"text","props":{"text":"a"}}]}]
  • Problematic case: *a/n*
[{"type":"text","props":{"text":"*a/n*"}}]
  • Expected: *a/n*
[{"type":"italic","children":[{"type":"text","props":{"text":"a/n"}}]}]

outloudvi avatar Mar 17 '22 12:03 outloudvi

仕様通りの動作です。これはバグではありません。 もしこの動作を変更する場合は、その変更内容を検討してMFM自体の仕様を変更することになります。

marihachi avatar Mar 17 '22 15:03 marihachi

I think it would be okay if it is - as you said - per the MFM spec (please correct me if I had it wrong since I don't know much about Japanese). Also, I can wrap italic text with <i> which will not suffer from this problem.

I just feel it a little weird because it does not affect the bold notation:

// *a/b*
[{"type":"text","props":{"text":"*a/b*"}}]
// **a/b**
[{"type":"bold","children":[{"type":"text","props":{"text":"a/b"}}]}]

outloudvi avatar Mar 17 '22 16:03 outloudvi

I agree that the current behaviour is very unexpected (and might thus be considered a bug). I personally consider the current behaviour for **bold** to be correct, so I think we should make the characters allowed inside *italic* the same as allowed in <i>italic</i>. (But *italic* should still require white space around it to be recognized.) Alternatively, we could remove the star-italic all together but that is not a good idea for backward compatibility.

(I did not quite understand; is the MFM specification somewhere else? Where would it have to be changed, since you said that "MFM itself has to be changed". Maybe that is just my translator not working correctly.)

Johann150 avatar Mar 17 '22 18:03 Johann150

@Johann150 以下にmfm.jsを実装するために作成された仕様があります。 https://github.com/misskey-dev/mfm.js/blob/develop/docs/syntax.md

marihachi avatar Mar 19 '22 11:03 marihachi

Any update on this?

ThatOneCalculator avatar Jun 20 '23 19:06 ThatOneCalculator

Any update on this?

@ThatOneCalculator Per marihachi, it seems to be expected rather than a bug:

仕様通りの動作です。これはバグではありません。

A workaround is to use <i>text</i> as instructed by the MFM docs.

outloudvi avatar Jun 21 '23 01:06 outloudvi

I personally disagree, as this isn't the behavior of other standard markdown parsers and confuses users.

ThatOneCalculator avatar Jun 21 '23 01:06 ThatOneCalculator

I join the discussion to say actual behaviour, I described into #134, it's confusing for people writing Latin / European languages.

Although in this repository MFM is never addressed as Markdown For Misskey in the source code, or documentation, neither when the repository was renamed #30 (2021/03).

I want to note that since 2021/09 the Misskey.io Wiki Pages are claiming MFM is Markdown For Misskey, and not a different thing, for example Markup For Misskey.

This is the origin of confusion. Since the beginning, people expect to have markdown into Misskey. At least a basic subset, made of bold, oblique, links and quote. (No support for bullet / numbered lists)

So I end up asking for oblique text rendering to be fixed. Please.

tassoman avatar Nov 24 '23 22:11 tassoman

The Firefish project will be addressing this in libmfm

ThatOneCalculator avatar Nov 24 '23 23:11 ThatOneCalculator

That software can't be used in this project because is lacking of a free software license compatible with AGPLv3.
If your code incorporated misskey-dev/mfm.js code, it must be released at least under MIT license or kept private.

tassoman avatar Nov 27 '23 17:11 tassoman

The idea is it to be an alternative implementation to mfm.js.

ThatOneCalculator avatar Nov 27 '23 18:11 ThatOneCalculator