GSoC ideas

[Michael Holzer]

Hi everyone!

I'm thinking about applying for this year's GSoC doing some Scala
IDE-related work. I checked the ideas page but found no projects related
to the Scala IDE, so I'll just throw out some of my thoughts:

* Scaladoc/Javadoc
- (IIRC there has once been some work on this - however nothing seems to
have made it into a release)
- Display the associated Scaladoc/Javadoc when hovering over e.g. a
class or method definition (as one is used to from Java).
- Display the associated Scaladoc/Javadoc for completion proposals (as
one is used to from Java).
- Support for writing Scaladoc comments (again - as one is used to from
Java for Javadoc), e.g. when typing "/**" + 'enter' over a method
definition provide empty tags for all method parameters.

* Refactorings
- Make refactorings (especially Rename) cross language boundaries (I've
seen this issue assigned to Mirko, but I don't know if there has been
any progress on it yet), this means:
- Participate in Java refactorings
- Trigger Java refactorings for refactorings initiated on the Scala side
- Extend refactoring support to Play templates and route files in the
Play plugin

* Developer plugin
I remember some talk about creating a developer plugin providing some
tools for working on Scala, though I can't find anything on it now.
- An AST view visualising the AST generated by the compiler for the
current file or some highlighted class/method.

* Miscellaneous
- Warn about unused variables (this could have saved me quite some
trouble already ;)
- Quickfixes for typos, i.e. suggest similarly named variables if the
named variable doesn't exist.


I know this are just a bunch of partially unrelated features, but I hope
I'll be able to turn (parts of) it into a nice proposal.

What do you guys think about it? Of course I also welcome any additional
ideas :)

Thanks in advance for any feedback!
michael

[iulian dragos]

Hi Michael,

It's great to see interest in GSoC for the IDE! I'll reply inline.

On Tue, Apr 9, 2013 at 5:23 PM, Michael Holzer <michi_ho...@gmx.at> wrote:

Hi everyone!

I'm thinking about applying for this year's GSoC doing some Scala
IDE-related work. I checked the ideas page but found no projects related
to the Scala IDE, so I'll just throw out some of my thoughts:

* Scaladoc/Javadoc
- (IIRC there has once been some work on this - however nothing seems to
have made it into a release)
- Display the associated Scaladoc/Javadoc when hovering over e.g. a
class or method definition (as one is used to from Java).
- Display the associated Scaladoc/Javadoc for completion proposals (as
one is used to from Java).
- Support for writing Scaladoc comments (again - as one is used to from
Java for Javadoc), e.g. when typing "/**" + 'enter' over a method
definition provide empty tags for all method parameters.

Some of this is part of Eugene's famous PR 365. There will definitely be room for improvement, such as better HTML rendering, and more editing tricks such as the one you're mentinoning (I know Simon Schaefer was looking into this as well).

 

* Refactorings
- Make refactorings (especially Rename) cross language boundaries (I've
seen this issue assigned to Mirko, but I don't know if there has been
any progress on it yet), this means:
  - Participate in Java refactorings
  - Trigger Java refactorings for refactorings initiated on the Scala side
- Extend refactoring support to Play templates and route files in the
Play plugin

This looks like a good candidate, but I think the best person to mentor it is Mirko. Depends on how much time he has at hand. I'd definitely value a bullet-proof "Rename", as well as a couple of other small refactorings, like

 

* Developer plugin
I remember some talk about creating a developer plugin providing some
tools for working on Scala, though I can't find anything on it now.
- An AST view visualising the AST generated by the compiler for the
current file or some highlighted class/method.

This would be cool. Additionally, it could display time spent in the type-checker for each method/expression (finding bottlenecks).

 

* Miscellaneous
- Warn about unused variables (this could have saved me quite some
trouble already ;)
- Quickfixes for typos, i.e. suggest similarly named variables if the
named variable doesn't exist.


I know this are just a bunch of partially unrelated features, but I hope
I'll be able to turn (parts of) it into a nice proposal.

What do you guys think about it? Of course I also welcome any additional
ideas :)

