On Sun, Oct 11, 2026 at 1:24 AM Michael Bien <[email protected]> wrote:
> On 10/8/26 08:27, Jan Lahoda wrote:
> >> what gets opened.
> >>
> >> tbh I am a bit confused why there is such big focus on trying to
> >> automatically open everything within a folder (it might be distracting
> >> from the actual underlying improvements). It is easy to demonstrate that
> >> it is a very bad idea to try that performance wise and likely security
> >> wise too. (performance PRs are welcome btw if backed by measurements)
> >>
> > My personal opinion:
> > If a user explicitly says "I want to work with stuff in this folder"
> (e.g.
> > by opening it as a project/"workspace folder"), then we should try to
> make
> > things work for them. In practice, that means indexing the stuff in the
> > folder (some things work reasonably with on demand indexing, but not
> all),
> > and project open is a way to make sure indexing happens.
> I am curious how that would work in practice. The generic folder is
> unstructured by design. What would NB do if it finds a jar or a json;
> e.g once in the index. what would it associate it with?
>
What I had in mind was that we'd discover projects under that directory,
and open them. (And also open a project that would be owner of that folder,
if any, although that is probably niche.)
This is, per my understanding, exactly what the VS Code extension is doing
for Java projects.
>
> "Real" projects have specific source roots, build structure and config
> based on their project type, which allows NB to create relationships
> between artifacts during index queries.
>
> To quote a movie line: "i have a bad feeling about this"
>
> If there would be a challenge to come up with a way to convert potential
> multi click CVEs into 0 click CVEs, running annotation processors and
> other things in arbitrary folders without much user interaction would be
> a hot contender ;)
>
We already have some "trust" for projects, and we may need an explicit
"trust" for folders like this in any case - at least assuming a folder like
this would be sent as a workspace folder to LSP servers.
>
> > If we let the user "open" a folder, but don't index, and force the user
> > manually select which projects should be open, then I am not sure how big
> > an improvement is that compared to the current state. The user could
> > already open the projects (if they exist).
>
> i think the improvement to have chosen folders attached to project
> groups (be it via project impl or other ways) would be already pretty
> significant IMO.
>
I guess I wonder what is the significance of improvement, where I can add
an arbitrary folder to the project group, but nothing else happens except
the folder is on some list of folders. I see it might be useful for use
with LSP servers and related technologies (as a workspace folder), but
outside that, in "pure" IDE, what's the advantage? Is it just because
Favorites are not switched when Project Groups are switched? Because it
sounds a lot like a folder inside Favorites.
>
> The fact that it could be a root folder for one or more projects is also
> interesting (the new sub-path tree indention makes that an option now)
>
> Opening projects is also pretty easy. If it isn't easy enough and there
> are actions missing e.g "open everything within folder" we could add it
> I suppose.
>
> Nice thing about this: the project group remembers what was open and
> what not - so it builds on top of existing functionality.
>
>
> we could flip the point of view too:
>
> Maybe someone wants to work only on a handful of sub projects, why would
> it be required to open everything just to close uninteresting projects
> again?
>
If someone wants to and has the knowledge to work on a limited set of
projects, then there's nothing preventing them from opening just the
projects they want, no? I mean, we don't want to remove any functionality,
right?
I suppose two reasons for adding the ability might be support for LSP
servers (i.e. sending them as workspace folders to the LSP server and
alike); and to make work with projects simpler. Just adding a folder into
the list with nothing more helps at most with the first one.
Jan
>
> > If the numbers seem a bit too high
> > (like for NetBeans), we don't open the projects, and show some kind of a
> > warning telling the user working with the whole folder at once might be
> > problematic,
> right. I mean it could be a project group setting. AUTO_OPEN.{NEVER,
> WHEN_FEW, ALWAYS}.
>
> NEVER should be default for our own sanity IMO - esp during rollout.
> (default would be somewhat analog how maven/gradle sub projects work
> right now when parent opened)
>
> best regards,
>
> michael
>
>
>
>
