Re: [racket-dev] Survey for DrRacket users related to automatic parentheses behavior
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' ?).
Laurent
On Fri, Nov 23, 2012 at 1:20 AM, Nadeem Abdul Hamid nad...@acm.org wrote:
Hello all,
I've been discussing with Robby a possible improvement of DrRacket's
automatic parentheses behavior and would like to get a sense of others'
general opinion about this. What follows is a description of my proposal
and then some concrete questions.
;;
The idea is to have DrRacket automatically skip over
automatically-inserted closing parens if the user types one while the
cursor is right in front of one. (The Eclipse Java IDE does this with
various types of braces and parens, and in the past I've found this very
nice and have observed others (my students) interact well with such a
feature.)
A concrete example: suppose you are in the process of typing the
expression (+ 4 (- 1 2) 3). After you type the first opening
parentheses and the characters following it up to the 2, the expression
in the editor looks like:
(+ 4 (- 1 2|))
where the | represents the cursor's position. Note the two
automatically-inserted closing parens that are after the cursor right now.
With
the current implementation, you have to then use the right arrow key to
make the cursor skip past the first auto-inserted ) and then you can
type 3. However, that really disrupts the typing process because even
if you don't type a ) as a habit and then realize you have to delete the
extra one, you still have to lift and move your finger to the arrow keys
area of the keyboard or type some other key combination to skip the
cursor forward.
My proposal would be to have it so that if you type ) in the editor
state above, it becomes:
(+ 4 (- 1 2)|)
and now you continue typing a space and the 3. Of course, the same thing
should apply for other types of parens - ( [ { etc.
I don't know about others, but I actually get annoyed with the curent
automatic parens feature to the point of disabling it. That is, I like
the auto-parens feature not because it relieves me from having to type
closing parentheses - I don't mind that, and I actually tend to do that
automatically as I'm typing expressions; but the benefit is that it always
keeps parens balanced while I'm still in the middle of typing an
expression. However, with the current behavior, it tends to make me type
extra closing parentheses and have to go back and delete parens to balance
things up again.
;;
So, the questions:
1. Do you use the automatic parentheses feature of DrRacket?
2a. If yes, does the proposal above resonate well with you?
2b. And, do you think this smart skipping of auto-inserted closing
parentheses should become the intrinsic behavior of the automatic
parentheses mode, or should it be a separate preference? (i.e. have two
preference options - the current automatic parentheses one and then a
subordinate option that enables/disables this skipping over of
auto-inserted closing parentheses as the user types them)
3. If your answer to #1 is No, why not? (Is it because you find its
current behavior awkward in some way?)
Thanks,
nadeem
_
Racket Developers list:
http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Survey for DrRacket users related to automatic parentheses behavior
On Sat, Nov 24, 2012 at 4:03 AM, Laurent laurent.ors...@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? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Survey for DrRacket users related to automatic parentheses behavior
On Sat, Nov 24, 2012 at 3:11 PM, Nadeem Abdul Hamid nad...@acm.org wrote: On Sat, Nov 24, 2012 at 4:03 AM, Laurent laurent.ors...@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. Another idea could be to remove the closing paren of the enclosed s-expr automatically; but there may be some cases where this could lead to undesired behaviors. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Survey for DrRacket users related to automatic parentheses behavior
On Sat, Nov 24, 2012 at 8:53 AM, Laurent laurent.ors...@gmail.com wrote: On Sat, Nov 24, 2012 at 3:11 PM, Nadeem Abdul Hamid nad...@acm.org wrote: On Sat, Nov 24, 2012 at 4:03 AM, Laurent laurent.ors...@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
Re: [racket-dev] Survey for DrRacket users related to automatic parentheses behavior
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. On Saturday, November 24, 2012, Robby Findler wrote: On Sat, Nov 24, 2012 at 8:53 AM, Laurent laurent.ors...@gmail.comjavascript:; wrote: On Sat, Nov 24, 2012 at 3:11 PM, Nadeem Abdul Hamid nad...@acm.orgjavascript:; wrote: On Sat, Nov 24, 2012 at 4:03 AM, Laurent laurent.ors...@gmail.comjavascript:; 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
Re: [racket-dev] Survey for DrRacket users related to automatic parentheses behavior
On Sat, Nov 24, 2012 at 12:07 PM, Nick Shelley nickmshel...@gmail.comwrote: 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.ors...@gmail.com wrote: On Sat, Nov 24, 2012 at 3:11 PM, Nadeem Abdul Hamid nad...@acm.org wrote: On Sat, Nov 24, 2012 at 4:03 AM, Laurent laurent.ors...@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 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Survey for DrRacket users related to automatic parentheses behavior
On Sat, Nov 24, 2012 at 12:14 PM, Grant Rettke gret...@acm.org wrote: On Sat, Nov 24, 2012 at 11:07 AM, Nick Shelley nickmshel...@gmail.comwrote: I sort of like this behavior, and the visual difference gets rid of any potential confusion. Just an idea... you might duplicate Paredit's functionality: http://emacswiki.org/emacs/ParEdit It is way past beta and has probably gone through all of the pain of debating over points like this since a lot of people use it and have shared their feedback, too. I haven't really used ParEdit at all - just tried it out a little bit in the last couple of days - but it seems to be too much of a straitjacket to me (at least in its default, out-of-the-box settings)? It overrides/ignores too much of what I try to do in terms of typing (closing) parens, and it seems possible to get it in a state where parentheses don't match up, like ( ... ], and it's not immediately evident how to correct it conveniently because ParEdit neither lets me delete or change the ]. Additionally, it would be a big selling point for DrRacket to be able to offer Paredit equivelant functionality in addition to the other great stuff it already offers. Yes, or maybe, better-than-ParEdit functionality, :-P Racket Users list: http://lists.racket-lang.org/users _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Implementation of bit vectors
Hi All, I have written an implementation of bit vectors intended to be part of the data collection. https://github.com/plt/racket/pull/176 Any comments on the implementation and documentation are welcome. The bit vector is represented as a vector of fixnums (packaged in a struct of course). -- Jens Axel Søgaard _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Old pull requests on Github
Hi All, I notice that there a few old pull requests on Github without any form of comments. Even a we will look at this later comment looks better to out siders, than none at all. https://github.com/plt/racket/pulls Any thoughts? /Jens Axel _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [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 nad...@acm.org wrote: On Sat, Nov 24, 2012 at 12:07 PM, Nick Shelley nickmshel...@gmail.comwrote: 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.ors...@gmail.com wrote: On Sat, Nov 24, 2012 at 3:11 PM, Nadeem Abdul Hamid nad...@acm.org wrote: On Sat, Nov 24, 2012 at 4:03 AM, Laurent laurent.ors...@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 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
Yesterday, Neil Toronto wrote: Rho! Cute! (As much as I like using non-ascii in code now, having a useful Emacs hack to do that (ρ ρ ρ your ⊥), I think that there are a significant number of people who would just avoid using a library that requires them...) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
On Sat, Nov 24, 2012 at 6:41 PM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Neil Toronto wrote: Rho! Cute! (As much as I like using non-ascii in code now, having a useful Emacs hack to do that (ρ ρ ρ your ⊥), I think that there are a significant number of people who would just avoid using a library that requires them...) Yeah, it would have to be an alternate notation. But my emacs nowadays works fine with unicode (and I long ago gave up on trying to maintain an .emacs file so I just get the defaults). Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Square-bracket-sensitive macros in Scribble sandboxes
Just now, Robby Findler wrote: But my emacs nowadays works fine with unicode (and I long ago gave up on trying to maintain an .emacs file so I just get the defaults). Heh -- yes, it handles unicode fine, but the real problem is typing it. There are input modes that allow you to type greek or sgml or whatever, but they're inconvenient since you need to switch the input, type the letter you want, then switch back. (And each switch is some obscure three-part chord, IIRC.) I started with an attempt to mimic drracket's M-\ feature, and ended up with a neat solution: I have a key that switches to my input mode which works temporarily only for one character, and then you're back to the input you've used. So, for example, to type a λ in drr you'd use \LAMBDAM-\, and the equivalent with my thing is M-RETLAMBDA. The nice thing about it is that I can define multiple names for each thing, for example, in addition to rarr I also have the much-easier-to-remember - (or a more extreme case: vdash vs |-). It's easy enough that I just have \ produce a lambda so I don't even need a specific shortcut key for that (M-RET\ is almost as quick). I'd love to see something like that in drr, but I think that it might be too confusing since it already uses \. Besides, in drr it makes sense to just have something less sophisticated and rely on the OS/GUI to make such things easier system-wide, whereas in Emacs the result of all of this is that I can use my thing even in places like file names, or isearch. (Now all that's missing is a drracket-jr resurrection...) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Survey for DrRacket users related to automatic parentheses behavior
I agree with the proposal.
And source-code auto formtting is also useful.
2012. 11. 23. 오전 9:29에 Nadeem Abdul Hamid nad...@acm.org님이 작성:
Hello all,
I've been discussing with Robby a possible improvement of DrRacket's
automatic parentheses behavior and would like to get a sense of others'
general opinion about this. What follows is a description of my proposal
and then some concrete questions.
;;
The idea is to have DrRacket automatically skip over
automatically-inserted closing parens if the user types one while the
cursor is right in front of one. (The Eclipse Java IDE does this with
various types of braces and parens, and in the past I've found this very
nice and have observed others (my students) interact well with such a
feature.)
A concrete example: suppose you are in the process of typing the
expression (+ 4 (- 1 2) 3). After you type the first opening
parentheses and the characters following it up to the 2, the expression
in the editor looks like:
(+ 4 (- 1 2|))
where the | represents the cursor's position. Note the two
automatically-inserted closing parens that are after the cursor right now.
With
the current implementation, you have to then use the right arrow key to
make the cursor skip past the first auto-inserted ) and then you can
type 3. However, that really disrupts the typing process because even
if you don't type a ) as a habit and then realize you have to delete the
extra one, you still have to lift and move your finger to the arrow keys
area of the keyboard or type some other key combination to skip the
cursor forward.
My proposal would be to have it so that if you type ) in the editor
state above, it becomes:
(+ 4 (- 1 2)|)
and now you continue typing a space and the 3. Of course, the same thing
should apply for other types of parens - ( [ { etc.
I don't know about others, but I actually get annoyed with the curent
automatic parens feature to the point of disabling it. That is, I like
the auto-parens feature not because it relieves me from having to type
closing parentheses - I don't mind that, and I actually tend to do that
automatically as I'm typing expressions; but the benefit is that it always
keeps parens balanced while I'm still in the middle of typing an
expression. However, with the current behavior, it tends to make me type
extra closing parentheses and have to go back and delete parens to balance
things up again.
;;
So, the questions:
1. Do you use the automatic parentheses feature of DrRacket?
2a. If yes, does the proposal above resonate well with you?
2b. And, do you think this smart skipping of auto-inserted closing
parentheses should become the intrinsic behavior of the automatic
parentheses mode, or should it be a separate preference? (i.e. have two
preference options - the current automatic parentheses one and then a
subordinate option that enables/disables this skipping over of
auto-inserted closing parentheses as the user types them)
3. If your answer to #1 is No, why not? (Is it because you find its
current behavior awkward in some way?)
Thanks,
nadeem
Racket Users list:
http://lists.racket-lang.org/users
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] Closing pull requests
On Sunday, Neil Toronto wrote: How do I close pull requests made to the plt/racket repo on GitHub? Am I authorized to do that in the first place? You can't. The reason for this is that our github repo is just a mirror, and they don't have a way to let people edit issues and pull requests while forbidding them to push commits to the repo. (And if you do push something to the repo by mistake you'll probably kill the mirroring from our main repo if GH will reject the new pushes, or your changes will be lost if it will accept these pushes.) This was at least the case when I asked them about it a few months ago, and I don't think that they did anything new there. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
