[slime-devel] [RfC] SPC vs. RET in Xref Buffers
Hi, In XREF buffers, pressing RET will open the definition at point in the buffer where you originally issued the xref command, but let the XREF buffer open and let point still be in there. Pressing, SPACE will bring one to the definition at point, but will also close the XREF buffer. I never get that right, so I'd like to swap the key bindings, as this makes more sense to me (and is what I want more often in my experience.) Anyone's muscle memories against that? -T.
The way the XREF buffer works wrt. emacs windows has always seemed a little strange to me. When you M-. and go straight to a function definition (for example), the source file opens in the same window you were in when you hit M-. The XREF buffer opens in another one (the opposite one if you work with two windows side by side, as I do). That's not bad by itself, but pressing SPACE on one of the definitions has the nasty side-effect of ruining my window layout. It replaces both windows with one to display the source file. So if I just want to go to a particular definition's source file, I either have to accept that and reset my windows by hand, or press ENTER, kill the XREF buffer, and switch to the other window with the source buffer. Am I missing something? It seems like other people would be experiencing this more often, but I've never heard anyone complaining.... -Andrew On Aug 8, 2008, at 4:35 PM, Tobias C. Rittweiler wrote:
Hi,
In XREF buffers, pressing RET will open the definition at point in the buffer where you originally issued the xref command, but let the XREF buffer open and let point still be in there.
Pressing, SPACE will bring one to the definition at point, but will also close the XREF buffer.
I never get that right, so I'd like to swap the key bindings, as this makes more sense to me (and is what I want more often in my experience.)
Anyone's muscle memories against that?
-T.
_______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
Andrew Gasparovic <andrew@andrewgasparovic.com> writes:
The way the XREF buffer works wrt. emacs windows has always seemed a little strange to me. When you M-. and go straight to a function definition (for example), the source file opens in the same window you were in when you hit M-. The XREF buffer opens in another one (the opposite one if you work with two windows side by side, as I do).
That's not bad by itself, but pressing SPACE on one of the definitions has the nasty side-effect of ruining my window layout. It replaces both windows with one to display the source file. So if I just want to go to a particular definition's source file, I either have to accept that and reset my windows by hand, or press ENTER, kill the XREF buffer, and switch to the other window with the source buffer.
I always work with two frames side by side. That said, I believe SPACE should now work a bit better even with your setup.
Am I missing something? It seems like other people would be experiencing this more often, but I've never heard anyone complaining....
In the long run, I'd like to have `C-u q' always restore the window configuration (not there yet), and `C-x k' never (where it's still made sure that potential cleanup functions are run) across all relevant buffers. `q' restores the window configuration only if it hasn't changed meanwhile. This works quite reasonable when you use frames, not so much when you use a horizontally split windows, I guess. Anyway, if the abovely pictured scheme is in place, you'll have full control over it. -T.
On Aug 8, 2008, at 6:57 PM, Tobias C. Rittweiler wrote:
Andrew Gasparovic <andrew@andrewgasparovic.com> writes:
The way the XREF buffer works wrt. emacs windows has always seemed a little strange to me. When you M-. and go straight to a function definition (for example), the source file opens in the same window you were in when you hit M-. The XREF buffer opens in another one (the opposite one if you work with two windows side by side, as I do).
That's not bad by itself, but pressing SPACE on one of the definitions has the nasty side-effect of ruining my window layout. It replaces both windows with one to display the source file. So if I just want to go to a particular definition's source file, I either have to accept that and reset my windows by hand, or press ENTER, kill the XREF buffer, and switch to the other window with the source buffer.
I always work with two frames side by side. That said, I believe SPACE should now work a bit better even with your setup.
Am I missing something? It seems like other people would be experiencing this more often, but I've never heard anyone complaining....
In the long run, I'd like to have `C-u q' always restore the window configuration (not there yet), and `C-x k' never (where it's still made sure that potential cleanup functions are run) across all relevant buffers.
`q' restores the window configuration only if it hasn't changed meanwhile. This works quite reasonable when you use frames, not so much when you use a horizontally split windows, I guess. Anyway, if the abovely pictured scheme is in place, you'll have full control over it.
That seems to be a pretty good compromise, actually, for people using side-by-side windows. Pressing RET in the XREF buffer (or SPACE in the future, I guess) to go to a definition, immediately followed by a 'q', closes the XREF buffer, leaves the windows alone, and leaves the point on the definition selected. I can live with that.... Thanks! -Andrew
-T.
_______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
Andrew Gasparovic <andrew@andrewgasparovic.com> writes:
That seems to be a pretty good compromise, actually, for people using side-by-side windows. Pressing RET in the XREF buffer (or SPACE in the future, I guess) to go to a definition, immediately followed by a 'q', closes the XREF buffer, leaves the windows alone, and leaves the point on the definition selected. I can live with that....
That's how it should work now already (in CVS even for side-by-side windows.) And pressing SPACE is a shortcut for RET + q already. -T.
On Aug 10, 2008, at 7:33 PM, Tobias C. Rittweiler wrote:
Andrew Gasparovic <andrew@andrewgasparovic.com> writes:
That seems to be a pretty good compromise, actually, for people using side-by-side windows. Pressing RET in the XREF buffer (or SPACE in the future, I guess) to go to a definition, immediately followed by a 'q', closes the XREF buffer, leaves the windows alone, and leaves the point on the definition selected. I can live with that....
That's how it should work now already (in CVS even for side-by-side windows.) And pressing SPACE is a shortcut for RET + q already.
Really? Is that a recent thing? My slime from the middle of June keeps my window arrangement if I do RET + q, but it basically does a C-x 0 if I hit SPACE. -Andrew
-T.
_______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
Andrew Gasparovic <andrew@andrewgasparovic.com> writes:
That's how it should work now already (in CVS even for side-by-side windows.) And pressing SPACE is a shortcut for RET + q already.
Really? Is that a recent thing? My slime from the middle of June keeps my window arrangement if I do RET + q, but it basically does a C-x 0 if I hit SPACE.
Yeah, I fixed it on behalf of your report (as I mentioned in my first reply, in fact.) :-) -T.
* Tobias C. Rittweiler [2008-08-08 22:35+0200] writes:
Hi,
In XREF buffers, pressing RET will open the definition at point in the buffer where you originally issued the xref command, but let the XREF buffer open and let point still be in there.
Pressing, SPACE will bring one to the definition at point, but will also close the XREF buffer.
I never get that right, so I'd like to swap the key bindings, as this makes more sense to me (and is what I want more often in my experience.)
Anyone's muscle memories against that?
What I'd like is this: M-. then RET to read the code and then q to return to where I started. I think that I like the current bindings better. Helmut.
participants (3)
-
Andrew Gasparovic -
Helmut Eller -
Tobias C. Rittweiler