Environment variable or setting for full paths

[jastice]

The current output of relativized paths breaks source link parsing in some tooling such as IntelliJ IDEA and ENSIME sbt-mode. If this is to be merged into sbt, it should support at least opting out of relative paths and displaying full paths based on an environment variable.

To be automatically compatible with these tools in their current state, enable full paths

• when the property idea.runid is set
• when the environment variable INSIDE_EMACS is set

Other approaches:

• a property/environment var specific to this feature
• sbt setting that enables/disables the feature
• sbt setting that lets you fully configure the output

[jvican]

it should support at least opting out of relative paths and displaying full paths based on an environment variable.

Cannot sbt-intellij match the relative paths? You can easily get the base directory and append it.

sbt setting that enables/disables the feature sbt setting that lets you fully configure the output

These two are the way to go, and the ones I rooted for in Twitter.

[jastice]

Cannot sbt-intellij match the relative paths? You can easily get the base directory and append it.

It probably can, with some extra work ;)

[jastice]

Linking issue on our side: https://youtrack.jetbrains.com/issue/SCL-12191

[Duhemm]

@jastice I've added that in #15. You can do something like:

reporterConfig := reporterConfig.value.withShortenPaths(false)

Would that work for you?

[jastice]

@Duhemm Thank you, it will work fine if this is merged into sbt 1.0 before release. If it stays independent, a flag that can be set without having the plugin on the classpath is preferable, so that I could do something like:

SettingKey["reporterShortenPaths"] := false

[dwijnand]

I wonder if this would work 🙈

type ReporterConfig { def withShortenPaths(b: Boolean): ReporterConfig }
SettingKey[ReporterConfig]("reporterConfig") ~= (_ withShortenPaths true)

[fommil]

it needs to be an envvar, we have no power to set sbt settings from sbt-mode and remember that sbt-mode is not ENSIME... many people (way more than you'd think) use Emacs without ensime or sbt-ensime.

[Duhemm]

@fommil Can you communicate with the sbt shell that's running? There's the apply command that can be used to inject settings. That's what IntelliJ is using AFAIK.

[fommil]

@Duhemm we have to do this in all the editors... can't we just have an environment variable for the legacy mode? Also "that can be used to" is a lot harder than you think it is because we have to consider the state of the buffer and the user and the process.

BTW, I am only talking about if it becomes part of sbt core. If it's not going into sbt core then whoever wants to use this plugin can fix it themselves.

[jastice]

We don't use apply in the sbt shell integration precisely because it would need to know about state. Instead we inject an sbt plugin through global settings, which you probably shouldn't do either unless you have a need for it anyway. So for most use cases, a setting that reads an environment variable by default would be easier to integrate with.