Preview

Vince's Avatar

Vince

19 Aug, 2017 07:40 PM

Running beta 16 on OS X 10.12.6.
I have both "Synchronize preview location while typing" and "Always synchronize scrolling" checked, and Typewriter mode turned off.

In our code block discussion, the subject of the preview pane came up, and you wrote about several of the improvements of MMD's over others. The problem is that I'm not seeing what you're describing.

So, for example, "With synchronized scrolling, the text on the left lines up with the same area on the right." Well, no, not for me. I've attached two screen prints of the top portion of the MMD window for one of my files. The "Top Left" is when I scroll as far as I can to the top in the left-hand (non-preview) portion of the window. Notice the big gap at the top on the right. The "Top Right" is when I scroll as far as I can to the top of the right-hand (preview) portion of the window. Notice the left-hand side is several lines down from the top.

Now, the "When you type, the line you are typing on in the editor lines up with the same line of text in the web view." does seem to work, mostly. When I put the cursor on the first line and type something, then the right-hand side suddenly scrolls up to match, and eliminates that big gap at the top you see in the "Top Left"picture.

"Mostly," though, is because the right-hand side jumps up and down several lines every so often. It seems to be random — not related to what I'm typing, and it only happens every few seconds, and it's very fast; it jumps up and back in the time it takes to type two or three letters (I type 100+). But it's very distracting. It might be a side-effect of the top gap being there, or it might be unrelated.

As far as "I'll trade all of this for not seeing a refresh every time I hit the spacebar," well… Again, I've been using MD for three or four years, and have tried at least a half-dozen editors in that time, three of which I still have (technically two; one of the ones I still have doesn't work since I finally upgraded to Sierra a couple of months ago). I've done a lot of typing in MD editors, and I see no visible difference in responsiveness in MMD, and so far I've run into multiple issues in it that I don't have in the others. I"m not trying to be argumentative, just telling you what I see in actual use.

