tag:support.multimarkdown.com,2013-02-12:/discussions/betas/174-tocMultiMarkdown Software, LLC: Discussion 2018-10-19T08:27:39Ztag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-05T19:50:30Z2017-09-05T19:50:31ZTOC<div><p>And this just happened, which I consider a more serious bug. (Still B31.)</p>
<p>I closed everything in the TOC sidebar down to level 1. I clicked on one of the level 1's and moved it up in the document. It immediately <strong><em>fully opened</em></strong> everything in the sidebar again. Urgh! What's up with that?</p>
<p>I can see it opening a (single) level 1 if I hovered over it so I could move it within that level 1's structure, but I didn't — it stayed at level 1. There was no reason to open anything, much less everything.</p></div>Vincetag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-05T19:51:45Z2017-09-05T19:51:45ZTOC<div><ol>
<li>
<p>Can you send a video? I can't reproduce this no matter what I try.</p>
</li>
<li>
<p>I'll look back at this -- I had code that handled some of this<br>
before, but I apparently didn't migrate it to v4. I probably <em>will</em> get<br>
this done for 4.0.</p>
</li>
<li>
<p>As you noted -- Cmd-1 goes the left sidebar. Tab from there will<br>
take you the search box. Cmd-F always searches text.</p>
</li>
</ol></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-05T19:59:54Z2017-09-05T19:59:55ZTOC<div><p>Yes, I'll send a video (it just did it again), but it will have to be tonight. And while I'm at it I hope I can show you that although I move it that level 1 to be between two other level 1's, it's splitting the text of the first level 1.</p>
<h1><a name="topic-a" class="anchor" href="#topic-a"></a>Topic A</h1>
<h1><a name="topic-b" class="anchor" href="#topic-b"></a>Topic B</h1>
<p>…</p>
<h1><a name="topic-g" class="anchor" href="#topic-g"></a>Topic G</h1>
<p>That's the way the sidebar looks — everything is closed to level 1. I click and grab Topic G, move it until the horizontal cursor is between A and B, and drop it. And it does drop in between, but some of the text of Topic A are now after Topic G, and everything is open.</p>
<p>Ahh, tab. That makes sense. Two keystrokes to search instead of one, but that's livable.</p>
<p>Oh, wait, I just realized. You replied 1.2.3 like my original email, but you replied to my second email. What can't you replicate — the cursor changing to text, or the TOC opening everything when I move something?</p></div>Vince Ricetag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-05T20:42:23Z2017-09-05T20:42:23ZTOC<div><p>The TOC <em>should</em> open if needed while dragging (e.g. to drop inside a<br>
parent between two children).</p>
<p>It currently <em>does</em> open after a drop, but that's because it currently<br>
always expands when the text has been changed and the TOC refreshes<br>
(that's the part I have to look back at).</p>
<p>What I can't replicate is cursor.</p>
<p>Weird -- now I can. I couldn't make it change to insertion caret for<br>
anything, but now I can. I'll try to look at this some time, but<br>
honestly it will be very low on the list.</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-05T20:52:48Z2017-09-05T20:52:49ZTOC<div><blockquote>
<p>The TOC <em>should</em> open if needed while dragging (e.g. to drop inside a parent between two children).</p>
</blockquote>
<p>Yes, I understand that, and said it should. That's not what I'm doing, though. (And, for the record, it should only "hinge" open, i.e. open while we're hovering over it and/or when we drop it. If we change our mind while we're still hovering and move on to somewhere else, it should close again.)</p>
<blockquote>
<p>It currently <em>does</em> open after a drop, but that's because it currently always expands when the text has been changed and the TOC refreshes (that's the part I have to look back at).</p>
</blockquote>
<p>That's what I'm talking about. So I'll await your looking. :)</p>
<blockquote>
<p>Weird -- now I can. I couldn't make it change to insertion caret for anything, but now I can. I'll try to look at this some time, but honestly it will be very low on the list.</p>
<p>Right, that's why I said it was an aesthetic problem. :)</p>
</blockquote></div>Vince Ricetag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-05T21:53:56Z2017-09-05T21:54:32ZTOC<div><p>b33 fixes some issues related to proper positioning of text during drag/drop (there was a loophole in the previous fix for character/byte offsets)</p>
<p>The open/close part is coming. (I try to prioritize any fixes that could potentially cause data loss)</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-05T22:04:48Z2017-09-05T22:04:48ZTOC<div><p>Awesome, look forward to it; I had to resort to cutting/pasting in the editor section for now, it was causing too many problems in TOC.</p>
<p>Here's another aesthetic one you won't care about for initial release (and maybe not at all :); I'll send some screen prints if you care and can't duplicate it.</p>
<p>Opening the TOC causes some artifacts to appear on the editor side of the splitter between editor and preview. The artifacts appear to be the first few (2-3?) pixels from the first character on each line in the Preview. The Preview itself is fine (IOW the pixels aren't missing there), they appear to be just leftover artifacts from moving the Preview when the TOC opened.</p>
<p>To see it, open a document (better if it's at least a full-screen worth, and that editor/Preview are in sync). The line dividing editor/preview is pristine. Open the TOC. That line now has very small artifacts just inside the left (editor) portion of that line all the way up and down it. It's only a couple of pixels, and it's only on the rows that have characters in Preview; blank lines in Preview obviously don't leave any artifacts. Closing the TOC returns the line to pristine condition. Repeatable every time the TOC is opened/closed.</p></div>Vince Ricetag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-05T22:10:54Z2017-09-05T22:10:54ZTOC<div><p>I can't replicate that, and have never seen it in the thousands of times I have toggled preview/TOC/etc.</p>
<p>I'll probably need a video on this one, a static image probably won't help tell me much about what's going on (but if a screen shot is faster I can start there).</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-06T01:03:01Z2017-09-06T01:03:01ZTOC<div><p>The expansion issue is fixed -- the code I mentioned was in fact there. The preference to turn it off was not. ;)</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-06T04:06:02Z2017-09-06T04:06:03ZTOC<div><p>You should by now — I'm special, things happen to me that never happen. :)</p>
<p>Video uploaded. This is on a late 2013 MBP Retina using the built-in graphics.</p>
<p>On my this year's iMac, I haven't yet gotten the artifacts leftover. However, I can see them appear and disappear in the transition.</p></div>Vince Ricetag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-06T10:13:19Z2017-09-06T10:13:19ZTOC<div><p>Hmmm.... Definitely have never seen that.</p>
<p>After artifacts appear, what happens when you scroll? Do they track with scrolling or remain static (or disappear)? If they track, do they track with preview or with editor?</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-06T15:32:05Z2017-09-06T15:32:06ZTOC<div><p>Now on B36 (I know it doesn't matter for this, just noting the change.)</p>
<p>They remain static, no matter which side is scrolled; it's like they're part of the splitter (hmm, that gives me an idea…). They also remain present after alt-tabbing away from MMD and back to it.</p>
<p>The idea: move the splitter (between editor/preview) and see what happens. Very interesting. Sometimes that makes the artifacts go away, sometimes that makes them appear. So, e.g. if they're already visible, I've been able to move the splitter and make them disappear, i.e. they're no longer present when I release it. But other times, when they're not visible, I can move the splitter and make them appear, i.e. they're present after I release it. And I've gotten them moving it both directions, which puts the kabosh on a theory I had (that they only appear when moving to the right).</p>
<p>So, not unique to TOC (that's just where I saw it first), I've now had it happen when moving the splitter, as well as messing with the other sidebars (CriticMarkup, Reference).</p></div>Vince Ricetag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-06T15:50:17Z2017-09-06T15:50:17ZTOC<div><p>So it sounds like something is making the splitter "dirty" (term used when a particular rectangle on screen has been modified and needs to be redrawn) and the splitter is not recognizing the need to redraw that rectangle?</p>
<p>Just to confirm I'm not missing anything:</p>
<p>1) The artifacts are always within that 1 pixel line (2 on retina displays)?</p>
<p>2) They do not interfere with the editor or preview, per se?</p>
<p>3) The issue is purely cosmetic?</p>
<p>4) If I understand correctly, the issue appears on your Retina computer, but not the non-retina computer? I don't have a retina Mac, only retina iPad/iPhones and resizing the splitter doesn't work on touch screens (not yet) and I don't have any sidebars implemented on iOS to toggle on/off.</p>
<p>I tried increasing the thickness of the divider to 10 pixels, and still did not see anything.</p>
<p>As long as this is purely cosmetic, I'm going to let it go for now. I am thinking about rewriting the code I use to layout the GUI, which would replace what I use now. If I do that, this issue would likely disappear. However, rewriting this is not something I want to do before releasing 4.0, and it would make more sense to rewrite as I get further along in iOS development (what I use works fine on iOS, but I want to experiment with some other ideas).</p>
<p>Am I missing anything?</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-06T16:17:12Z2017-09-06T16:17:12ZTOC<div><p>?? iOS? There's an app for iOS? How did I miss that? I just looked on the store and didn't see anything.</p>
<ol>
<li>I am not smart enough to know how many pixels are displaying. Nor do I have any non-retina displays. I would guess it's 1-4 pixels, but that's all it would be, a guess.<br></li>
<li>No. As I said at the beginning, aesthetic.<br></li>
<li>Yes.<br></li>
<li>No, both of my computers are retina. But I haven't had the issue yet on the iMac, although as I said, I can see the artifacts as it moves, they just don't happen to stick on the iMac. (At least in my admittedly small testing sample there.)</li>
</ol>
<p>I'm fine with not worrying about it, I only reported it to be thorough, and because sometimes small things like indicate bigger problems behind the scenes.</p></div>Vince Ricetag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-06T16:21:31Z2017-09-06T16:21:31ZTOC<div><p><em>I</em> have an iOS app, it's not ready for use or sale though (it's basically the editor, preview, and info bar (word count, etc) but no<br>
"wrapper" that does everything else (files, save, open, print, sync, etc.).</p>
<p>Right now it's just proof of concept that the editor works, and helps<br>
provide me with another way of bug checking.</p>
<p>I had a beta iOS app back in 2012 or so(?) but wasn't happy with it and<br>
didn't have time to work on it after Composer 2, then 3, for the Mac.</p>
<p>But it will move back up the priority list once the macOS version is<br>
"finished."</p>
<ol>
<li>The divider is set to 1 pixel, but that should be doubled to 2 pixels<br>
on Retina display automatically.</li>
</ol>
<p>In this instance, this should not (never say never, and all that) be<br>
related to any bigger issue.</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-06T19:27:48Z2017-09-06T19:27:49ZTOC<div><p>Ahhh. Well, I look forward to the Testflight invitation for that. :)</p>
<p>Just to confirm your suspicions, here's a screen print I took of a very small section of the bar with the artifacts. They do all seem to be one or two pixels wide (I just loaded it in Preview and then zoomed way in.)</p></div>Vince Ricetag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-06T20:00:34Z2017-09-06T20:00:34ZTOC<div><p>Interesting -- it's one pixel wide, and I would have expected it to be<br>
two pixels wide on a retina display. I'll play around and see if I can<br>
make it 2 pixels wide on retina displays -- maybe that will help both<br>
issues?</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-06T20:12:57Z2017-09-06T20:12:57ZTOC<div><p>Did you see my other email/video? :) How wide's the one between TOC and Editor? 'Cause I get a splitter cursor there.</p>
<p>But I assume it can't hurt, and is probably the right thing to do, regardless.</p></div>Vince Ricetag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-06T20:18:04Z2017-09-06T20:18:04ZTOC<div><p>They are built using the same code, so same thickness -- it's hardcoded<br>
in and I don't change that, except to 0.0 when a view is toggled off.</p>
<p>But I <em>was</em> able to replicate the artifact in fake retina mode on my<br>
laptop, so next build will use thicker divider if a retina display is<br>
detected.</p>
<p>We'll see whether that helps one or both issues.</p>
<p>F-</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-06T20:42:23Z2017-09-06T20:42:24ZTOC<div><p>But now that I look at it more closely, the one between TOC and editor (in my case, technically between TOC and line numbers) does look wider than the one between editor and Preview. So maybe that does the solve at least the "can't get splitter cursor" problem. Might solve the other, too, but I can't imagine it would make it worse. (He says confidently like he knows what he's talking about.)</p>
<blockquote>
<p>On Sep 6, 2017, at 3:12 PM, Vince Rice <a href="mailto:vrice@solidrocksystems.com">vrice@solidrocksystems.com</a> wrote:</p>
<p>Did you see my other email/video? :) How wide's the one between TOC and Editor? 'Cause I get a splitter cursor there.</p>
<p>But I assume it can't hurt, and is probably the right thing to do, regardless.</p>
<blockquote>
<p>On Sep 6, 2017, at 3:00 PM, Fletcher > wrote:</p>
</blockquote>
</blockquote></div>Vince Ricetag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-06T20:58:55Z2017-09-06T20:58:55ZTOC<div><p>Apple's developer site is down, so I can't sign and release a new build.<br>
(Who knew that Xcode needs the web site in order to be able to manage that...)</p>
<p>Will try again this evening.</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-07T01:41:12Z2017-09-07T01:41:12ZTOC<div><p>Apple back up, update pushed.</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-07T01:53:45Z2017-09-07T01:53:45ZTOC<div><p>It does seem to help with the splitter cursor showing up between editor/preview, and I haven't so far been able to coax any artifacts from sticking around.</p>
<p>The issue with the splitter cursor sticking over the TOC didn't change, though.</p>
<p>But still, two out of three ain't bad!</p></div>Vince Ricetag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-07T01:54:37Z2017-09-07T01:54:37ZTOC<div><p>I was only hoping for two, so two out of two is great!!</p>
<p>;)</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-07T17:57:10Z2017-09-07T17:57:10ZTOC<div><p>Is the expanding/collapsing behavior doing better for you? (I assume you turned <em>off</em> the preference forcing expand always)</p></div>Fletchertag:support.multimarkdown.com,2013-02-12:Comment/433678882017-09-07T19:08:53Z2017-09-07T19:08:54ZTOC<div><p>Yes! Although I didn't have to uncheck it — it was already unchecked. (It took me a while to find it intially, being under "Advanced Preview Preferences" and having nothing to do with Preview. :)</p>
<p>And I haven't had further issues with dropping things in the middle of text, either.</p>
<p>Another two for two!</p></div>Vince Rice