I had a couple of ideas, but some of them are too "open-ended". One that I'd like to see how it shapes up is "internal reprogrammability". This is a very fancy word for saying: let the programmer modify the IDE "on the fly", by providing little Scala snippets in certain places. One of the advantages of Emacs (and other lightweight editors such as SublimeText) is that they make it dead-easy for the user to tweak their behavior: interpreted languages tend to have an "eval" function :)

Here's the thing: in Scala we can do something similar, by evaluating code on the fly! We have a REPL, and it can be used programmatically. Why not let the user provide an expression for things like:

- save actions: something to be done on save, like "remove all trailing white spaces". This can be done as easy as  `doc.lines.map(_.trimRight)` // well, there's no trimRight, but you get the idea

- auto-edits: you want to change the way the editor works? provide a little snippet (for example: replace "@now" with the current date)

- custom value renderers in the Debug/Variables view. Sometimes '.toString' is not enough. Let the user define how his data should be displayed

- step filters: you don't want to step into all methods in the debugger, and maybe name based regexps are not enough.

So, these are a few ideas, not totally fleshed out. Important things to define: "sand-boxing" these snippets (not to corrupt state, aggressive time-outs, enabling/disabling, etc). I hope it's inspiring for some!

cheers,

iulian

 

Thanks in advance for any feedback!

michael

--
You received this message because you are subscribed to the Google Groups "Scala IDE Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

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

[Grzegorz Kossakowski]

On 9 April 2013 09:56, iulian dragos <jagu...@gmail.com> wrote:

I had a couple of ideas, but some of them are too "open-ended". One that I'd like to see how it shapes up is "internal reprogrammability". This is a very fancy word for saying: let the programmer modify the IDE "on the fly", by providing little Scala snippets in certain places. One of the advantages of Emacs (and other lightweight editors such as SublimeText) is that they make it dead-easy for the user to tweak their behavior: interpreted languages tend to have an "eval" function :)

Here's the thing: in Scala we can do something similar, by evaluating code on the fly! We have a REPL, and it can be used programmatically. Why not let the user provide an expression for things like:

- save actions: something to be done on save, like "remove all trailing white spaces". This can be done as easy as  `doc.lines.map(_.trimRight)` // well, there's no trimRight, but you get the idea

- auto-edits: you want to change the way the editor works? provide a little snippet (for example: replace "@now" with the current date)

- custom value renderers in the Debug/Variables view. Sometimes '.toString' is not enough. Let the user define how his data should be displayed

- step filters: you don't want to step into all methods in the debugger, and maybe name based regexps are not enough.

So, these are a few ideas, not totally fleshed out. Important things to define: "sand-boxing" these snippets (not to corrupt state, aggressive time-outs, enabling/disabling, etc). I hope it's inspiring for some!

I just wanted to say that I love this idea. Being able to easily hack Scala IDE with little snippets of code would be great. Those experiments can be turned into full blown plugins when they mature but one shouldn't be forced to learn about Eclipse ecosystem just to hack something small.

--
Grzegorz Kossakowski

Scalac hacker at Typesafe

twitter: @gkossakowski

github: @gkossakowski

[Simon Schäfer]

+1

I often think about something similar too. In fact I do it each time I
try to contribute to a feature I haven't used before. Learning how the
IDE internally works is a real time killer (but one that makes a lot of
fun ;)).

It would be so great if most editor related components could be extended
by user defined code. If users would be able to create rules for
refactorings, formattings, hyperlinks, find references etc. and if all
contributions could be tested and integrated completely automatically by
the IDE, this would probably lead to an exponential growth in opened
PRs. Integrating these things in the ecosystem (like the one that exists
for sublime) even better would lead to no PR reviewing anymore but a lot
of useful user content.

Maybe Scalas still outstanding macros may turn to a great supporter to
create such a "collaborative IDE", we may see. Scala itself is already
titled as "the statically programming language that feels dynamic", it
would be wonderful it such a thing could also be said about the Scala
IDE. I just can't wait on all the things that will be realized in the
next years for the IDE.

