Home → Problems (v2) →

Deleting one of a smart pair should remove both (esp wrt CriticMarkup)

• Edit

hal0

07 Jun, 2013 01:31 AM

When using smart pairs, hitting Del to backspace through the opening mark (or, really, any means of erasing the markup) should also remove the closing mark to keep them balanced. This may be little more than a nuisance, but it's a very common one (depending on the content), and when dealing with CriticMarkup, it is especially problematic. Should one make a change with CriticMarkup enabled, then change one's mind and attempt to "remove" the change, only the opening markup can be removed. As a workaround, the closing markup can be removed if/only if Track Changes is turned off.

Because this is an unexpected behavior, I'm opening this under problems instead of suggestions. The CriticMarkup problem could be solved by treating it in the same way as smart pairs, so I list them together here.

1. Support Staff 1 Posted by Fletcher on 07 Jun, 2013 11:50 AM

   

   Using `delete` immediately after typing a smart pair has already been changed for next release.

   The problem with CriticMarkup is that the syntax is multi-character, so hitting delete won't completely erase the markup with a single keystroke unless it is treated as a single unit. Trying to be clever and predicting when the user wants to delete a single character and when they want to delete more than one character is probably going to cause more problems than it solves, unless the prediction algorithm is spot on for every user out there.

   When track changes is on, the user is *intentionally* prevented from "screwing" with the CriticMarkup symbols, because they could quite easily break things. In this case, the best way to undo an unintentional change when tracking changes is the Undo command. When I think of an app offering to "track changes", I assume it is offering me a way to undo anything I change. In this case, it means the app has to be a bit rigid about it lets you do.

   Don't forget, you can also use the accept/reject change feature to "undo" critic markup as well, and this includes removing empty CriticMarkup characters.

   F-

   --
   Fletcher T. Penney
   Manager, Founder
   MultiMarkdown Software, LLC
   [email blocked]

   • smime.p7s 4.78 KB
   • Edit

2. 2 Posted by hal0 on 07 Jun, 2013 02:43 PM

   

   Thanks for fixing the smart pair issue. This has really been bugging me.

   To reply to the CriticMarkup issue: First, it shouldn't be difficult at all -- always treat the CriticMarkup tags as atomic units whenever Track Changes is turned on, and always treat them as individual characters when it's turned off. That may not always be correct, but it will be as close to 100 percent as one can hope to achieve.

   Since opening this issue, I looked into it a bit further. The problem isn't quite as I described it earlier. The actual problem seems to be that the CriticMarkup tags can be removed (both open and close) by using fn+del (forward delete). I agree that it's better not to allow this type of behavior, however, there's another issue that interferes and makes manual removal of the markup an attractive option:

   Suppose I have turned Track Changes on, then, on the following line of text

   The quick brown fox jumps over the lazy, sleeeping dog.

   I correct my misspelling:

   The quick brown fox jumps over the lazy, sl{--e--}eeping dog.

   Then, should I decide to remove the word sleeping entirely, it is not possible without first accepting or rejecting changes, which interrupts the workflow. The correct action, in this particular case, would be to expand the deletion marks:

   The quick brown fox jumps over the lazy{--, sleeping--} dog.

   which automatically "subsumes" the first change into it. However, it's currently much easier (and admittedly incorrect) to manually remove the original marks by forward-deleting them, then continuing on as normal.

   • Edit

3. Support Staff 3 Posted by Fletcher on 07 Jun, 2013 03:52 PM

   

   Good point about the fn+del --- I did not consider that.

   As to your specific example, however, if you place the cursor in front of the deleted range, when you hit delete the CriticMarkup deletion range will grow to include the additional characters. Easier to see than to explain.

   If I "block" fn+del, then the same thing will happen moving forward from the currently deleted range. I realize that this doesn't cover all possible cases where one would want to manually delete critic markup tags, but it would obviate the need to change anything for the specific example you include. You can simply grow the deletion range as needed

   I'm still inclined not to make it any easier for users to delete critic markup tags while track changes is enabled, however. It would make it too easy for the user to break the functionality so that the document no longer accurately reflects the changes that have been made. The idea of track changes is that it records everything needed to convert the original version of your document to the new version. If you're in there "mucking" around with the markup, that is no longer the case. As is, it's still not perfect since you are allowed to edit the text inside deletions and substitutions (maybe you shouldn't be??).

   F-

   On Jun 7, 2013, at 10:43 AM, hal0 <[email blocked]> wrote:

   • smime.p7s 4.78 KB
   • Edit

