julials: default localization of .JuliaFormatter.toml

[ismael-lajaaiti]

Problem description

With the default configuration of julials it seems that procedure to find the .JuliaFormatter.toml is different from the one described in the JuliaFormatter documentation:

When format called, it will look for .JuliaFormatter.toml in the location of the file being formatted, and searching up the file tree until a config file is (or isn't) found. When found, the configurations in the file will overwrite the given options.

For instance if I have the following tree:

Julia/
├──.JuliaFormatter.toml
├──Project.toml
├──Manifest.toml
├── directory/
    ├── test.jl
    ├── ... 

If directory/ doesn't have a .JuliaFormatter.toml, the formatting will occur according to Julia/.JuliaFormatter.toml.

However, the behaviour with julials formatting is slightly different.
From I see, if there is no directory/Project.toml my environment is Julia/ and the formatting is ruled by Julia/.JuliaFormatter.toml. However, if there is a directory/Project.toml, it seems that julials is looking for a directory/.JuliaFormatter.toml and if doesn't not exist, default formatting options are applied. Whereas here, I would expect that the Julia/.JuliaFormatter.toml rules to be applied.

Why do you think this is an issue with mason-lspconfig.nvim?

I am new to neovim and not sure who is responsible for the behaviour of the formatting of julials. Thus if I'm opened this issue in the wrong repository, I would be happy to be redirected to the right place and sorry for the inconvenience.

Neovim version (>= 0.7)

NVIM v0.8.3
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by brew@Ventura-arm64.local

Operating system/version

Darwin sk-E22-66-156.local 22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:03:51 PST 2022; root:xnu-8792.61.2~4/RELEASE_ARM64_T6000 arm64

I've manually reviewed the Nvim LPS client log (:LspLog) to find potential errors

• Yes

I've recently downloaded the latest plugin version of mason.nvim, mason-lspconfig.nvim, and nvim-lspconfig

• Yes

Affected language servers

julials

Steps to reproduce

1. $ cd <trash_dir> to go to a directory to create the temporary files and directory
2. $ mkdir Julia
3. $ cd Julia
4. $ julia --project=. -e 'using Pkg; Pkg.add("Random")' to create a Project.toml and Manifest.toml
5. $ echo 'indent = 1' > .JuliaFormatter.toml
6. $ mkdir directory
7. $ echo 'for i in 1:10\nprintln(i)\nend > test.jl'
8. $ nvim test.jl and run the LSP formatter, you should see the inner line of the loop (println(i) to be indented with 1 space), then save and quit the file
9. $ julia --project=. -e 'using Pkg; Pkg.add("Random")' to create a Project.toml and Manifest.toml in the directory/
10. $ nvim test.jl and run the LSP formatter, the inner loop should no be indented with 4 spaces (the default formatter option).

Actual behavior

If an environment (i.e. Project.toml) exists in the current directory of the file but there is no .JuliaFormatter.toml the default formatting options are applied. (In my example, the current directory is directory/ and the file test.jl)

Expected behavior

Whereas we expect that formatter options of the .JuliaFormatter.toml of the directory above (Julia/ in my example) to be applied, instead of the defaults.

LspInfo

Language client log: /Users/me/.local/state/nvim/lsp.log
 Detected filetype:   julia
 
 1 client(s) attached to this buffer: 
 
 Client: julials (id: 1, bufnr: [1])
 	filetypes:       julia
 	autostart:       true
 	root directory:  /Users/me/Documents/Projects/trash/Julia/directory
 	cmd:             julia-lsp  /Users/me/Documents/Projects/trash/Julia/directory
 
 Configured servers list: julials, lua_ls, pylsp, r_language_server, ltex

LspLog

No response

Healthcheck

mason: require("mason.health").check()
========================================================================
## mason.nvim report
  - OK: neovim version >= 0.7.0
  - WARNING: **Go**: not available
  - OK: **cargo**: `cargo 1.67.0`
  - WARNING: **luarocks**: not available
  - OK: **Ruby**: `ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin22]`
  - OK: **RubyGem**: `3.0.3.1`
  - WARNING: **Composer**: not available
  - WARNING: **PHP**: not available
  - OK: **npm**: `8.19.2`
  - OK: **node**: `v18.12.1`
  - OK: **python3**: `Python 3.9.6`
  - OK: **pip3**: `pip 22.2.2 from /Users/ismael.lajaaiti/Library/Python/3.9/lib/python/site-packages/pip (python 3.9)`
  - OK: **javac**: `javac 19.0.2`
  - OK: **java**: `openjdk version "19.0.2" 2023-01-17`
  - OK: **julia**: `julia version 1.8.5`
  - OK: **wget**: `GNU Wget 1.21.3 built on darwin22.2.0.`
  - OK: **curl**: `curl 7.87.0 (aarch64-apple-darwin22.2.0) libcurl/7.87.0 OpenSSL/3.0.7 zlib/1.2.13 brotli/1.0.9 zstd/1.5.2 libidn2/2.3.4 libpsl/0.21.2 (+libidn2/2.3.4) nghttp2/1.51.0`
  - OK: **gzip**: `Apple gzip 400`
  - OK: **tar**: `bsdtar 3.5.3 - libarchive 3.5.3 zlib/1.2.11 liblzma/5.0.5 bz2lib/1.0.8 `
  - WARNING: **pwsh**: not available
  - OK: **bash**: `GNU bash, version 3.2.57(1)-release (arm64-apple-darwin22)`
  - OK: **sh**: `Ok`
  - OK: GitHub API rate limit. Used: 1. Remaining: 59. Limit: 60. Reset: Tue 14 Mar 15:22:55 2023.

Screenshots or recordings

No response

[williamboman]

Hello! Thanks for the detailed report. I don't believe there's anything that should be addressed in this plugin. I believe the problem is that nvim-lspconfig is configured to look for Project.toml when resolving the workspace folder for the project, so it will end up using directory/ if there's a Project.toml in there.

The Julia language server seems to look through all registered workspace folders to find a JuliaFormatter config. nvim-lspconfig will only set a single workspace folder when launching the server.

I see three potential solutions:

1. override nvim-lspconfig's default root_dir setting
2. keep the default nvim-lspconfig settings and manually add workspace folders via :h vim.lsp.buf.add_workspace_folder()
3. use vim.lsp.start() instead of nvim-lspconfig to set up julials (it gives you greater flexibility)

[iago-lito]

Thanks for the convincing insight @williamboman :)
IIUC these workarounds will "make it work", but none solves the problem that the formatter is behaving incorrectly with the default installation. Do you think this report (and the associated workarounds) should be moved to nvim-lspconfig then? The problems seems to be that their hypotheses about the idea of a "workspace" are too strong?

[williamboman]

Yeah that would probably be a better place. Note that nvim-lspconfig configurations are technically "unsupported" and best-effort. To me it sounds like this relates to project setups that are more complex than what nvim-lspconfig currently is able to support, so I think a good first step would be to iron out what constitutes a "project" and how these can be identified.