[Michael Holzer]

Thanks for your feedback and ideas!
Some comments inline.

On 09/04/13 18:56, iulian dragos wrote:
> * Scaladoc/Javadoc
[...]

> Some of this is part of Eugene's famous PR 365

> <https://github.com/scala-ide/scala-ide/pull/365>. There will definitely

> be room for improvement, such as better HTML rendering, and more editing
> tricks such as the one you're mentinoning (I know Simon Schaefer was
> looking into this as well).

That's great news :)

> * Refactorings
[...]

>
> This looks like a good candidate, but I think the best person to mentor
> it is Mirko. Depends on how much time he has at hand. I'd definitely
> value a bullet-proof "Rename", as well as a couple of other small
> refactorings, like

I contacted Mirko directly about this.

> * Developer plugin
> I remember some talk about creating a developer plugin providing some
> tools for working on Scala, though I can't find anything on it now.
> - An AST view visualising the AST generated by the compiler for the
> current file or some highlighted class/method.
>
>
> This would be cool. Additionally, it could display time spent in the
> type-checker for each method/expression (finding bottlenecks).

[...]

> I had a couple of ideas, but some of them are too "open-ended". One that
> I'd like to see how it shapes up is "internal reprogrammability". This
> is a very fancy word for saying: let the programmer modify the IDE "on
> the fly", by providing little Scala snippets in certain places. One of
> the advantages of Emacs (and other lightweight editors such as
> SublimeText) is that they make it dead-easy for the user to tweak their
> behavior: interpreted languages tend to have an "eval" function :)
>
> Here's the thing: in Scala we can do something similar, by evaluating
> code on the fly! We have a REPL, and it can be used programmatically.
> Why not let the user provide an expression for things like:
>
> - save actions: something to be done on save, like "remove all trailing
> white spaces". This can be done as easy as `doc.lines.map(_.trimRight)`
> // well, there's no trimRight, but you get the idea
> - auto-edits: you want to change the way the editor works? provide a
> little snippet (for example: replace "@now" with the current date)
> - custom value renderers in the Debug/Variables view. Sometimes
> '.toString' is not enough. Let the user define how his data should be
> displayed
> - step filters: you don't want to step into all methods in the debugger,
> and maybe name based regexps are not enough.
>
> So, these are a few ideas, not totally fleshed out. Important things to
> define: "sand-boxing" these snippets (not to corrupt state, aggressive
> time-outs, enabling/disabling, etc). I hope it's inspiring for some!

That's a very nice idea :)
I'll definitely look into that, spefically I'd like to explore two
directions:
- Well-defined hooks for users (things like the save actions you suggested)
- Open up the IDE as much as possible to provide a 'playground' for IDE
developers to explore and directly hack the IDE. Does anyone know if
something like this ('scripting eclipse') has been done for Eclipse in
another plugin, another language?

michael

[Mirko Stocker]

Hi,

I think these would all be wonderful things to have in the IDE :-)

> > * Refactorings
> > - Make refactorings (especially Rename) cross language boundaries (I've
> > seen this issue assigned to Mirko, but I don't know if there has been
> >
> > any progress on it yet), this means:
> > - Participate in Java refactorings
> > - Trigger Java refactorings for refactorings initiated on the Scala side
> >
> > - Extend refactoring support to Play templates and route files in the
> > Play plugin
>
> This looks like a good candidate, but I think the best person to mentor it
> is Mirko. Depends on how much time he has at hand. I'd definitely value a
> bullet-proof "Rename", as well as a couple of other small refactorings, like

I'd be happy to mentor Michael, he already knows the code base and from his
last project I know that he is very autonomous and doesn't need "hand holding"
to produce great results.

Making Rename bullet-proof while extending it to participate with JDT's
renaming and then making it extensible for Play sounds like a solid plan to
me.

Cheers

Mirko

--
Mirko Stocker | m...@misto.ch
Work: http://ifs.hsr.ch | http://infoq.com
Personal: http://misto.ch | http://twitter.com/m_st