I’ve tried out a few distros for vim and emacs over the years and usually drop them after a few hours of trying. But I gotta say I’m really enjoying LazyVim. It’s config layering system makes tweaking any specific plugin settings very easy, and it’s based on the “lazy.nvim” plugin manager that most plugins feature first in their README intros these days. That means there’s less a feeling of doing things “the normal way” vs “the weird distro specific way” that I experienced with DOOM EMacs and SpaceVim.

It’s definitely still a kitchen sink, lots of stuff that I wouldn’t configure on my own, but surprisingly discoverable via a popup that shows available keyboard shortcuts that appears after you type LEADER and wait a moment.

It’s also super fast to start up, putting most destros out there especially EMacs ones to shame.

The main downside is it encourages you to spread out your config in multiple Lua files, and overall learn and use more Lua stuff. But I think it’s worth the price.

Doesn't the idea of an "LSP for Neovim" mean the entire premise of LSP has failed? Wasn't the whole idea supposedly to put an end to editor-specific plugins in favor of one protocol spoken by all editors?

I was in the same place you were a month ago but I decided to just bite the bullet and build my own Neovim configuration from scratch. Fortunately I don't use auto-complete and an LSP was only a recent addition to my configuration. Telescope was one of the few plug-ins I configured off the bat and when you start small learning the eco-system isn't that much of a hurdle.

The Nvim Kickstart Project is a great starting point for your configuration and has it's config file heavily commented to teach you how to setup your own configuration, I highly recommend it.

Is there a Java code assist utility for neovim that isn't a language server?

It heavily depends on the language, the frameworks and the actual project.

Languages that have great and standard tooling will work great. Frameworks that rely on basic language features work great. Projects that rely on standard tooling and features work great. Things just work.

Languages that have 3 decades of legacy warts, languages with no or poorly implemented LSPs, languages where the ecosystem relies heavily on runtime language features, frameworks that rely on behind the scenes magic and conventions, projects where for ten years the whole team only ever used one IDE… yeah, it’s not where vim/helix/vsc shines, and you will fight an uphill battle.

There's a spectrum. notepad.exe, vi, emacs/vim/notepad++, vscode, idea. Every new layer adds more features and adds more bloat. You can upgrade to the next layer by installing enough extensions (if editor allows it and those extensions exist). You can certainly turn your bare vim into vscode comparable editor with enough extensions. And you can certainly install enough extensions into vscode to make it comparable with idea.

An important thing is to find a personal sweet spot. For me, using Idea with hundred plugins is just not worth it. Spring plugin comes with thousands of features, but when I disable it, miss very few things, and the bloat is real: slow start, lots of new menu items and icons, new bugs.

I, personally, prefer to use editor on steroids like vscode, with full language-aware support. At the same time I'm using external terminal a lot, doing builds and stuff there. So IDE for me is an entire computer and vscode is part of this IDE.

There are people out there who don't even use an LSP with autocompletion or type handling, just syntax highlights. There's a theory that actively thinking about this will prevent u from making mistakes like forgetting a semicolon.

I do agree that some nvim setups are just IDE's in your shell, but it's also nice to have everything in one place. I don't like vsc's and Jetbrains's terminals at all, as it gets clunky too quick. To each their own though!

You don't need a full-blown IDE to write HTML. Maybe for Python. But for languages like Java, you're leaving a lot of productivity and error prevention on the table.

I agree I think a lot of people do tend to go overboard with the plugins they add to Neovim. I only use a hand-full of plugins myself; Telescope for fuzzy finding, LSP for navigation and Rainbow-delimiters. I've found attempting to add anything "un-neovim-like" such as tabs or a debugger to be more of a hassle and jankier than just using something better suited to that task.

I actually think the best way to learn Neovim is to build your own configuration with as little plugins as necessary for you to get the job done because it'll force you to learn the Neovim way of doing things. For example instead of relying on tabs I learnt to use the Mark system and it was a great addition to my workflow.

The I stands for Integrated. Although technically I think the big 3 Java IDEs are written as a pile of plugins largely to support multiple languages. But they do tend to feel more "integrated"/look more cohesive. I guess the point is that if you feel like opening a text file in something it's a text editor. If you don't it might be an idea. I do try to open up individual text files outside of a project in pycharm sometimes but usually it feels weird. Maybe that's why they added scratch files. Somehow shift+shift new scratch file json and copy/pasting feels easier then making a new file outside your project with the IDE

