sublimehq
[Markdown] Re-wrapping of quotations by using Alt-Q is wrong
Test 1:
> Some text a a a a a a a a a a a a a a a a a a
> a a a a a a a a a.
Test 2:
> Some text a a a a a a a a a a a a a a a a a a
> a a a a a a a a a
> a a a a a a a a a a a a a a a a a a.
Select the text and press Alt-Q. It is expected that Sublime Text should re-wrap selected lines, so that it should become
> Some text a a a a a a a a a a a a a a a a a a a a a a a a a a a.
> Some text a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
> a a a a a a a a a a a a.
Instead, nothing happens.
Also, if the initial quotation is a one-liner, the wrapped version will have only the first >. That is,
> Some text a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a.
Will be wrapped to
> Some text a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
a a a a a a a a a a a a a a a a a a a a a a a a a.
- Sublime Version: 4.1.1.3
- OS Version: Win 7
Sublime Text doesn't have any concept of special treatment of leading punctuation.
It is not possible to automatically add such leading punctuation for soft-wrapped lines atm.
It's a "serious" core limitation as it is very likely to be hit in Markdown in various situations. It has been discussed at https://github.com/SublimeText-Markdown/MarkdownEditing/issues/203, already.
alt+q is bound to a built-in function, which is as naive as just hard-wrapping lines without such prefixes, too.
It is definitely possible to create a custom "wrap_lines" command for Markdown, which handles block-quotes and lists, but that's probably out of scope of this repository, which primarily is used for syntax definitions. It may be implemented in MarkdownEditing in future.
If ST creates hanging indentation for > a a a you are lucky already. I'd whish something like that happening for soft-wrapped ordered and unordered lists.
@deathaxe Hmm, but if I change > to // and save it as JavaScript file, it works fine.
Test 1:
// Some text a a a a a a a a a a a a a a a a a a
// a a a a a a a a a.
Test 2:
// Some text a a a a a a a a a a a a a a a a a a
// a a a a a a a a a
// a a a a a a a a a a a a a a a a a a.
Test 3:
// Some text a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a.
Test 1:
// Some text a a a a a a a a a a a a a a a a a a a a a a a a a a a.
Test 2:
// Some text a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
// a a a a a a a a a a a a.
Test 3:
// Some text a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
// a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a
// a a a a a a a a a a a a a a a a a a a a a a a a a.
Soft wrapping via "word_wrap" setting doesn't add/display such leading punctuation automatically. That's what I refered to as "no concept of leading punctuation".
Yes, the core command wrap_lines which is called when pressing alt+q (aka. hard line wrapping) seems to know about some comment styles in source code, but no one except core devs knows exactly how.
It appears ST4 uses comment and punctuation.definition.comment for that, but I don't think we want to scope block quotes "comment".
@deathaxe I understand your explanation, thanks for it.
However, let me point back to the tests 1 and 2 to show why I think you are not completely correct.
> Some text a a a a a a a a a a a a a a a a a a
> a a a a a a a a a
> a a a a a a a a a a a a a a a a a a.
If you select these lines and press Alt-Q, nothing happens. However, without >, Alt-Q works just as expected. And so it seems that Sublime Text is actually does have the conception of leading punctuation or something like it.
This "concept" is limited to wrapping comments by built-in "wrap_lines" command.
It can't be applied to any other syntax construct nor does it work for soft-wrapped lines.
That's why I don't want to call it a concept.
That said, this issue can't be fixed by syntax definitions in this repo.
In case the core "wrap_lines" function is to be updated I'd like to see some kind of general scoping concept which can be used by any syntax to specify
- hanging indents
- repeated characters to be prepended to each wrapped line
rather than relying on any hard-coded core heuristics, which can't satisfy all those different syntaxes out in the wild.