markdown-insert-bold and other formatting, including space

[telephon]

Expected Behavior

markdown-insert-bold and similar functions should always result in a legal formatting of the text, even if the selection/markers included a space at the beginning or end. [EDIT] This could be achieved by jumping to the next "legal" beginning of a formatting.

Actual Behavior

When selecting text to then do C-c C-s … (e.g. markdown-insert-bold), it easily happens that accidentally the selection begins with a space instead of the first character of the text. Then the text is not formatted, and one has to manually move the space outside.

Eg.

this is* a selection* of two words

this is *a selection* of two words

Steps to Reproduce

1. select a string so that it begins with space
2. hit C-c C-s b
3. the resulting text is not bold.

Backtrace

Software Versions

markdown-mode, version 2.5-dev

GNU Emacs 27.1 (build 1, x86_64-apple-darwin18.7.0, NS appkit-1671.60 Version 10.14.6 (Build 18G95)) of 2020-08-12

[syohex]

This is specification. * or _ or similar markup character is treated as literal character if * or _ is followed by space.

https://spec.commonmark.org/0.29/#emphasis-and-strong-emphasis

A left-flanking delimiter run is a delimiter run that is (1) not followed by Unicode whitespace.

https://gist.github.com/syohex/513571899a8b9b934426b148020f76c2

For example, Github markdown renderer does not render as you expected, it renders as markdown specification.

[telephon]

@syohex

This is a misunderstanding: I am not arguing against the specification, but for it. I am arguing that the intended semantics of a function does not meet that specification.

e.g. markdown-insert-bold intends to "insert characters to make selected text bold". But it does not always insert characters in a way that the selected text is bold. If the text begins with a space, it does not succeed to do this, because it ignores the specification.

So it offloads subtle boundary conditions to the call context which leads to failure if not used carefully.

The alternative is to avoid inserting the characters at a place where they do not result in the intended behaviour, but instead find the next non-whitspace character for the insertion point first. This will make the function work better according to markdown specification.

[syohex]

I'm not sure, is #614 what you said ?

[telephon]

Excellent, thank you!

It would be good if it would also work for spaces at the end: (I use | pipes to mark selection):

one| two| three –> one **two** three ;; this works
one |two |three –> one **two **three ;; this doesn't work yet, should be:
one |two |three –> one **two** three

And it could be used for markdown-insert-strike-through, too.