Framework for passive fixups #848

Open
aemoncannon opened this Issue Feb 27, 2015 · 7 comments

Projects

None yet

4 participants

@aemoncannon
Member

Two aspects to this:

  • A backend system for subscribing to interesting events, changes to particular AST fragments, looking at a certain type of file, etc, and then computing fixups.
    • A gui that gives a non-intrusive notification when fixups are available.
    • A gui for applying said fixups.
@fommil
Member
fommil commented Feb 27, 2015

๐Ÿ‘ certainly important for Java... but even in Scala there are some obvious cases (like "implement this missing method").

For Java, I strongly recommend just re-using/borrowing the NetBeans API and implementations. Extremely useful stuff in there (I know, I wrote some of them ๐Ÿ˜› )

@fommil
Member
fommil commented Feb 27, 2015

I'm actually keen for Java stuff to be a focus for post 1.0, so moving to that milestone so it doesn't get lost.

For post 1.0 my personal priorities are:

  1. refactor protocol messages, marshalling and use WebSockets: will make it really easy to extend in the future and lowers the barrier to entry for new contributors (and other editors to implement)
  2. really spend some time in the model/search layers to ensure we're passing around the correct Java and Scala names for everything (this affects Shapeless/functional/typey users a lot... whom ENSIME appeals to)
  3. (unless it makes it into 1.0) type hierarchy browsing: "show me the implementations of this trait" stuff.
  4. Java!
  5. Spring! (ok, maybe that's pushing it...)
@fommil fommil added this to the Next Gen 1.1 milestone Feb 27, 2015
@aemoncannon
Member

+1 this will be a big quality of life improvement for me at work ;-)

On Fri, Feb 27, 2015 at 4:05 PM Sam Halliday notifications@github.com
wrote:

I'm actually keen for Java stuff to be a focus for post 1.0, so moving to
that milestone so it doesn't get lost.

For post 1.0 my personal priorities are:

  1. refactor protocol messages, marshalling and use WebSockets: will
    make it really easy to extend in the future and lowers the barrier
    to entry for new contributors.
  2. really spend some time in the model/search layers to ensure we're
    passing around the correct Java and Scala names for everything (this
    affects Shapeless users a lot)
  3. (unless it makes it into 1.0) type hierarchy browsing: "show me the
    implementations of this trait" stuff.
  4. Java!
  5. Spring! (ok, maybe that's pushing it...)

โ€”
Reply to this email directly or view it on GitHub
#848 (comment)
.

@fommil
Member
fommil commented Feb 28, 2015

@rorygraves this would work well for the "add explicit type to public member" stuff we always want to implement

@rorygraves
Contributor

Sounds good to me!

@fommil fommil removed the Feature request label Jun 12, 2015
@fommil
Member
fommil commented Jul 31, 2015

relevant discussion in the emacs mailing list (for elisp passive cleanups) https://groups.google.com/d/msg/gnu.emacs.help/Oza4k-YpZk4/jazksyvgqmkJ

This was referenced Feb 2, 2016
@fommil fommil modified the milestone: Shiny 2.0 May 28, 2016
@VyacheslavMik

IMHO, an override suggestions would be useful feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment