Editing formatting getting stuck
B24 on OSX 10.12.6, using the MMD standard Solarized theme.
I'm having a lot of instances of the editing formatting getting "stuck." For example, in a list, where the text is normally a different color (I'm not good with colors, so I'm not even going to attempt to describe what that color is), I'm getting new list items where the text color remains gray (the "normal" text color). I'm attaching an example of that.
I've also had it where the list color was right, but when I accented a word to mark it as code, e.g. like this, what was in the accents didn't change color or font (again, on the editing side, the Preview is OK).
I've also had it where the code formatting got stuck, i.e. in a case like this, what followed the "like this" stayed in the color and font of the code block, instead of resetting back to the normal list formatting after the second accent.
Those examples are all while in a list, but it's not restricted to that — I just had it get stuck while in normal text (code didn't show as code). I'm attaching a second screen print of that. In this case, I chose a blank line below the list (IOW, I didn't hit Enter on the last line of the list, I positioned to an already existing blank line below the list), hit Enter, and started typing. Code formatting didn't work.
One or the other has happened several times to me very shortly after I started using B24 this morning. I switched over to the test file, and it happened there as well. There's no particular set of steps to make it happen, it just starts happening. I'm editing towards the end of the test document.
-
No_list_formatting.jpg
321 KB
-
No_code_formatting.jpg
277 KB
No_list_formatting.jpg
No_code_formatting.jpg
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
Support Staff 1 Posted by Fletcher on 30 Aug, 2017 04:32 PM
If you can figure out how to reproduce it, let me know. I've seen it
happen once, maybe twice, and that was weeks ago.
Basically, there are two options when formatting a document like
Markdown where earlier lines can effect the meaning of later lines (e.g.
fenced code blocks):
1. Reparse the entire document to make sure nothing has changed
2. Attempt to identify the smallest possible unit of text to reparse
Option 1 is feasible, but can start to hurt performance in long
documents (some people write novels in Composer). So that's out.
Option 2 requires a smart algorithm to identify the proper range. And
there are *tons* of edge cases here.
I spent months of testing in v3 to create a (rather complex) algorithm
that worked reliably. In v4 I wanted to try to create something simpler
and faster. The vast majority of the time it works, but it can be
fooled (again, fenced code blocks being an easy example). Now that
other stuff is settling down, I'll go back to that algorithm, but edge
cases that don't work are very helpful in improving it.
(PS> Nothing should have changed about this in b24)
Thanks!
2 Posted by Vince Rice on 30 Aug, 2017 04:56 PM
As I said, it's happening to me pretty regularly in both my real file and the test one I sent you. I just had it get locked on code formatting. I deleted the entire sentence including the code, saved the file, then exited and re-opened MMD. This time when I started typing, the list formatting is locked; an accented word doesn't show up as code. So the opposite of what was happening. But it happened in a brand new started MMD.
That's as much as I'm going to be able to tell you.
And whether it "should" have changed or not, I haven't seen this prior to B24.
Support Staff 3 Posted by Fletcher on 30 Aug, 2017 05:26 PM
It's not something I can replicate, so if you're able to figure out anything more specific, let me know.
4 Posted by Vince Rice on 30 Aug, 2017 05:55 PM
I feel like you're putting this back on me. I've already spent several hours putting together a test file for you. I've given you screen shots that shows where it happened and what it looked like when it did. I've told you where I was editing (which you can also see in the screen shots) when it happened. I've indicated that sometimes it happens in the first editing that occurs in a file, and sometimes it happens after a while, but that it is happening pretty consistently. There are no "steps" to make it happen. It just starts happening, just like the bouncing around issue.
If you can't replicate it, then you can do more testing to see if you can, or ask (specific) questions if you need more information that hasn't been provided, or put together an instrumented app, or any of a number of other things. Or you can ignore it and release the app with the problem. But whatever happens next, it's in your hands, not mine. I have given you all of the information that I know to give.
Support Staff 5 Posted by Fletcher on 30 Aug, 2017 07:38 PM
I'm not putting it back on you. I'm simply informing you that I use
this app a lot, and haven't seen this behavior in weeks (many versions ago).
I should also note that only one person has reported this issue, and he
noted that the problem disappeared and he has presumably not recreated
it since (I haven't heard anything new).
You report having this issue frequently.
Presumably there is something different about the way you type in your
files than the way I type in mine (like the French Canadian example I
gave you.) If the app caused this much trouble for me, I would not have
released it without fixing it first.
This makes it very unlikely that I will stumble across a recreation,
since I don't write in French (to continue the analogy.)
I would like to fix the issue, but need details in order to accomplish
this the "right" way (without reverting to the sledge hammer of "just
reparse the entire document every keystroke").
If it happens again, simply stop typing. Use undo to step backwards
until the problem disappears, then redo until it happens again. This
will show you exactly where the problem occurred and what the change was
(e.g. "I hit enter after a list bullet with 5 empty spaces after it.")
You can then send a copy of the text immediately before the glitch,
along with what to type and where, allowing me to easily recreate the
issue and ensure a working fix.
This should be a quick way to give me accurate information with minimal
effort on your part -- simply recognizing that something strange
happened that you want to have fixed, and a few keystrokes to move and
back forth through the undo chain.
Either way, I appreciate the feedback you have given so far to help
continue to improve MultiMarkdown Composer.
Support Staff 6 Posted by Fletcher on 30 Aug, 2017 07:44 PM
(ADDENDUM: If using the undo/redo approach, it's best to send the two steps leading up to the issue to better ensure that some of the "hidden" variables are the same)
Support Staff 7 Posted by Fletcher on 02 Sep, 2017 02:40 AM
I found an issue in highlighting that is probably what caused this. Fixed for b27. If it returns, please open a new issue with as many specifics as possible. Thanks!
Fletcher closed this discussion on 02 Sep, 2017 02:40 AM.