4. Support Staff 4 Posted by Fletcher on 07 Jun, 2013 07:52 PM

   

   I've reworked some of the code related to CM. You will either be pleased that things are more consistent, or frustrated that they further inhibit your ability to "break" CriticMarkup. In either case, the `fn+del` should work better.

   ;)

   I will use CM to mean CriticMarkup.

   (All of the following only apply when track changes is enabled)

   1. You can continue to use the delete\backspace key to "grow" the beginning of a deletion or substitution by deleting backwards through existing characters, and adding them to the CM that already exists.

   2. You can do the same thing with `fn+delete` to delete forwards and grow the end of a CM deletion/substitution by adding characters.

   So, using your example, you could now extend your single letter deletion to a word deletion, etc. by simply backspacing, or deleting forward.

   3. Using backspace to delete a selection that follows an existing CM deletion, will create a new CM block. Using `fn+delete` to delete a selection that precedes a CM deletion will do the same. Easier to see/do than to explain, but basically the delete functions have a "direction" to them, and only extend an existing CM deletion in the proper direction. If you're in the wrong direction, they are treated as a separate CM deletion block.

   4. Attempting to modify existing text inside a CM deletion, highlight, or the deletion part of a substitution will not do anything. In other words, you can't retroactively modify how a document "used to be."

   5. You can still modify text inside a CM addition, comment, or the addition part of a substitution, since this does not change the original document, only the new version.

   6. You can delete an empty CM structure of any kind. e.g., you can delete "{++++}" or "{----}". But if you hit delete, the whole thing goes --- you can't delete only part of it, which would leave a broken marker.

   Once I test a bit more, I'll release a non-sandboxed build (later this weekend), and you can try it out. I think you will like it better, but it should at least be more consistent with the idea that turning on track changes "freezes" the current version of the document and allows you to record what should be changed from the old to the new version. When track changes is disabled, you can still do whatever you like.

   On Jun 7, 2013, at 10:43 AM, hal0 <[email blocked]> wrote:

   • smime.p7s 4.78 KB
   • Edit

5. 5 Posted by hal0 on 07 Jun, 2013 10:45 PM

   

   Fletcher, this is just what it should be. My goal wasn't to break the CM functionality, but rather, I was finding that I was breaking it out of expediency in lieu of pausing my workflow, "changing the change", then continuing. I'm looking forward to testing the new version, and I'll let you know how it turns out, of course.

   • Edit

6. Fletcher closed this discussion on 08 Jun, 2013 12:34 AM.

7. hal0 re-opened this discussion on 10 Jun, 2013 12:24 AM

8. 6 Posted by hal0 on 10 Jun, 2013 12:24 AM

   

   Here's what I've seen since I've been using the new 2.3.1 with the changes you outlined above:

   There is a very small problem between CM and the highlighting portion of the style sheet engine. I've attached a screen to help you see what's happening. (I'm using the Solarized Dark style sheet in the image.)

   All of the changes you described above seem to be very much like I had hoped for. I did notice that I was unable to delete empty {++} and {--} when Track Changes is on, which I personally do not find too upsetting but other users may. I found no other problems with anything (regression or previously reported).

   I did find a new problem, however, that is unrelated to your fix: Dragging and dropping items from the TOC HUD when Track Changes is turned on should track the changes made by that action. Currently, the drag-drop does not add any CM marks at all. Although dragging a TOC header implies a large block of text being moved, it is still a change that should be tracked. Whether it can be with the limitations of CM is another question.

   All things considered, the goal of tracking changes in plain text only is a rather tall order, and MMC is doing quite well at it. These changes help a lot. Thanks!

   Smart Pairs

   The smart pairs functionality still doesn't work quite right. Here's the problem:

   Action	Result
   Type (	(^)
   Type 5	(5^)
   Hit del	(^)
   Hit del again	^)

   ( ^ represents insertion point.) The opening half is being deleted and the closing half is not. The closing mark should be removed with the opening mark.

   • CriticMarkup_highlighting.jpeg 110 KB
   • Edit

9. Support Staff 7 Posted by Fletcher on 10 Jun, 2013 12:50 AM

   

   > I was unable to delete empty {++}
   >

   I assume you meant `{++++}`? Just put your cursor inside and hit delete.

   Didn't think about the TOC…. Trying to manage that inside of Critic Markup is probably going to get too messy. I've disabled using the TOC to rearrange while Track Changes is on, as I agree it's best if all changes are tracked. Doing so will effectively disable syntax highlighting through large parts of the document.

   I'll think about whether there are better solutions, but this is probably stretching the bounds of CM. It's still possible to do this manually by cut and paste, or by using the "Compare to other file" feature as well.

   Thanks for your feedback.

   F-

   --
   Fletcher T. Penney
   Manager, Founder
   MultiMarkdown Software, LLC
   [email blocked]

   • smime.p7s 4.78 KB
   • Edit

10. 8 Posted by hal0 on 10 Jun, 2013 02:48 AM

    

    Yes, {++++}. I was attempting to delete from the front of it and from behind it, both of which failed. I didn't try from inside of it.

    That's probably the best thing to do about the TOC. The CM specs actually say that each change should "try" to be contained to one line, so accounting for a drag-drop in the TOC is technically outside the scope of its mission, but still should be either accounted for or disabled.

    Did you see the edit I made to my last reply regarding the smart pairs? These should probably be in different threads; sorry for that. I didn't think about it when I created the thread.

    • Edit

11. Support Staff 9 Posted by Fletcher on 10 Jun, 2013 04:35 PM

    

    Thanks for pointing out your edit --- those are easy to miss.

    Composer is not going to delete characters you don't tell it to delete unless you're deleting the first character of a smart pair immediately after typing it.

    There's nothing more frustrating to me than when editors won't let me delete one character because it's trying to be too clever. Once you type the 5, you "set" the smart pair and they are no longer treated as linked when deleting.

    • Edit

12. Fletcher closed this discussion on 10 Jun, 2013 04:35 PM.