<div class="gmail_extra"><div>On Sat, Nov 24, 2012 at 12:07 PM, Nick Shelley <span dir="ltr"><<a href="mailto:nickmshelley@gmail.com" target="_blank">nickmshelley@gmail.com</a>></span> wrote:<br></div><div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For what it's worth, Xcode differentiates these cases by inserting a temporary closing paren that is gray instead of black. You can make it permanent by arrowing over it, typing it yourself, tabbing over it, or just moving the cursor outside the matching parens. When it becomes permanent it is black like the other text and you have to delete it individually, but while it is still gray it will be deleted automatically if you delete the opening paren.<div> <br></div><div>I sort of like this behavior, and the visual difference gets rid of any potential confusion.</div></blockquote><div><br></div><div>Yes, I believe Eclipse does something like this too, maybe not with such a visual sort of indication. I agree that it's very cool functionality but it requires really thorough tracking of some hidden state as Robby says (history of the users' key and/or mouse interaction) and I don't think I'm going to go for this right now.</div> <div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div><div class="h5">On Saturday, November 24, 2012, Robby Findler wrote:<br></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"> On Sat, Nov 24, 2012 at 8:53 AM, Laurent <<a>laurent.orseau@gmail.com</a>> wrote:<br> ><br> ><br> ><br> > On Sat, Nov 24, 2012 at 3:11 PM, Nadeem Abdul Hamid <<a>nadeem@acm.org</a>> wrote:<br> >><br> >> On Sat, Nov 24, 2012 at 4:03 AM, Laurent <<a>laurent.orseau@gmail.com</a>> wrote:<br> >>><br> >>> If you can, I think it would be a good idea to remove the paren pair if<br> >>> the user deletes the opening paren he just typed by mistake. Undo should do<br> >>> the same (which apparently it does not currently; missing<br> >>> 'begin/end-edit-sequence' ?).<br> >><br> >><br> >> Yeah, the undo behavior I've fixed. The first scenario you mention might<br> >> be tricky - how do you distinguish between typing an open paren and then<br> >> immediately deleting it vs. typing an open paren, making a bunch of other<br> >> edits, and then coming back and deleting the open paren?<br> ><br> ><br> > I think it would already be good enough to only consider the case where the<br> > user types the paren and wants to remove them immediately (e.g., he placed<br> > them in the wrong place, or wanted square brackets instead, or just changed<br> > his mind).<br> > In the case of meanwhile edits, I don't think the user would bother deleting<br> > the closing paren himself.<br> <br> I think that hidden state like this can lead to confusing behavior.<br> Probably you want to have deleting a paren do the same thing,<br> regardless of what the character most recently typed was.<br> <br> Robby<br></div></div><div class="im"> _________________________<br> Racket Developers list:<br> <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a><br> </div></blockquote></div></div> <br>_________________________<br> Racket Developers list:<br> <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a><br> <br></blockquote></div><br></div>