On a completely separate note…
When giving the users options for behavior, the defaults of a program should offer the "least surprise" to the user. IMO, MMD violates this on several fronts: Typewriter mode should default to off, and both of the synchronize options should default to on. Nobody expects typewriter mode (or the Spanish Inquisition) *by default* in a text editor. Everyone expects synchronized scrolling in any MD editor. The options to change the behavior are great, but the defaults should offer the least surprise to the user. In the current configuration, new users have to jump through a lot of hoops (including figuring out what the heck typewriter mode is, and no, I don't want to know more about it) that they shouldn't need to. You don't have to convince me of why I'm wrong, I'm just offering feedback. Do with it what you will, including nothing. :)

  1. Support Staff 1 Posted by Fletcher on 19 Aug, 2017 08:41 PM

    Fletcher's Avatar

    Your screenshots were not attached here either, so I can't see what
    you're describing.

    There are a few tweaks to be done in the automatic CSS for v4 to add
    extra space to accommodate scrolling under all (or nearly)
    circumstances. So there will be edge cases that don't work. For now, if
    you want to test it out, stick to the "middle" of the document rather
    than the top/bottom, and things will work better.

    Also, I assume a document where scrolling makes sense(e.g. taller than
    the window.)

    The "mostly" is an area that still requires fine tuning in the beta (and
    this is similar to the issue caused by typing a space). Also, the
    behavior is different in b16 and 17.

    When I'm typing normal "thinking speed" I never (almost never?) see it.
    But as I type faster it happens occasionally. If I type gibberish, it
    happens more frequently.

    This didn't happen in earlier versions of the beta because performance
    was a bit slower. v3 beta, for example, was much slower and if I "speed
    type" the preview just pauses until it catches a break. The prevents
    the jumping, but reduces the responsiveness of the preview.

    v4 builds 16+ have faster performance, which brought this issue back out
    -- I just need to tweak some of the settings to strike the right balance.

  2. 2 Posted by Vince on 19 Aug, 2017 08:59 PM

    Vince's Avatar

    Weird. Let's try again. Right now, the box below this text box says, "ATTACHED FILES with both files listed below it. Which is, of course, what it said when I posted the original message. (They're only a 200-300K each, so they're not hitting the size limit.)

    Interesting. I forgot the spam protection message, so I got the error page. But that page also said neither of the files made it and I should try zipping them. Underneath both file names it said "can't be blank". Which they obviously aren't. So now I've zipped them and we'll see what happens.

    Same thing. I left the spam off intentionally, and I got the same message. The exact text says:
    There was a problem with your uploaded files.
    Try zipping the problem files - our security system automatically blocks certain types of attachments and files. Unfortunately security is always a tradeoff with convenience.

    Preview_scrolling_issues.zip (479 KB)
    can't be blank

    I don't know what "can't be blank" means. If you have any ideas, I'll try it again, or if you have someplace I can email/upload them, I'll be glad to do that.

  3. Support Staff 3 Posted by Fletcher on 19 Aug, 2017 09:02 PM

    Fletcher's Avatar

    Weird -- feel free to email them directly to me:

    admin @ multimarkdown dot com

  4. 4 Posted by Vince Rice on 19 Aug, 2017 09:31 PM

    Vince Rice's Avatar

    Done.

  5. Support Staff 5 Posted by Fletcher on 21 Aug, 2017 05:19 AM

    Fletcher's Avatar

    b19 includes a fair amount of work to the preview in many respects.

  6. Fletcher closed this discussion on 21 Aug, 2017 05:19 AM.

  7. Vince Rice re-opened this discussion on 21 Aug, 2017 03:50 PM

  8. 6 Posted by Vince Rice on 21 Aug, 2017 03:50 PM

    Vince Rice's Avatar

    Beta 19 on OSX 10.12.6. And given the abbreviation issue, I downloaded the beta again just to make sure. :) Same behavior.

    With respect to the specific problems I reported, it's worse.

    I can now scroll the right-hand (preview) side until the text is completely off-screen, both at the top and the bottom. IOW, very similar to what can be done on the left-hand side when Typewriter mode is on (I still have it off. I will always have it off. :) )

    It also still doesn't line up, i.e. scrolling to the top on the non-preview side leaves the same amount of blank space on the preview side that you saw in my previous screen print. However, now when scrolling to the bottom on the non-preview side, it now doesn't go all the way to the bottom on the preview side, to varying degrees.

    I've tried this on several longer than one screen files. The top is consistent — there's a blank space on the preview side on all of them. The bottom is inconsistent; some of the files scroll to the bottom on the preview side, some of them are just missing a line or two below the screen, and some of them are missing a dozen lines or more.

    In addition to all that, on a test document I created (I found a lorum gipsum generator online), I also have a weird cursor problem. When I move to a position in a paragraph and type a letter, the cursor is about a half-space off vertically. In other words, instead of the cursor being after the character, it's right on top of it. I've attached (hopefully!) a screen print showing the cursor in the middle of a character, as well as the file itself.

    If the attachments don't come through, let me know.

  9. Support Staff 7 Posted by Fletcher on 21 Aug, 2017 04:19 PM

    Fletcher's Avatar

    It's intentional to be able to scroll the preview off the screen -- that
    is necessary to allow it to line up properly with the text.

    Also, when defining whether they line up, look at the middle of both
    views vertically -- the text in the middle of the editor should be very
    close to the corresponding text in the preview. It won't be exact
    (lines break in different ways), but it should be very close.

    Remember -- synchronized scrolling in Composer is based on the content
    of the text, NOT matching the percentage of the screens. For example,
    40% of the way down the text may line up with 50% of the way down the
    preview. This is very pronounced in a document with many images -- an
    image takes 1 line of text, may may be an entire screen's worth of the
    preview. A "dumb" scrolling approach (as used in the apps I have
    tested) simply says line 40% on left up with 40% on the right -- this
    may be nowhere near accurate in a document filled with images. Composer
    will generally get it just right (there are ways to trick it, but these
    don't happen often in real world use).

    As for scrolling to the top/bottom, depending on your margins, one side
    or the other may be off the screen. In that case, simply scroll on the
    other side. It also may help if you increase the top/bottom padding in
    the preferences (for my screen and settings, a padding of around 80px
    does pretty nicely...) This gives some additional leeway -- especially
    helps near the top.

  10. Support Staff 8 Posted by Fletcher on 21 Aug, 2017 04:20 PM

    Fletcher's Avatar

    Forgot -- as to the cursor thing, are you able to reproduce it?

    I have seen it in prior builds, but have never been able to reliably
    reproduce it, and haven't seen it lately.

    (I've generally noticed it when AutoZoom was turned on, but I don't
    think you're using that feature).

  11. 9 Posted by Vince Rice on 21 Aug, 2017 04:27 PM

    Vince Rice's Avatar

    Just noticed that we can scroll the preview all the way to right to a blank screen as well.

  12. Support Staff 10 Posted by Fletcher on 21 Aug, 2017 04:40 PM

    Fletcher's Avatar

    How do you do that?

    I can't scroll to the right unless I have a large image or something
    like that, and even then can only scroll the normal amount.

  13. 11 Posted by Vince Rice on 21 Aug, 2017 04:56 PM

    Vince Rice's Avatar

    Last first — I do not have AutoZoom turned on, and it is reproducible on that file. I haven't seen the behavior on any other file so far.

    We should not be able to scroll the preview off the screen. I don't want that there anymore than I wanted it on the non-preview side. I don't know why preview would need to go off-screen to line things up — they are by definition not lined up if I have a hunk of blank screen in the preview. (And, just for information, I don't have any pictures. I know you have to allow for pictures, just clarifying that when I report things, it's without any pictures.)

    I'm not worried and haven't reported anything except all the way to the top/bottom. I don't really care how accurately things are lined up in the middle, as long as they're close. MMD is close, but so is every other program I use. But when I scroll to the top on the non-preview side, then the preview should also be all the way to the top. We should not have to futz with the preview to get it all the way to the top. The top is the top and the bottom is the bottom; there's nothing to compute there. And we shouldn't be able to scroll the preview off the screen in any direction — again, we shouldn't have to futz with the Preview, we should just be able to scroll all the way and have it stop.

    So, I don't know about "dumb" and "smart", but I do know that in these areas, MMD's Preview is worse than the others, not better. And B19 appears to be worse than previous builds. (I'm having the Preview side move to the right several characters on a random but regular basis, so I'm constantly having to scroll left to see everything.)

  14. Support Staff 12 Posted by Fletcher on 21 Aug, 2017 11:10 PM

    Fletcher's Avatar

    I still have not been able to replicate left/right scrolling, on your or
    any other file. See if it happens in b20.

    I think we need a common "terminology" so that we can distinguish bugs
    from performance from design decisions.

    (This got longer than intended -- I'm leaving it in for posterity, but
    feel free to skim over it for the highlights).

    1. In case I didn't do a good job describing Composer's synchronized
    scrolling, I added a video to the support site that shows exactly what I
    mean and why it's different than what I've seen with other apps:

    <http://support.multimarkdown.com/kb/composer-v4/multimarkdown-composer-synchronized-scrolling>

    2. On my machines, 4.0b20 represents a big improvement in the preview
    pane. Let me know how it works for you.

    3. In my mind, these are the separate issues related to the preview:

    A. Accuracy -- whether the same content is in the middle of the editor
    and the middle of the preview. This has to be evaluated separately when
    typing and when scrolling (they work in completely different ways), but
    they should end up with basically the same result. For various reasons,
    it's not practical to expect pixel level accuracy, but it should be very
    close. If it's not accurate, send me the file so I can do some testing
    and improve the algorithm. Some things won't work well however (for
    example, some people load massive log files info Composer --- it doesn't
    surprise me if those don't work, since they're not Markdown files! ;)

    B. Visual stability -- whether the preview "jumps" vertically while
    typing. This actually has to be broken down further:

    1. Frequent jumps with a "re-scroll" to center while typing (every few
    characters). The preview moves unexpectedly, but then moves back to the
    proper place. -- This is a bug (actually several bugs). I spent a lot
    of time today experimenting with different algorithms to avoid edge
    cases that give bad information. 4.0b20 has been, by far, the most
    stable in my tests. Even with rapid fire typing in a test document I
    can't make it jump. If you happen to catch one of these at the right
    time, and *STOP* typing, the preview will remain in the wrong spot.

    2. Very infrequent jumps -- I *think* that there is an issue with
    Apple's Webview that causes infrequently "mis-scrolls". There's no way
    to stop typing and "freeze" this -- it fixes itself. In the latest
    build (4.0b20), I have not been able to identify one of these in my
    testing, so perhaps it was related to a bug on my end. We'll see what
    happens with more testing. Aside -- Apple now has WKWebView, which may
    fix the "spacebar bug" I've alluded to elsewhere, but it is going to
    take a bunch of recoding to make use of it. We'll see where that goes.

    C. Speed -- The preview is designed to be able to keep up with
    individual keystrokes. Depending on how I try to solve other issues,
    sometimes the process is a bit slower (depending on typing speed). For
    example, in a 38,000 character test document -- if I type at "gibberish"
    speed at the bottom of the document, it still refreshes every character
    or couple of characters (it's hard to tell to be honest). But if I do
    the same thing at the top of the document, it refreshes about every
    "word". I'll look into why that is.

    At normal "human" speeds (maybe not professional typist speeds), the
    Preview should be able to refresh every character or two (at least most
    of the time).

    As an aside, I limit the refresh to at most 0.05 seconds, so it can't
    refresh any faster than that.

    D. Scroll detection -- for some reason Composer v3 and v4 aren't always
    told that a scroll has been started with the modifier key held down.
    This seemed reliable in v2. On occasion, I have to stop scrolling, be
    sure to press the modifier key *before* starting the scroll, and then it
    works. I'm looking into what I can do to improve this.

    E. Whitespace/Margins -- in order to allow for proper alignment of any
    text in the middle of the window (since we allow "Typewriter mode"),
    there needs to be additional whitespace at the top and bottom of the
    editor and preview. It should be possible with 1/2 the window height,
    but there were a few issues under special circumstances that made it
    better to use 1x the height. As I improve accuracy, I might be able to
    nudge that back to 1/2 (but even that assumes the "typewriter height" is
    in the middle of the screen). And, yes, if Typewriter mode is disabled,
    the rules change a little bit, but that causes issues with forcing a
    reload any time we toggle settings.

    A good example is a document with metadata at the top. Some of my
    documents have 10-20 lines of metadata in the editor. That has no
    corresponding text in the web side. So in order for the first `<h1>` to
    line up, the preview has to be able to scroll down further than it
    normally would, which requires the presence of additional space at the top.

  15. Support Staff 13 Posted by Fletcher on 22 Aug, 2017 12:19 AM

    Fletcher's Avatar

    Just so that you can see what I see...

    This was from 4.0b20.

    https://vimeo.com/230529690 -- I can't embed it here for some reason.

  16. 14 Posted by Vince Rice on 22 Aug, 2017 07:56 PM

    Vince Rice's Avatar

    A. As I mentioned, this doesn't really concern me, as long as it's close. It's close on every MD editor I've ever tried, including MMD.
    B. I care about this a lot; the jumping is very distracting. But, they're bugs, you're working on them, so this will hopefully be taken care of soon. NBD.
    C. I don't care much about this, either, as long as it keeps us with me 99% of the time, which MMD and every other editor I've tried does.
    D. I'm not sure what this one means. I just scroll with the mouse/trackpad, I don't use a modifier key or know why I would want to.
    E. I care about this one a lot, too. This isn't an MD editor thing, this is an editor thing, period. If I scroll text, I want that text to stop at the window boundary, on all four sides. Period. And every text editor, of any kind, on any platform, that I've ever used, either has this behavior by default (vast majority) or have an option to make it so. If MMD needs to temporarily show some blank space due to consistency issues, fine (I wouldn't, but that's not a deal killer) but the second I start scrolling on that side, I want it to respect the margins, which means there should at least be an option to make it do so. To not do so violates the standard of every text editor on the planet*, and IS a deal-killer.

    For the left/right scrolling, that one's my fault. It appears to be another design decision that, in my experience, though understandable, is non-standard.
    What I didn't notice when I reported it was that a had a really long line in a code block at the end of the document. When I scrolled left/right at the top of the document, I couldn't see that line since it was way off-screen to the bottom, and thus all I got was a blank page. Since I was seeing the same behavior top/bottom, I assumed (and you know where that gets you) they were related.
    MMD doesn't wrap those lines on the preview side, while other MD editors do (that's what I mean by "non-standard"). I understand MMD's behavior and the reasoning behind it, but I don't like it. :) This is another one that IMO should be an option. (And, to be clear, I'm just talking about soft-wrapping the on-screen preview, not modifying the output.)

    *Confession: I have not tried every text editor on the planet. Although sometimes it feels like I have.

  17. Support Staff 15 Posted by Fletcher on 23 Aug, 2017 03:48 PM

    Fletcher's Avatar

    For posterity, (and to prove I'm not crazy), I found additional confirmation of the spacebar bug.

    In rewriting code for the editor pane, I improved performance dramatically by enabling "noncontiguous" layout (basically being able to update text attributes in isolated chunks of the text, rather than a single contiguous block.

    This makes the view more responsive when resizing.

    But this brings back the spacebar bug to the editor pane, not the preview pane. Turning off noncontig layout resolves the issue on the editor. There's not a similar setting for webview, but I suspect the problem may be in the underlying scroll view that both share??

    More details here:

    https://stackoverflow.com/questions/6803665/nstextview-enclosing-sc...

    https://stackoverflow.com/questions/5323830/modifying-nstextstorage...

  18. 16 Posted by Vince on 23 Aug, 2017 09:18 PM

    Vince's Avatar

    Hmmm. I replied to your email yesterday, but apparently screwed up something so it didn't make it here.

    For the record, I didn't think you were crazy. :)

    A. As I mentioned, this doesn't really concern me, as long as it's close. It's close on every MD editor I've ever tried, including MMD.

    B. I care about this a lot; the jumping is very distracting. But, bugs happen, you're working on them, so this will hopefully be taken care of soon. NBD.

    C. I don't care much about this, either, as long as it keeps us with me 99% of the time, which MMD and every other editor I've tried does.

    D. I'm not sure what this one means. I just scroll with the mouse/trackpad, I don't use a modifier key or know why I would want to.

    E. I care about this one a lot, too. This isn't an MD editor thing, this is an editor thing, period. If I scroll text, I want that text to stop at the window boundary, on all four sides. Period. And every text editor, of any kind, on any platform, that I've ever used, either has this behavior by default (vast majority) or has an option to make it so. If MMD needs to temporarily show some blank space due to consistency issues, fine (I wouldn't, but that's not a deal killer) but the second I start scrolling on that side, I want it to respect the margins, which means there should at least be an option to make it do so. To not do so violates the standard of every text editor on the planet*, and IS a deal-killer.

    For the left/right scrolling, that one's my fault. It appears to be another MMD design decision.
    What I didn't notice when I reported it was that I had a really long line in a code block at the end of the document. When I scrolled left/right at the top of the document, I couldn't see that line since it was way off-screen to the bottom, and thus all I got was a blank page. Since I was seeing the same behavior top/bottom, I assumed (and you know where that gets you) they were related.
    MMD doesn't wrap long lines in a code block on the preview side, while other MD editors do. I understand MMD's behavior and I can imagine the reasoning behind it, but I don't like it. :) This is another one that IMO should be an option. (And, to be clear, I'm just talking about soft-wrapping the on-screen preview, not modifying the output.)

    *Confession: I have not tried every text editor on the planet.

  19. 17 Posted by Vince on 23 Aug, 2017 09:20 PM

    Vince's Avatar

    Well, I sent a reply to your yesterday's email that didn't make it. And when I just tried to post it on the web site, that didn't work, either. I'm just doing this to see if this one works.

  20. Support Staff 18 Posted by Fletcher on 23 Aug, 2017 10:02 PM

    Fletcher's Avatar

    This worked.

  21. Support Staff 19 Posted by Fletcher on 23 Aug, 2017 10:34 PM

    Fletcher's Avatar

    These got routed to the spam folder -- I released them.

    RE: letter D -- You turned on "Always synchronize scrolling", so you
    don't need a modifier key. Though if you did use it, then the two sides
    *would not* scroll in sync. Either way, by toggling the modifier key
    you can control what happens when you scroll.

    That makes sense now about left right scrolling. Code blocks are
    supposed to preserve the original line breaks. If you use a code block
    with long lines, they are not supposed to break. So in this instance,
    Composer is doing the "standard" thing. ;) This is why so many
    code-heavy websites put code blocks inside a separate scrolling frame --
    inserting line breaks that aren't there would alter the layout, and
    potentially the meaning, of the text.

    The same thing would happen if you included an image and specified a
    width larger than the size of the window -- the options are to modify
    your document (shrink the image?, shrink the entire page?) or to have
    the image extend past the boundary of the view.

    This is the exact same behavior demonstrated by web browsers when the
    content is too large for the window size.

  22. 20 Posted by Vince on 24 Aug, 2017 03:58 PM

    Vince's Avatar

    The person standing by herself/himself can yell "standard" all they want, but if no one joins them it's a standard in name only. :) (And since there is no standard for MD, it's not even one in name.)

    As I already said in my email, we're not talking about the output, we're talking about the display on the screen. And when displaying really long lines on the screen, it's helpful to be able to soft-wrap them. (Most code editors have an option to soft-wrap past a certain margin for just this reason.) Which is why I said MMD should have an option to do the same.

    Images are a completely separate matter; they can't be soft-wrapped. Text can (optionally).

  23. Support Staff 21 Posted by Fletcher on 24 Aug, 2017 05:09 PM

    Fletcher's Avatar

    They may be standing alone, but that doesn't make them any less right... ;)

    But my bigger point is this:

    What you think is "standard" is "wrong" to someone else (and
    vice-versa). Sometimes there is a correct answer, and sometimes it's
    just two conflicting opinions. I can't read everyone's mind as to when
    they think Composer should follow the "rules", and when it should break
    the rules.

    So I have to do what I think is right. And when I get feedback, I have
    to decide whether to change my mind.

    On occasion, I can add an option to allow both options.

    **BUT**.... One thing I am absolutely convinced of is that too many
    options and preferences is not the answer. Microsoft Word has just
    about every possible preference, check box, and dial imaginable. And it
    is one of the worst programs out there in common use.

    So I won't be adding user preferences for every single possible thing.

    Especially since Composer allows so much flexibility as is.

    For example, you want code blocks (which normally do not line wrap) to
    line wrap. No problem -- adjust your CSS so that code blocks line wrap:

    <https://www.w3schools.com/cssref/pr_text_white-space.asp>

    This allows each user control over how they want their documents to
    work, and they don't have to wait on me to do it.

  24. 22 Posted by Vince Rice on 24 Aug, 2017 07:30 PM

    Vince Rice's Avatar

    Perhaps surprisingly to you, I agree with everything you said. My purpose and goal in a beta, any beta, is to provide that feedback. And to try to do so with while keeping in mind a larger audience than just me. I don't expect you to read "everyone's" mind. In general, I'm not using opinions (mine or anyone else's) as the basis for requests. I'm using actual, shipping, products. And where there are a wide variety of implementations, I'm not claiming one is right and the other wrong. I'm specifically only talking about instances where MMD stands alone in an implementation.

    E.g., in the case of code wrap, every other product I've encountered wraps code in preview. "Standard!" is thus no defense for not doing so; even if it was a standard (it's not — for preview), it would be a standard no one adheres to. "Use CSS!" is a valid "option" (not all options are Preference options), but I'll note it would be even more helpful if MMD provided an example CSS that did so, without forcing users to learn CSS just to accomplish what every one else does by default. (If/when I figure it out, I'll be glad to donate the CSS.)
    (And, to digress for a moment, the pretentious.css file is an atrocity, to put it nicely. :) Please get that formatted in standard, readable CSS format, like the basic.css file. Right now, it's one long giant line, no white spaces around the brackets, etc. It's unreadable, and therefore useless as an example for those of us who know very little about CSS.)

    Ditto for scrolling in preview. MMD stands alone on scrolling outside the boundaries (I would argue it's breaking a standard), not just for MD editors, but for editors in general. That means, IMO, that MMD owes users a way to implement the standard behavior. This isn't a unique capability like support for subscripts/superscripts, where you can implement it however you want with whatever restrictions you want, because you're the only one doing it, or at least the only one I've encountered. (I love that support, btw. I'll probably need it once a year, but I love that it's there.) It's a standard capability that anyone using an editor expects.

    So, when I ask for options (and as I said, by "option" I mean "a means to get the behavior"), I have in mind the big picture, and I'm only doing so on issues where MMD is forcing behavior unique to itself that are non-standard.

    We understand each other's positions, I think. We can move forward. :)

  25. Support Staff 23 Posted by Fletcher on 24 Aug, 2017 10:59 PM

    Fletcher's Avatar

    ;)

  26. Fletcher closed this discussion on 30 Aug, 2017 02:19 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac