Re: Proposed New Structure (starter for 10)

Lee Hinman <[email protected]> writes:

> Phillip Lord writes:
>
>> My starting point is that I would rather have a major-mode to open
>> files and does nothing else, but is installable via package.el. This
>> is the most critical change that we must achieve. Until this happens
>> JDEE is effectively junk.
>
> +1, having to manually install is a non-starter for a lot of people.
> Having an actual package so people can follow along or MELPA would be
> fantastic.
>
>> After this my vision is subtly different. I believe that JDEE should
>> be relatively small and do as little as possible, while allowing Emacs
>> and the environment to do most or all of the things that you speak
>> off.
>> 
>> So, project support. Eric has already mentioned EDE. Combine this with
>> rapid navigation tools like projectile, and we should have what we
>> need. The rest of the project support can be binned.
>
> +1, I think jde-mode should be a minor mode rather than a major-mode,
> all the non-interactive parts should be part of java-mode and
> contributions/enhancements should be made there.

I think that there are a few practical issues here, esp with the release
cycle and potentially with copyright policy for core. Having a small
jde-major-mode, which is essentially java-mode + some improvements is
less good than contributing straight through to core but may be a
practical necessity.


>> I believe we need connectivity to the JVM. I suggest nrepl for this,
>> as it allows us to connect, and gives structured access, an
>> interactive repl (albeit Clojure based rather than bsh which looks
>> like Java) and an independent channel for tooling. This already
>> exists. My starter for 10 just adds maven support (will when it
>> works!).
>
> I think nrepl is a good choice for it, but I enjoy clojure so I might be
> biased. Perhaps for Java 9 the included JDK REPL would be a good idea
> though (since it will be supported by the OpenJDK team)?


I would separate out "nrepl" and the current nrepl backend. Even if the
JDK REPL existed in widespread usage, then we'd probably still want to
use an NREPL client-server.

Just to clarify, nrepl is a protocol for structured communication with a
REPL process. It's an attempt to move Emacs away from the situation when
it sends a string to a process, then parses the output and tries to put
the two together. nrepl is a little Clojure biased, but is generic
enough. I know, for instance, Vitalie Spinu has built a nrepl
client/server for R, because parsing R output is a pain.

I'd suggest the clojure backend, simply because it's JVM and some of the
middleware (e.g. classpath, the object inspector, the stack trace
presentation) is likely to be directly sharable.



>> Find usages of -- backend middleware. Hopefully we can plugin to helm
>> and the like.
>>
>> Constant Compilation (and class reloading) -- no idea how to achieve
>> this, but I think it is not an Emacs issue, I think it is a build tool
>> and repl issue. We should work with CIDER and ENSIME to achieve this,
>> as they would probably both like it.
>
> Constant compilation (to me) isn't such an important feature, but I
> *definitely* want to be able to compile the project/file manually with
> something like =C-c C-k= (ala Cider) or =C-c C-v C-c= (jde current). An
> important feature of the compilation (again, for me) would be
> integrating with Flycheck so I could see the lines that have compilation
> errors/warnings.


I wonder whether Malabar mode would already provide this when integrated
with JDE as a minor mode?


>
>> My point is, JDEE has been a fore-runner in many of these things, but
>> is now carrying a lot of baggage. A lot of it's features now shadow
>> more general implementations. We need to throw out everything but the
>> glue that we need.
>>
>> As I said before, though, I only have a limited time to work on this.
>> I think my structure makes sense, and will take the least effort. But
>> I do not even have a lot of time to convince people, let alone code
>> it. I'll get my core idea up there as a starting point. But this is
>> probably where I will leave it. If no one takes it up, it's not going
>> anywhere.
>
> I'm happy to work on an idea like this, but I don't have any history
> working with JDEE before, so I don't know the best way to go about this.
>
> My idea of a minimum-viable-project is one where I can do =M-x
> jde-connect= and then hit =C-c C-v C-c= to compile the project (or get
> the compilation errors). This includes JDEE detecting the project type
> and configuring the appropriate classpath.
>
> Just let me know how I can help ^_^


My starter for 10 works now, and installs the CIDER "classpath"
middleware. Help would be appreciated, including just giving it a go and
seeing if it makes sense for you.

I'd like to get my code doing one useful thing (probably an
auto-importer) working. After which, I will stop, as it will be complete
as a proof-of-principle. Others are right -- we need to have a vaguely
coherent vision about the way forward for the simple reason that none of
us has the energy for a fork!

Phil

------------------------------------------------------------------------------