I use Vim (recently switched to Neovim on my work laptop) as my daily driver with a minimum set of plugins. My primary language right now is Go, but used to be C++. It works just fine for my purpose. I have tried using IDEs in the past, most recently vscode when I was trying to learn Rust, I always end up going back to Vim, I find it more a more enjoyable and streamlined experience. For IDEs it's usually a struggle getting everything to work for me, and if there is a new version it just ends up breaking everything. I'm sure it's just a matter of what I'm used to. However I learned JAVA at university and it's the one language I have never managed to come to terms with using vim. At university I used Netbeans and I think that remains my one positive experience with IDEs. I really liked how that worked (or maybe I just hadn't been conditioned that much at that point). Java seems to be designed around the idea that you should user an IDE though. Sooo Verbose, and so many frameworks...

The full statement is "You don't need a full-blown IDE, just use (vim or whatever), unless you are writing in Java". Among mainstream languages, Java is uniquely hostile to being written by humans.

The statement is usually shortened under the assumption that nobody is writing Java by choice, and if you're writing it for work you're forced to use (Employer-provided development tool).

There are other languages that are hard to use without an IDE, but they always are relatively obscure ones and/or blatantly integrate the language itself tightly into the IDE, like Smalltalk or Scratch.

Most languages, it's feasible to write with nothing more than a regex-based keyword detector and symbol tagger. LSPs are overrated, other than the fact that they're a narrow waist for supporting multiple languages in multiple editors.

My .exrc file is about 10 lines long and has no plugins.

Combined with ctags and a terminal it’s all I need for the languages I’m familiar with (c, c++, rust, python and several others)

I like working in terminals. An IDE will never run in the terminal. Vim with the plugins I like run in my terminal.

I also need to configure which "plugins" I want whenever I install regular Visual Studio. In fact you can't really even start using it before that initial setup window. The time it takes to install and configure a plugin on vscode, for example, is basically 0 for most languages and platforms.

Thu people saying the former are different people than the ones installing all dhise plugins. I just run without plugins mostly

Today I generally think of an IDE supporting one language (or a few complementary languages) without any configuration, whereas a text editor usually requires configuration to get the same features. Although it's true the features are almost identical now. Though IDEs typically still offer some special sauce features, usually things that still don't fit cleanly into LSP and DAP (language server and debugger protocols respectively) models. On the flip side, text editors typically (lightly) support more file formats out of the box, and scale better, e.g., equally comfortable editing a single file or an entire project. TLDR: the trade off is between flexibility (text editor) or specificity (IDE).

> I wonder at which point do we call it IDE instead of text editor

The most hilarious to me is when people refer to Emacs as a "text editor". I'm not talking about the fact that Emacs shall happily display pictures (inlined in a file like in org-mode for example or in their own window), open binary files, open PDF files, manipulate files over SSH (Tramp), etc.

Heck, as a statement some made Emacs run as PID 1.

But many seem to honestly think Emacs is "notepad with bad shortcuts".

A good fuzzy finder helps a lot with this. You can type something like `ccufFoo` to match `com.company.util.factories.FooWidgetFactory`. I use fzf.vim for this.

Thankfully my company has its own hosted LSP that supports Java (and every other language in our bazel monorepo) so I don’t have to mess around with Eclipse and JDTLS (what happened to eclim?). But at a prior company I just worked without an LSP and just did a lot of referencing Java docs in a browser and split screen files.

FWIW, that is not a Maven-ism that is actually inherent to Java (the language and the runtime)[1]. Including case-sensitivity for the filename, which was an especially bold choice for Sun to make back in 1990, although I guess they're all "we'll sell more Solaris workstations!!1" or something

For example:

    $ mkdir foo
    $ cd foo
    $ printf 'package jimbo;\npublic class Foo2 {}\n' > fred.java
    $ javac -g -d . fred.java
    fred.java:2: error: class Foo2 is public, should be declared in a file named Foo2.java
    public class Foo2 {}
           ^
    1 error

