Community
Participate
Working Groups
When the 'step into' menu bar action is selected, if there is a selection it should invoke 'step into selection' if the selection is in the same method as the executing context. This may be better than having an additional icon in the menu bar for 'step into selection'. Alternatively, alt-clicking on the 'step into' might perform a 'step into selection' instead.
(In reply to comment #0) > When the 'step into' menu bar action is selected, if there is a selection it > should invoke 'step into selection' if the selection is in the same method > as the executing context. I like that idea! > This may be better than having an additional icon > in the menu bar for 'step into selection'. Yes. I would not want to add more clutter to it. > Alternatively, alt-clicking on > the 'step into' might perform a 'step into selection' instead. Not sure what you wanted to say here. Ctrl+Alt click does exactly that.
(In reply to comment #1) > (In reply to comment #0) > > Alternatively, alt-clicking on > > the 'step into' might perform a 'step into selection' instead. > > Not sure what you wanted to say here. Ctrl+Alt click does exactly that. Ctrl+Alt on the text in the source does 'step into selection'. I was thinking about people using the 'step into' button on the toolbar; or does Ctrl+Alt on that toolbar button do a 'step into'? Having said that, if the selection present makes the 'step into' button do that anyway, the way that you click on the toolbar button becomes irrelevant anyway.
The Step Into and Step Into Selection commands must stay predictable. -1 for a magic change of behavior of "Step Into". I have "Step Into Selection" bound to F9, and I use both F5 and F9 depending on what I need. Taking away "Step Into" in some situations is a no-go. Adding a modifier for the toolbar button to change it to "Step Into Selection" would be fine, but it should be Ctrl (Mac: Command) for consistency with other action modifiers and because Alt+drag moves windows on Linux.
(In reply to comment #3) > The Step Into and Step Into Selection commands must stay predictable. > > -1 for a magic change of behavior of "Step Into". I have "Step Into > Selection" bound to F9, and I use both F5 and F9 depending on what I need. > Taking away "Step Into" in some situations is a no-go. Indeed. I'm not sure the modifier buys us something. I would expect that those who use the mouse (to click the button), would better use Alt+Ctrl+click then.
(In reply to comment #3) > The Step Into and Step Into Selection commands must stay predictable. > > -1 for a magic change of behavior of "Step Into". I have "Step Into > Selection" bound to F9, and I use both F5 and F9 depending on what I need. > Taking away "Step Into" in some situations is a no-go. > +1. Some of the debug commands are confusing enough, I don't want any more of them to behave differently based on workbench selections (see context launching). > Adding a modifier for the toolbar button to change it to "Step Into > Selection" would be fine, but it should be Ctrl (Mac: Command) for > consistency with other action modifiers and because Alt+drag moves windows > on Linux. We already do this for the launch toolbar: Ctrl + Click will create a new launch configuration (using context launching logic) and open the launch dialog on it - or just open the launch dialog if a config could not be created.
Removing milestone. I likely won't have time to do this for M7 as I just remembered that the entirety of the Step Into action code is in platform debug and the entirety of the Step Into Selection code is in JDT debug (as resolving the selection requires the Java model).
