#1001284 Code completion in pattern matching should offer parameter names as variable names where possible

[Simon Ochsenreither]

I would be interested in looking into that, could anyone give me some guidance how to approach it?

https://www.assembla.com/spaces/scala-ide/support/tickets/1001284-code-completion-in-pattern-matching-should-offer-parameter-names-as-variable-names-where-possible

[Simon Ochsenreither]

https://github.com/scala-ide/scala-ide/tree/master/org.scala-ide.sdt.core/src/scala/tools/eclipse/completion and
https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt.core/src/scala/tools/eclipse/ScalaPresentationCompiler.scala#L253
seem to be of interest. Anything else I'm missing?

[iulian dragos]

Hi Simon,

This is an ambitious ticket, and I don't have a clear path on how to best approach it. I can list a few things that could help you.

- the information you need (parameter names) is in the `Symbol` of the unapply method. You can access them by `sym.paramss` (a list of parameter lists), where each symbol has a name

- you must find a way to get from the completion position to the unapply symbol. Since most of the times you will have erroneous code (for instance, not enough arguments), the compiler may not be able to resolve it for you. You'll have to fiddle with positions and find what works.

- it may make sense to make completions insert parameter names for constructors as well (and apply methods): #1001272. This might alleviate problem 2 above

Don't hesitate to ask more questions, or post code that does not behave as expected. We'll try to help. 

Thanks for all the great work you're doing!

iulian

On Fri, Oct 19, 2012 at 11:58 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

I would be interested in looking into that, could anyone give me some guidance how to approach it?

https://www.assembla.com/spaces/scala-ide/support/tickets/1001284-code-completion-in-pattern-matching-should-offer-parameter-names-as-variable-names-where-possible

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

[iulian dragos]

On Tue, Oct 23, 2012 at 1:26 PM, iulian dragos <jagu...@gmail.com> wrote:

Hi Simon,

This is an ambitious ticket, and I don't have a clear path on how to best approach it. I can list a few things that could help you.

- the information you need (parameter names) is in the `Symbol` of the unapply method. You can access them by `sym.paramss` (a list of parameter lists), where each symbol has a name

You probably know about this already, but this is the interesting part for retrieving parameter names: https://github.com/scala-ide/scala-ide/blob/master/org.scala-ide.sdt.core/src/scala/tools/eclipse/ScalaPresentationCompiler.scala#L290

 

- you must find a way to get from the completion position to the unapply symbol. Since most of the times you will have erroneous code (for instance, not enough arguments), the compiler may not be able to resolve it for you. You'll have to fiddle with positions and find what works.

- it may make sense to make completions insert parameter names for constructors as well (and apply methods): #1001272. This might alleviate problem 2 above

Don't hesitate to ask more questions, or post code that does not behave as expected. We'll try to help. 

Thanks for all the great work you're doing!

iulian

On Fri, Oct 19, 2012 at 11:58 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

I would be interested in looking into that, could anyone give me some guidance how to approach it?

https://www.assembla.com/spaces/scala-ide/support/tickets/1001284-code-completion-in-pattern-matching-should-offer-parameter-names-as-variable-names-where-possible

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

[Simon Ochsenreither]

Hi!

Simon and I have been looking into it and we managed to figure out an “ad-hoc” way to do it: https://github.com/soc/scala-ide/commit/cd6df6148e2aaa0e90a1d2debdb79cb866350748

One issue which came up is how to properly tell apart the different types of completions required. In the commit above we abused ScopeMember, but I think it might make sense to create an UnapplyMember to disambiguate it properly and call some custom mkCompletionProposalForUnapply in that case (https://github.com/soc/scala-ide/commit/cd6df6148e2aaa0e90a1d2debdb79cb866350748#L0L72) instead.

One weird thing is that the AST changes from Select to something drastically different when the “extends” is added like in this example:

sealed trait Foo
case class Bar(str: String, int: Int) //extends Foo // <--- !!!

object Main extends App {
  val foo: Foo = ???
  foo match {
    case Bar(|)  // | is the position of the cursor when auto-completion is requested
  }
}

Any ideas why this happens?

Any suggestions what's the best way to structure the code?

Thanks!

Bye,

Simon & Simon

[Simon Ochsenreither]

Reworked PR: https://github.com/scala-ide/scala-ide/pull/475