The only exception that I'm aware of is that inner classes don't have to live in their own filename (given that they're more or less property of the owning class)

The Maven-ism that I'm aware of is the by default structure of {src/main/java, src/main/resources, src/test/java, src/test/resources} but (of course) those are customizable via the pom.xml if it jams up your project that much

1: https://docs.oracle.com/javase/specs/jls/se6/html/packages.h... (it's the oldest spec version they still link)

Not at all -- if you're something like LazyVim with the stock config, then in a large project it's just <leader>ff to search by filename or <leader>sg to grep across the project (using ripgrep!) or for a symbol search <leader>sS (using symbols provided by the LSP).

I haven't found anything better than Neovim+Lazyvim and switched from ST4 a couple of years ago and never looked back.

you want the ctrl+p plugin

It's a fuzzy file finder.

For your example of `org/example/groupid/packageid/submodule/File.java` I might write "[Ctrl+P] pamodFi[Enter]"

If `File.java` is unique enough, I can just type that and it finds it without issue.

There's also filetree plugins if you really want the visual clutter

Wouldn't that mostly matter if you're really navigating in your source code via the tree panel? In the post-Textmate days, fuzzy file finders seem to be all the rage whether you're using vim or IDEs (or Sublime etc.). Or you go to definition/references immediately.

I mostly use the file navigation when exploring the structure, which I'm not doing that often.

And which I probably should do with a class browser anyways, which I used to do often in Eclipse, way back in time, but it seems that particular SmallTalk-ism isn't very popular in contemporary IDEs.

Doing any work in a project worked on by multiple teams without C-P-style fuzzy file name matching is a recipe for frustration in any editor or IDE, regardless of the language. I've relied on this feature a lot when working in nvim+Python and nowadays in my vscode+typescript job it is one of my most heavily used shortcuts, too.

Try filepicker.vim [0] to navigate these in one of the many popular millers like lf, yazi, ranger or nnn

[0] https://github.com/Konfekt/filepicker.vim

Honestly having one single dedicated F key for jumping anywhere to a class or method definition is, for me, a killer feature that most alternatives lack. I do a lot of kinds of development with Vim, but for certain languages I find it a far better experience to use a language specific IDE.

One thing that non-Java devs don't get is just how much better the tooling is for Java than literally any other language.

Most jetbrains IDEs I find are indeed comparable to vscode plug-ins and a huge glob of vim plug-ins for most languages, especially the dynamically typed ones where the amount of static analysis you can do is already quite limited.

But for IntelliJ, literally no other editor comes close. Extract method/variable, all the "hey you wrote java 6 but it's 2024 that those 6 lines you wrote are 1 lambda now, do you want to replace", and so many other things.

Did you know that if you paste a maven xml dependency coordinate into a .gradle file, it auto-translates it to gradle format before the paste?

Vscode uses LSP, and for most mainstream languages it can provide refactoring, definition lookup, symbol renaming, etc.

JetBrains IDEs are highly extensible, and they have support for AI completions. Nevertheless, I think that the assistance and navigation features in IDEs are much more useful than auto-generating half-broken code.

Right now, I’d say the “AI IDEs” like Cursor or Zed are ready to replace less Java-centric environments. I’d put VSCode in this “not really Java centric” bucket. I see VSCode as a “fancy text editor” for Java, i.e., better than an editor like Neovim, but, not by much. So, an AI IDE is more likely going to gain traction on people who have been using VSCode or Neovim than anyone using Eclipse or IntelliJ.

Recently, my company has tried to introduce a “cloud IDE” (the development environment runs in the cloud somewhere). Initially, it only supported VSCode. The only engineers that bothered using it were junior; once people had about 5+ years of experience, they just found it tedious. Once the company included IntelliJ for that cloud IDE, usage spiked massively. (To the point they are restricting usage due to cost.)

These “classic Java IDEs” just launch with features useful for understanding large systems, like, fast navigation and debugging capabilities. Things like “where is method used” or “what implements this interface method” is fast and accurate - i.e., not based on text search. Or the interactive debugger that lets you inspect stream state, track objects, etc.

JetBrains probably won’t be focusing on using AI simply for writing code, but for enhancing all of these other capabilities. This is where I’m not sold on Cursor or Zed replacing these truly language-specific IDEs… yet.

These new upstarts need to improve the ability to navigate and understand. Right now, they only seem to focus on writing, which I don’t think is what’s going to gain traction. I also don’t see any of them doing much other than just fancy autocomplete, which can be awful on a large legacy codebase. So… we’ll see.

This could be generational, I’ve definitely seen poorer DevEx win simply because they gained the attention of younger engineers and lasted long enough.

I mean, yeah if you are using Kotlin you are almost inherently locked in to IntelliJ... by design. But for java proper, it's far from the only viable IDE.

> Surely the solution isn't to assume that JetBrains will do enough innovation in AI IDE features in the next year or two to prevent is wanting to try out all the other AI IDE innovation?

They kind of have been doing just that, their jetbrains AI assistant has an integration comparable to cursor's, just the model itself isn't as good which is a shame

What kills me with JetBrains is they work on a barely functional (according to vim coders I talk to) simulation plugin, instead of just investing resources into integrating Neovim as a backend via plugin. You can literally have all the niceness of JetBrains IDEs with the editing power of Neovim. That alone would flip so many die hard Vim users.