This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 108966 - Code completion inserts unwanted parens
Summary: Code completion inserts unwanted parens
Status: NEW
Alias: None
Product: ruby
Classification: Unclassified
Component: Code Completion (show other bugs)
Version: 6.x
Hardware: PC Windows Vista
: P3 blocker (vote)
Assignee: issues@ruby
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-05 19:05 UTC by jamespb
Modified: 2011-01-28 20:10 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jamespb 2007-07-05 19:05:11 UTC
Hit control-space to get a code completion window, choose a method with arguments.

NetBeans inserts a call with parens; if you choose a_method, it inserts a_method().  The parens should be optional. 
Ruby doesn't require them (parens in method calls are just there to resolve ambiguity), and whether or not to include
them is a code style choice.

As you can probably guess, I'm on the side that says inserting parens in a method call should only be done when
necessary.  Most calls should look like

a_method :foo => 3, :bar => 7 # Looks good

not

a_method(:foo => 3, :bar => 7) # Ugly, written by a Java refugee
Comment 1 Torbjorn Norbye 2007-07-06 23:14:03 UTC
I have code in there which tries to be smart about it.

If you select a method whose documentation refers to the method without parentheses, I will do the same thing when inserting the method call. For 
example, in a Rails controller file, if you choose for example the "render" method, it will insert render along with the parameter list, without parentheses.

I was defaulting to using parentheses in other scenarios, since it seemed to be the convention used in the Ruby libraries - and also because I've read 
various warnings here and there about the pitfalls of skipping parentheses.  That may not be as important in the IDE since you get an underline warning 
telling you about ambiguous constructs where parentheses are required.

One thing I had never seen before until I saw your screenshot, was skipping parentheses in the method signature itself. (For example, ActionController's 
Base definition has an rdoc which lists the render method without parentheses, but the method definition itself is using it).

This might be an additional clue I can use to decide whether to use parentheses or not: If the documentation suggests I should skip parens, skip parens. 
Else if the method definition is skipping parens, skip parens. Else use them.

Perhaps the most flexible solution would be to add a user-configurable option:

Use parentheses:
* Smart
* Always
* Never, unless ambiguous
* Never Ever

(We probably don't need the last one)

"Smart" would be the behavior I'm describing above, where it chooses parens based on the method definitions own usage or documentation.
Always is self explanatory.  "Never, unless ambiguous" would always prefer spaces, unless it would result in an ambiguous construct (e.g. if you for 
example have one method call inside another). 

How does that sound?

I'm a bit reluctant to add new options since lots of people don't use them; the default has to work well. Also, we've traditionally had too many options and 
we're trying to clean up usability a bit so I want to make sure that we only add knobs that we truly expect developers to want to turn.  But this one might be 
worthy of one since it does seem like a stylistic choice.
Comment 2 jamespb 2007-07-06 23:59:26 UTC
My guess would be that you're not going to be successful by looking at either the def itself or the documentation, since
you'd also need to know whether the method I'm calling is one of ours (and would follow our coding conventions) or an
external library (in which case, I don't care how they think it should be used, I want it without parens).

I like the user-configurable option.

My inclination would be to say that it's a dumb switch; you either get parens, or you don't.  The 80% of the people who
want them will never turn it off, and the rest of us aren't bothered by typing them occasionally.

I'd also say that you're right to be concerned about too many options.  And more ruby styles use parens than not.
Comment 3 Torbjorn Norbye 2007-07-09 20:05:55 UTC
I've started some work on this. It's not hooked up to a user-visible option yet.

But if you run with -J-Druby.complete.spaces=true (or add to netbeans.conf/nbruby.conf as appropriate in your userdir) it should try to use spaces for code 
completion instead of parentheses.  It does however look at the AST around the call, and if it looks like the call is inside another call, it will use parentheses 
(to avoid ambiguity - ruby would generate warnings if it didn't do this.)

I'm leaving the issue open to track actually making this a user visible option and perhaps tweak the behavior.

I'm not sure just checking for a surrounding call is right; that's also going to force parentheses in case where the call is on a previous line, which perhaps is a 
case where parens can be avoided? If this is a common scenario I should improve the ambiguity-detection.
Comment 4 Torbjorn Norbye 2007-10-12 21:54:14 UTC
It's too late to add a UI for controlling these settings in 6.0.

However, I've made some changes lately which will hopefully make this a little bit less severe than it used to be.

For various methods that provide documentation which uses the method without parentheses, it also avoids parentheses.
Thus, for many of the Rails DSL methods, NetBeans will also avoid parens.  There's also code completion for various
methods that offer hash keys (such as the various ActiveRecord methods, various ActionView and ActionController methods
etc) and in these scenarios NetBeans doesn't insert the method signature at all.

We still need to offer a way to really force parenthesis handling one way or the other regardless of the documentation
conventions (surprisingly, the ActiveRecord "create_table" method for example is described using parentheses - perhaps
an old style?) but I'm hoping that with my code completion fixes this is a bit less severe and we can live with this for
6.0.