[racket-dev] Survey for DrRacket users related to automatic parentheses behavior

> 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.

I understand if it's not worth implementing for complexity reasons. I was
just suggesting what I thought was a good visual solution to the potential
confusion caused by such hidden state.

And forgive me if this is an ignorant question since I have no idea what it
takes to implement something like this, but couldn't you just have the
state be tied to the specific closing paren character? If that were
possible, the state could just include whether it is temporary and which
opening paren it is linked to, and certain user actions change that state
to permanent or deleted. I don't see a need to track history. But again, I
have very little knowledge about this subject.


On Sat, Nov 24, 2012 at 12:16 PM, Nadeem Abdul Hamid <nadeem at acm.org> wrote:

> On Sat, Nov 24, 2012 at 12:07 PM, Nick Shelley <nickmshelley at gmail.com>wrote:
>
>> 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.
>>
>> I sort of like this behavior, and the visual difference gets rid of any
>> potential confusion.
>>
>
> 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.
>
>
>
>> On Saturday, November 24, 2012, Robby Findler wrote:
>>
>>> On Sat, Nov 24, 2012 at 8:53 AM, Laurent <laurent.orseau at gmail.com>
>>> wrote:
>>> >
>>> >
>>> >
>>> > On Sat, Nov 24, 2012 at 3:11 PM, Nadeem Abdul Hamid <nadeem at acm.org>
>>> wrote:
>>> >>
>>> >> On Sat, Nov 24, 2012 at 4:03 AM, Laurent <laurent.orseau at gmail.com>
>>> wrote:
>>> >>>
>>> >>> If you can, I think it would be a good idea to remove the paren pair
>>> if
>>> >>> the user deletes the opening paren he just typed by mistake. Undo
>>> should do
>>> >>> the same (which apparently it does not currently; missing
>>> >>> 'begin/end-edit-sequence' ?).
>>> >>
>>> >>
>>> >> Yeah, the undo behavior I've fixed. The first scenario you mention
>>> might
>>> >> be tricky - how do you distinguish between typing an open paren and
>>> then
>>> >> immediately deleting it vs. typing an open paren, making a bunch of
>>> other
>>> >> edits, and then coming back and deleting the open paren?
>>> >
>>> >
>>> > I think it would already be good enough to only consider the case
>>>  where the
>>> > user types the paren and wants to remove them immediately (e.g., he
>>> placed
>>> > them in the wrong place, or wanted square brackets instead, or just
>>> changed
>>> > his mind).
>>> > In the case of meanwhile edits, I don't think the user would bother
>>> deleting
>>> > the closing paren himself.
>>>
>>> I think that hidden state like this can lead to confusing behavior.
>>> Probably you want to have deleting a paren do the same thing,
>>> regardless of what the character most recently typed was.
>>>
>>> Robby
>>> _________________________
>>>   Racket Developers list:
>>>   http://lists.racket-lang.org/dev
>>>
>>
>> _________________________
>>   Racket Developers list:
>>   http://lists.racket-lang.org/dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20121124/dcfa79e3/attachment.html>