Links with nested HTML or \n confuse the markdown converter

この issue ではファイルもテストも指定されていません。まず、レポートにある3つの HTML リンクのケースを Markdown コンバーターで再現し、次に、そこで説明されているアンカーテキストのマッチングと node textContent の処理を調べてください。リンク内のネストされた要素と改行によって期待される Markdown リンクが生成され、報告された例に対するリグレッションカバレッジがある状態を完了とします。

A couple cases that generate the wrong markup.

1. nested html elements in link

<a href="http://example.com/"><span>foo</span></a> <a href="http://example.com/">bar</a> foo bar

gets converted to

[foo](http://example.com/) bar foo [bar](http://example.com/)

when I would expect

[foo](http://example.com/) [bar](http://example.com/) foo bar

What happens: the walker enters the a and then enters the span again, finding the same text twice. But the proper label text was already consumed, so it consumes until it finds another match. In some cases (like above) it even linkifies the wrong text.

2. line breaks in link

<a href="https://example.com/">foo
bar</a>

(notice the line break) gets converted to

foo bar

when I would expect

[foo bar](https://example.com/)

What happens: the node textContent is 'foo\nbar' which doesn't match any text in the plaintext.

2b. <br> in link

Another similar (but possibly harder to fix) case is

<a href="https://example.com/">foo<br>bar</a>

which like 2 doesn't create a link:

foo
bar

In general, since the code can't rely on the browser to properly deal with HTML content, some of these corner cases will probably keep popping up. But this happened in the real world (try copying and pasting the first news entry in the deprecated section here) and it seemed to be significant enough to report.

I will follow up with a PR that suggests potential fixes for 1 and 2 (but not 2b), but this is not my field so it might be far from good.