Metals Prompts on Startup When Merging

[vito-c]

Is there a way to prevent metals from prompting if it should import changes? This becomes a little cumbersome when working on the cli with git.

For example during merges. I was also just prompted if I wanted to reimport when I was doing a git rebase -i master that seems like a bug that it would kick off the reimport flow when editing a commit message?

I could select "Don't show again" does that mean it won't prompt at all ever? Will I have to manually kick off the builds then?

I am also a bit confused about when a build is kicked off. For example I usually have to for force a :e % to get the little red x marks to disappear. A save will work to kick off a compile but the x's will hangout. Kicking off a refresh of the file will cause all your folds to collapse so that's also a little problematic.

Thanks!

[ckipp01]

Thanks for the question!

Is there a way to prevent metals from prompting if it should import changes? This becomes a little cumbersome when working on the cli with git.

So the way this works is that Metals has a digest of the build files related to your build tool. At any time if any of those files change, and therefore the digest changes, it will prompt you for a re-import. There really isn't a good way around this apart from just not changing any build related file.

For your example with the commit message, I'm unsure how that would ever happen, unless it's a timing thing somehow where coc.nvim still thinks the session hasn't ended with Metals yet, and then answers the request. In theory, that could happen, but it should be pretty rare. In the situation you have listed, do you have coc-metals open in another window or something that there is still a connection? Without it being open at all and then doing a commit shouldn't prompt this.

I could select "Don't show again" does that mean it won't prompt at all ever? Will I have to manually kick off the builds then?

For that workspace, yes. You'd either have to do a manual build import after that, or do a metals-reset-choice, which would reset your selection and then prompt you again moving forward.

I am also a bit confused about when a build is kicked off. For example I usually have to for force a :e % to get the little red x marks to disappear. A save will work to kick off a compile but the x's will hangout. Kicking off a refresh of the file will cause all your folds to collapse so that's also a little problematic.

So I'm not sure if you're the one that has mentioned this before or not, but this isn't the first time that I've heard of this behavior. The challenging thing is that this one is extremely hard to troubleshoot without a reproduction. Mainly, the red marks staying means your diagnostics aren't being cleared after a successful compilation. If this happens again, there are a few things that would really help.

Create the trace files and watch the communication. The build server should send a diagnostics message with a clear via bsp, which then in return should be sent via lsp to coc-metals. So there are multiple things that could go wrong

• Bloop doesn't send the clear
• Metals doesn't forward it correctly
• coc.nvim doesn't clear them correctly

So it's hard to know without having a full picture of the logs. Ideally, if this can ever be reproduced consistently, I'd be very happy, but I've never been able to do it.

[arbitrary-dev]

I'm having the same issues, when doing git add -p . and interactive diff editing in .git/addp-hunk-edit.diff

coc.nvim starts up a Metals server, but I would like it to not do it for files that aren't *.scala or *.sbt

[ckipp01]

coc.nvim starts up a Metals server, but I would like it to not do it for files that aren't *.scala or *.sbt

So this is a total guess, but if it's opening the .git/<whatever> is the root of the workspace still your scala project? Because it's actually not just the file type that prompts Metals being started, but also if the workspace contains other stuff. You can see this here:

https://github.com/scalameta/coc-metals/blob/4ff3959b61f0f1267571b71ef8011112087da0d3/package.json#L40-L47

So I'm assuming that when you are in that directory, this still triggers.

[arbitrary-dev]

is the root of the workspace still your scala project?

Don't quite get what you mean by the root, but, when performing diffs, the current working directory is indeed the scala project.

[ckipp01]

So then yes. What I mean by workspace is in LSP sort of relies on a workspace. So most editors have a "open workspace" option, which opens a folder and identifies it as a workspace. Since Vim doesn't really have that concept, it sort of cheats it and looks for "patterns" to identify a root which will help coc.nvim define the workspace. Then within that workspace, it things like a build.sbt exist, then that's an activationEvent like is listed above and starts Metals. I'm not fully sure how not to start Metals in this situation because a valid activation event (you being in the workspace with a build.sbt) happened.

[arbitrary-dev]

Maybe exclude diff filetypes from activation?

[ckipp01]

Maybe exclude diff filetypes from activation?

Well again, it's not so much the diff that is causing the activation. For example, if you just randomly open up a diff in a directory of it's own, it won't activate Metals. It's that the diff is located in a legit Scala workspace, and that is the activation.

[arbitrary-dev]

Yeah, I understand that. The question is, could the filetype be used as an exclusion from activation?

[godenji]

Not sure if this is related, but similar experience -- am prompted repeatedly to import build changes on each new open buffer in VIM despite no build changes having been made. Incredibly annoying, none of the 3 options have any effect.

I do have a Play server instance running, perhaps that's causing some havoc with CoC? At any rate would love to solve this intrusive behavior, often right in the middle of changing a line of code o_O

[ckipp01]

@arbitrary-dev

Yeah, I understand that. The question is, could the filetype be used as an exclusion from activation?

Sorry for the delayed response. But I took some time to try to see if there was any way to have a more involved activationEvent. Some that would be like this workspace has an activation event, but I'm in a diff so don't activate, but as as far as I can tell, there is no way to do this in coc.nvim. So basically it's a all or nothing, if your diff (from the coc.nvim) point of view is seen as "In a workspace" because an activationEvent fired, then this will happen. I'd actually recommend maybe posing the question in the coc.nvim gitter or even creating an issue over there about diff files triggering a server. Because this has to have happened in some other extension that also uses activationEvents like this.

@godenji

I do have a Play server instance running, perhaps that's causing some havoc with CoC? At any rate would love to solve this intrusive behavior, often right in the middle of changing a line of code o_O

So this really shouldn't happen unless Metals sees a "build file" changed in your workspace. So if using sbt, if your build.sbt, anything in project/ etc changes, it will trigger an import. We also store the state of your build and if you just change a comment or something, then we still won't trigger an import. Does this happen to you all the time, or only in your play project? Also if it's all the time, or even if it's just your play project, can you create a separate issue to not have 2 separate threads in here since the issues are different.

[esamson]

One workaround is to disable coc for git. I have this in my ~/.vimrc, for example:

if (&filetype=='gitcommit')
    let g:coc_start_at_startup=0
endif

[arbitrary-dev]

I ended up with this one:

if (index(v:argv, '-d') != -1 || v:argv[-1] =~ "\.git/")
  let g:coc_start_at_startup=0
endif