idea to improve useability of refactoring features

+1

Norris Shelton
Sun Certified Java Programmer




Alex wrote:

>Not sure if anyone suggested this before, but here goes...
>
>I use the rename refactoring all the time; So much so that I have it bound
>to ALT-R. I also use about 50% of the other refactorings, but for those I
>always have to access the Refactor menu in the menubar of the right-click
>popup menu. The problem with that Refactor menu is that it is starting to
>become overwhelming with the number of options. What is confusing is that
>the Refactor menu is not contextual -- All the refactor choices are
>available even when they don't make sense. If you select a wrong item, it
>does display an error message.
>
>I would like the Refactor menu to dymamicaly disable items which
>are not valid for the current context. I suppose there may be a
>performance problem to doing this for the Refactor menu in the menubar but
>the right-click popup menu should be able to do this.
>
>What I really want is a new feature similar to the inline intention
>popups; This inline popup would display all the refactor commands which
>are valid for the current context: local variable, field, method, static
>method, class, expression, blocks of code, etc.
>
>For example, if you invoke it on a local variable in a method.
>[Rename]
>[Inline]
>[Introduce Field]
>[Introduce Constant] (if that is possible)
>[Introduce Parameter]
>[Replace temp with Query]
>
>If you invoke it on a method
>[Rename]
>[Change Signature]
>[Make Method Static] (if not static)
>[Convert to Instance Method] (if static)
>[Move] (if static)
>[Safe Delete]
>[Inline]
>
>This feature would make it much easier to understand which Refactorings
>are applicable in each context. Also, I would bind this inline popup
>command to a keybinding so that with two keybindings I have access to the
>Rename Refactoring (80%+ of my refactoring work) and then all the other
>refactorings through the inline Refactor Popup Menu.

>

There is a closely related Tracker item:

http://www.intellij.net/tracker/idea/viewSCR?publicId=4028

Just an idea: it could be a little bit too time-expensive to detect
available refactorings immediately. Also note, that the current behaviour
has one advantage: it shows an explanation, WHY something does not work.
With your suggestion it might happen, that one might wonder, why something
isn't available.

Tom

Johannes Graham wrote:

>There is a closely related Tracker item:
>http://www.intellij.net/tracker/idea/viewSCR?publicId=4028

>

It's been open for 2 years: be patient, or be vocal.

Alain

Thanks for looking that up.
That tracker#4028 is asking for the dynamically disabling the Refactor menu like I mentioned.
That feature is needed more so today because the number of refactorings continues to increase.

But an inline Refactor Popup that I really want would just show the valid choices similar to how intention inline popup works.

Imagine if you invoked the inline Intention popup, and a huge menu of Intentions popped up with all the invalid intentions for this context disabled (greyed out)!

Or Imagaine if the Intentions were only accessible from that bloated right-click Popup Menu:

Copy
Cut
Paste
-

Analyze--->
Refactor--->
Intentions--> Yuck!

-Alex

Hmmm, now that they've opened up the refactoring processors, this should be pretty straightforward to do as a plugin. Maybe I'll play around with this over Christmas break.

--Dave

Based on my intentions work, I can pretty much gaurantee that figuring out what refactorings are available is not too expensive.

--Dave Griffith

I really think it would not be very expensive. Most of the validity checks are just based whether it is a local variable/ field/ method / class, etc. In some cases, it matters whether it is static method or not, or etc. It doesn't seem any more expensive than Smart Completion or Intention inline popups.

I would much rather have IntelliJ be proactive and disable choices are not valid than let me select invalid choices and then have it tell me WHY I shouldn't have selected that. I think if someone is that curious, they should refer to the online help. The online help should explain the context required for each refactoring..

For my own use, I don't even care if they fix the menubar Refactor menu and right-click Refactor pull-right menu, because I've already figured out which applicable in which contexts, so it won't help me. I do think new users would benefit from disabling invalid choices, though.

What I really want is that inline Refactor popup menu because I can quickly access it with keyboard and it would work just like the Intention Popup (ALT+ENTER).

-Alex

Thomas Singer (MoTJ) wrote:

Also note, that the current behaviour has one advantage: it shows an explanation, WHY something does
not work. With your suggestion it might happen, that one might wonder,
why something isn't available.

What about taking a middle way?

One approach would be to take advantage of the fact that the refactoring
menu items do not have an icon. E.g. IDEA could show green tick if an
refactoring is available and red X if it's not, you could still click on
the unavailable refactorings and get short description. Or if it causes
too much clutter they can keep the active refactorings plain and add
subtle icon to the ones that are not available.

