✨ Add "toggle block quote" #811

Sean10 · 2020-09-12T15:18:06Z

support scene

quote/unquote the cursor line
quote/unquote the selection lines.
- if some lines haven't been quote, quote them.
- if all of the lines have been quoted, unquote them.

#704

yzhang-gh

Many thanks! Just a few comments.

package.json

yzhang-gh · 2020-09-12T15:44:14Z

src/formatting.ts

@@ -45,6 +46,74 @@ function toggleCodeBlock() {
    return editor.insertSnippet(new SnippetString('```$0\n$TM_SELECTED_TEXT\n```'));
 }

+enum QuoteState {
+    // State 1: part of lines has been quoted, need to be quoted
+    PARTIALQUOTED,


I think it is more natural to quote all the lines (not only the unquoted lines) in this case (thinking about doing multi-line comment).

In consideration of the selected text not always accurate, especially like i use three finder drag, i may select more lines which have been quoted. In this situation, what i need is just to quote the unquoted lines. There is no need to quote which have been quoted which may cause the text format disturbed. So could you share the example which is preferred to quote all selected lines?

In consideration of the selected text not always accurate, especially like i use three finder drag, i may select more lines which have been quoted. In this situation, what i need is just to quote the unquoted lines.

I agree this is probably a good design (for some people, or maybe the majority). But as a first step, I would like to make it consistent with other similar commands, e.g.

Maybe add a switch to decide wthether need to only quote unquoted lines so that default quote behavior is the same as others?

Assuming you implement a separate unquoting command, @Sean10 can't the user just solve your case by hitting the unquoting command then hitting the quoting command? Same result.

I agree with @yzhang-gh there are many more instances when it's preferable to nest blockquotes.

src/formatting.ts

yzhang-gh · 2020-09-12T15:49:11Z

src/formatting.ts

+    if (line.startsWith("> ")) {
+        return line.slice(2);
+    } else {


line.startsWith('>')?

Yes, you're right. I thought adding a space is more beautiful and standard. But actually no such setting in github markdown.I will modify this.

Well, I think we can definitely advocate adding a space after > (actually I like it). I meant we still need to handle the case if there isn't a space.

Ok～I will modify the space back and skip the line which it hasn't appended space.

src/formatting.ts

… code, use eol to replace \n to fix different eol problem, fixredundant quote syntax

Lemmingh · 2020-09-13T02:01:27Z

FYI, VS Code's _analyzeLines() and _executeLineComments():

https://github.com/microsoft/vscode/blob/03adc22ea6ff4c9dd88ec6e4bbd11b1097f0f726/src/vs/editor/contrib/comment/lineCommentCommand.ts

The Spec is very permissive about spaces, which honestly, is often a headache.

And remember leading spaces may have semantic meaning, for example, indentation.

Given that indentation in Markdown is flexible, we cannot use tabSize configuration, but usually have to look behind and ahead to determine it instead.

My proposal:

When a user run this command, the person implies all the lines support it, so we only need to detect indentation.

If there are 4 or more leading spaces in the lines, check if we're in an indented code block.
If there are 3 or more leading spaces in the lines, check if we're in a list.
If there are 2 or more leading spaces in the lines, check if we're in an unordered list.
Otherwise, we're at the root level.

Lemmingh · 2020-09-13T02:58:19Z

My previous comment looks pretty confusing.

The actual procedure to determine indentation size I is more likely to be:

Let I = 0.
Let S be the length of leading spaces.
If S >= 2, then:
1. Look behind. If we're in a list, then:
  1. Let I be ("the length of list marker" + "the length of the marker's leading spaces" + 1).
Return I.

@yzhang-gh
What about extracting some functions from listEditing.ts as utilities?

yzhang-gh · 2020-09-13T06:31:39Z

Things become more complex now...

I don't want to add too much code only to deal with the corner cases for such a tiny feature. The simplest way is probably to stick with what VSCode does for comment/uncomment (not 100% accurate as VSCode seems to ignore blank lines?)

If not all lines start with > (or are blank lines), then add > to all lines;
else if all lines start with > , remove all leading > ;
else remove leading > of all lines. (As for the possible leading whitespace... I don't care...)

The difference (from the current implementation) is each line is not transformed independently.

@Lemmingh What do you think of (case 1) adding > to 1) all lines or 2) only lines that don't have > ? (IMO, it isn't worth a configuration... Let's simply do a poll and make a decision here.)

Something interesting

Input

> - one
>   - two

Output

one

two

Input

>- one
>  - two

Output

one

two

Lemmingh · 2020-09-13T14:38:53Z

As far as I can tell, there are 2 major differences between VS Code's "Toggle Line Comment" and our "Toggle block quote":

When a user runs the command:
- VS Code first checks whether it is supported.
- In our case, the user is determined and implies all the lines support it, so we don't need to check.
To calculate insertion points when adding markers:
- VS Code uses _normalizeInsertionPoint() which depends on tabSize.
- We cannot due to the flexibility of Markdown, and I raised the proposal. (The first time I thought, I found a great number of cases. Later I realized that only lists count. 😂)

I think "To calculate insertion points" (or "indentation size" or "indentation point") is the challenge now:

When the lines really contain a block quote ("Each prefixed by a block quote marker (ignoring leading spaces)" && S <= I + 3), we can remove markers. (Otherwise, the user intends to add markers to create one.)
When adding markers, we have to know where to insert them.

VSCode seems to ignore blank lines

I think so.

I believe our command should act on all the lines to produce only one block quote.

If not all lines start with ...

In step 1, I prefer not to op on leading and trailing blank lines. I mean we should exclude leading and trailing blank lines at analyzing stage, since user may select a lot of blank lines around the intended lines.

In step 2, we should match block quote marker by /> ?/. After ignoring leading spaces, the operation should equal to .replace(/^> ?/, '')

Step 3 may break the document and sounds unnecessary. I prefer to drop it.

What do you think of (case 1)

To be robust, I'm stubborn to always add > (U+003E U+0020) to all the lines.

Your interesting case exactly reflects the definition of block quote, and is one of the reasons that I said

The Spec is very permissive about spaces

yzhang-gh · 2020-09-13T15:38:55Z

When adding markers, we have to know where to insert them.

Alright, I didn't really think of this case. Now I know what you mean, for example

- one                   -->      - one
  nested quote 😱                  > nested quote 😱

one

nested quote 😱

@Sean10 As you see, there are quite a few potential issues with the current implementation. I would suggest making a standalone extension for this feature. And if we find there are many users wanting this, we can then make an effort to resolve this properly.

Sean10 · 2020-09-14T01:33:44Z

Yes, I understand this. I will temporarily make a standalone extension for my specific scene.

GMNGeoffrey · 2021-01-22T01:38:13Z

@Sean10 did you end up making this? I came here looking for this feature. I may install https://marketplace.visualstudio.com/items?itemName=jebbs.markdown-extended as well, but not sure about extension interaction

Sean10 · 2021-01-22T07:37:57Z

@Sean10 did you end up making this? I came here looking for this feature. I may install https://marketplace.visualstudio.com/items?itemName=jebbs.markdown-extended as well, but not sure about extension interaction

vscode-markdown-quote - Visual Studio Marketplace this one.

gmccullo · 2023-03-18T09:59:37Z

+1. I want this!

huyz · 2024-03-31T16:47:12Z

I think all this is too complicated because of the misguided attempt to implement a "toggle".

Not only does this bring up lots of undefined cases, but it's actually not useful IMO. What would be preferable is blockquote increase and decrease. In Markdown, there are many use cases for nested blockquotes. I use them all the time in Obsidian.

For this blockquote functionality, I've been using this Obsidian plugin https://github.com/czottmann/obsidian-blockquote-levels for years and it works beautifully.

Two separate commands are simpler to design and implement and actually give users a way to handle all cases, without ambiguity.

Sean10 · 2024-04-14T14:38:58Z

I think all this is too complicated because of the misguided attempt to implement a "toggle".

Not only does this bring up lots of undefined cases, but it's actually not useful IMO. What would be preferable is blockquote increase and decrease. In Markdown, there are many use cases for nested blockquotes. I use them all the time in Obsidian.

For this blockquote functionality, I've been using this Obsidian plugin https://github.com/czottmann/obsidian-blockquote-levels for years and it works beautifully.

Two separate commands are simpler to design and implement and actually give users a way to handle all cases, without ambiguity.

done

add quote/unquote line/multiline support

c3cf132

yzhang-gh reviewed Sep 12, 2020

View reviewed changes

Lemmingh changed the title ~~add quote/unquote line/multiline support~~ ✨ Add "toggle block quote" Sep 12, 2020

delete default quote keybinding, use better every() replace redundant…

886d813

… code, use eol to replace \n to fix different eol problem, fixredundant quote syntax

Sean10 and others added 3 commits September 13, 2020 11:09

back to append space after '>'

df65a66

remove default key binding

4344ab6

tweaks

abf326a

Sean10 force-pushed the master branch from ca93e38 to abf326a Compare September 13, 2020 03:30

Lemmingh marked this pull request as draft September 13, 2020 14:39

Lemmingh added the Help wanted Looking for help. label Dec 13, 2020

Lemmingh added Area: Block quote https://spec.commonmark.org/0.30/#block-quotes Area: Input Related to editor input processing (key presses, key bindings). labels Aug 26, 2021

rexingQ mentioned this pull request May 23, 2022

I prefer to not add a default key binding for this command as it is not very popular. #1128

Closed

huyz mentioned this pull request Mar 31, 2024

[Feature] Separate commands for increasing and decreasing blockquote Sean10/vscode-markdown-quote#1

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

✨ Add "toggle block quote" #811

✨ Add "toggle block quote" #811

Sean10 commented Sep 12, 2020

yzhang-gh left a comment

yzhang-gh Sep 12, 2020

Sean10 Sep 12, 2020

yzhang-gh Sep 12, 2020

Sean10 Sep 12, 2020

huyz Mar 31, 2024 •

edited

Loading

yzhang-gh Sep 12, 2020

Sean10 Sep 12, 2020

yzhang-gh Sep 12, 2020

Sean10 Sep 12, 2020

Lemmingh commented Sep 13, 2020

Lemmingh commented Sep 13, 2020 •

edited

Loading

yzhang-gh commented Sep 13, 2020 •

edited

Loading

Lemmingh commented Sep 13, 2020

yzhang-gh commented Sep 13, 2020

Sean10 commented Sep 14, 2020 •

edited by Lemmingh

Loading

GMNGeoffrey commented Jan 22, 2021 •

edited

Loading

Sean10 commented Jan 22, 2021

gmccullo commented Mar 18, 2023

huyz commented Mar 31, 2024 •

edited

Loading

Sean10 commented Apr 14, 2024

✨ Add "toggle block quote" #811

Are you sure you want to change the base?

✨ Add "toggle block quote" #811

Conversation

Sean10 commented Sep 12, 2020

support scene

yzhang-gh left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

huyz Mar 31, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Lemmingh commented Sep 13, 2020

Lemmingh commented Sep 13, 2020 • edited Loading

yzhang-gh commented Sep 13, 2020 • edited Loading

Lemmingh commented Sep 13, 2020

yzhang-gh commented Sep 13, 2020

Sean10 commented Sep 14, 2020 • edited by Lemmingh Loading

GMNGeoffrey commented Jan 22, 2021 • edited Loading

Sean10 commented Jan 22, 2021

gmccullo commented Mar 18, 2023

huyz commented Mar 31, 2024 • edited Loading

Sean10 commented Apr 14, 2024

huyz Mar 31, 2024 •

edited

Loading

Lemmingh commented Sep 13, 2020 •

edited

Loading

yzhang-gh commented Sep 13, 2020 •

edited

Loading

Sean10 commented Sep 14, 2020 •

edited by Lemmingh

Loading

GMNGeoffrey commented Jan 22, 2021 •

edited

Loading

huyz commented Mar 31, 2024 •

edited

Loading