Finaly, IDEA could display the reason why a refactoring is unavailable
in the status bar (though this one has a problem that it's not very
visible.) And finaly, they could enable the tooltips only for the
disabled menu items (though this could be mighty annoying, anybody
remember OS 9's baloon help)?

cheers,
Dimitar

Please do. Could you also do this for the version control menu? Or
could someone give an option to hide unavailable options. Should be
pretty easy, since they are already grayed out.

Hmmm. Now that I think about it, I'm going to create an RFE to allow
hiding disabled options in the menu's. Maybe they can give the little
double arrow button like M$ that displays all options.

Norris Shelton
Sun Certified Java Programmer




Dave Griffith wrote:

>Hmmm, now that they've opened up the refactoring processors, this should be pretty straightforward to do as a plugin. Maybe I'll play around with this over Christmas break.
>
>--Dave

>

Maybe they can give the little
double arrow button like M$ that displays all
options.

OMG No! runs away shedding tears of desperation

Configurable. Look the RFE and see what I am talking about. They hide
the ones you haven't used in a while. I want to hide the ones that I
can't use anyway.

Norris Shelton
Sun Certified Java Programmer




Marcus Brito wrote:

>>Maybe they can give the little
>>double arrow button like M$ that displays all
>>options.
>>
>>
>
>OMG No! runs away shedding tears of desperation
>

>

"IDEA could show green tick if an refactoring is available..."

Friggin excellent idea! That is hot. I swear to you that my eyes are
trained to check the right scroll area for todos and warnings and errors.
Seeing little green opportunties to refactor would rock. Like you, I only
use a few refactorings regularly, only because it takes effort (however
small) to peek at the menu and hunt down a refactoring I want to apply.

About 3 months ago (?) I wrote a singleton by hand only to have a fellow
teammate show me that IDEA could do it in .5 seconds. I'm the IDEA
evangelist at the job and this guy is showing me stuff about the program.

So embarrassing.

:)


I hope the green tick idea gets implemented. What I'm finding is that I
really like IDEA when it tells me, without any effort on my part, what's
wrong with my code. Those little light bulbs that pop up every now and then
make me smile. When I have to hunt down functionality, well...let's just
say that those features dont get used, hence I probably only use about 40%
of the power of this product.

The productivity tips was a step in this direction, but you only see it once
on startup and you forget. The light bulbs are always in your face. Like
little mosquitos nibbling at you. I've developed a new fetish of trying to
ensure a clean right scroll bar area. No todos. No errors (obviously) and
no warnings. And I don't "cheat" by turning the warnings to "Do Not Show".
I want them to show. To remind me to clean up my act. To nag me in a
gentle and unobtrusive way. Whoever came up with the light bulb concept at
JB deserves a raise.

Maybe we'll get a green tick for Christmas. Good idea Tom. It'll make a
great IDEA.

:)



"dimiter" <dimiter@nos-pam.blue-edge.bg> wrote in message
news:cptdj1$b0d$1@is.intellij.net...

Thomas Singer (MoTJ) wrote:

Also note, that the current behaviour has one advantage: it shows an

explanation, WHY something does

not work. With your suggestion it might happen, that one might wonder,
why something isn't available.

>

What about taking a middle way?

>

One approach would be to take advantage of the fact that the refactoring
menu items do not have an icon. E.g. IDEA could show green tick if an
refactoring is available and red X if it's not, you could still click on
the unavailable refactorings and get short description. Or if it causes
too much clutter they can keep the active refactorings plain and add
subtle icon to the ones that are not available.

>

Finaly, IDEA could display the reason why a refactoring is unavailable
in the status bar (though this one has a problem that it's not very
visible.) And finaly, they could enable the tooltips only for the
disabled menu items (though this could be mighty annoying, anybody
remember OS 9's baloon help)?

>

cheers,
Dimitar

Btw, what I meant is the green tick to be shown as icons in the menu for
the items that will work in that location.

The problem it was intended to solve is that right now you get an
explanation box on the unavailable refactorings after you choose them
and after that you have to open the menu again, scan it to find the item
you want and hope that this one is available. The standard UI solution
for this is to disable the unapplicable items, but then we lose the
explanations and this could lead to rather frustrating experience.


-- dimitar

It's somewhat I do not understand completely.
Would you like a green lightbulb popping up on each identifier in the code
suggesting to rename it? Or change some method signature?
It doesn't look helpful IMO.

The only smarter capability comes in mind is automatic duplications finder
which would suggest method extracting or something like that.

Maxim Shafirov (JetBrains) wrote:

It's somewhat I do not understand completely. Would you like a green
lightbulb popping up on each identifier in the code suggesting to rename
it? Or change some method signature?
It doesn't look helpful IMO.

No, the suggestion has to do with the refactoring menu. To summarize:
If you place the caret on an identifier and you select the refactoring
menu, you get dozens of different refactorings with no easy way of
determining which ones are actually applicable at the current location.
If you select a refactoring from the menu, you might get an error
message.

There was a debate about this years ago, with the conclusion that you
didn't want to disable the menu items that were not available because
then there would be no way of finding out why a refactoring wasn't
available.

If you don't disable menu items that aren't available, but put a green
checkmark on those items that are available, then you get the best of
both worlds: It's easy for anyone to see in the menu which refactorings
are available at the current location, and if you want to see why a
refactoring isn't available, you can still just select an item without a
green checkmark and get the same error dialog that you do in the current
version of IDEA.

Jonas Kvarnström wrote:

>

No, the suggestion has to do with the refactoring menu. ..
.. put a green checkmark on those items that are available, then you
get the best of both worlds: It's easy for anyone to see in the menu
which refactorings are available at the current location, and if you
want to see why a refactoring isn't available, you can still just
select an item without a green checkmark and get the same error dialog
that you do in the current version of IDEA.

And the next logical step is to preselect the most logical/prefered
refactoring, based on simple rules:
ex:
Caret on static method name => convert to instance
Caret on id => rename
Caret next to '{' of anonymous class => "convert anonymous to inner"
Caret next to '{' of inner class => "Move"
etc..


That's the now 2-years old :
" 22 refactorings in menu : preselect most probable/gray out invalid
refactorings "
http://www.intellij.net/tracker/idea/viewSCR?publicId=4028

Alain