Odd formatting with typstyle

[TimeTravelPenguin]

Describe the bug I am getting odd formatting when setting the format mode to typstyle.

Consider the following unformatted code:

#let add_draft_stamp() = {
  with_color_or_default("red",red,fill => {
      place(center + horizon,rotate(-45deg,
          text(fill: fill,weight: 700,15em,"DRAFT",),),)
},)}

When running typstyle myfile.typ:

#let add_draft_stamp() = {
  with_color_or_default(
    "red",
    red,
    fill => {
      place(
        center + horizon,
        rotate(
          -45deg,
          text(fill: fill, weight: 700, 15em, "DRAFT"),
        ),
      )
    },
  )
}

When using the inbuilt formatter within tinymist:

#let add_draft_stamp() = {
  with_color_or_default(
    "red",
    red,
    fill => {
      place(
        center + horizon,
        rotate(
          -45deg,
          text(
            fill: fill,
            weight: 700,
            15em,
            "DRAFT",
          ),
        ),
      )
    },
  )
}

I can't seem to work out why tinymist's typstyle format causes excessive newlines. I dislike so many unnecessary newlines because a mix would be better but I can deal with it for the sake of consistent formatting. However, because the two do not produce the same output, I am rather confused as to what is going on.

Package/Software version:

I am using Neovim 10.1.

tinymist 
Build Timestamp:     2024-08-08T13:41:17.836500000Z
Build Git Describe:  ee50b24
Commit SHA:          ee50b24ce43d98d560e38c49ad8c34769a97a64e
Commit Date:         None
Commit Branch:       None
Cargo Target Triple: aarch64-apple-darwin
Typst Version:       0.11.1

[Myriad-Dreamin]

https://github.com/Enter-tainer/typstyle/issues/31

[TimeTravelPenguin]

Enter-tainer/typstyle#31

@Myriad-Dreamin Hmm, then it is likely the case that it is doing "too much" over my own personal preference.

At first I thought it behaved similarly to Black or Ruff where it spreads function params over multiple lines if:

1. The user overrides with a config to always do so (not applicable here)
2. The function args are too long
3. The final argument ends with a comma, indicating that the dev wants them on multiple lines, regardless of the total length.

In particular, I thought it was option 3, since the formatter adds commas. I suppose instead the issue is in the way the formatter determines from surrounding context and considers a more global scope, whereas I want my inner scopes to not spread over multiple lines.

Is there any way to disable this from happening, or do I need to stick with the external formatter?

[Myriad-Dreamin]

We detect if current array/func call is laid out in multiple lines and use that to format them.

[TimeTravelPenguin]

We detect if current array/func call is laid out in multiple lines and use that to format them.

Yes, understand. In my original demo code:

#let add_draft_stamp() = {
  with_color_or_default("red",red,fill => {         //    <-------- this line here
      place(center + horizon,rotate(-45deg,
          text(fill: fill,weight: 700,15em,"DRAFT",),),)
},)}

The line indicated only breaks over more than one line in a new scope. I suppose if I want to keep my styling preference, I will need to extract this out.

[Myriad-Dreamin]

I can't seem to work out why tinymist's typstyle format causes excessive newlines. I dislike so many unnecessary newlines because a mix would be better but I can deal with it for the sake of consistent formatting. However, because the two do not produce the same output, I am rather confused as to what is going on.

I think I have answered the question. You just need to remove newlines in the function call, then it won't stretch a function call that is only spanned in a single line.

[TimeTravelPenguin]

I think I have answered the question. You just need to remove newlines in the function call, then it won't stretch a function call that is only spanned in a single line.

I'm sorry, but I am confused. If I do:

#let add_draft_stamp() = with_color_or_default("red",red,fill => {place(center + horizon,rotate(-45deg,text(fill: fill,weight: 700,15em,"DRAFT",)))})

It still formats exactly the same

[Enter-tainer]

I guess this is related to mis configuration. you may accidentally set column width to zero in tinymist. So typstyle breaks at every possible break position

[TimeTravelPenguin]

I guess this is related to mis configuration. you may accidentally set column width to zero in tinymist. So typstyle breaks at every possible break position

Sorry for the late reply. I have looked through my vim setup and am not able to find any place where this might be happening. Not unless something is doing it would me knowing. Is there a way I can re-set the width?

Here is my personal repo, where I configure tinymist. Currently, things are commented out, but I have tried with them enabled with no success. Do you have any other ideas I can try?

[Enter-tainer]

https://github.com/TimeTravelPenguin/NeoVim/blob/1c7743d136a3fe456701dbd1d6a93f9d90d98372/lua%2Fconfigs%2Flspconfig.lua#L117-L117

this line looks suspecious, could you try uncomment this line and see how tinymist format your code?

cc @Myriad-Dreamin just to confirm, what would happen if user doesnt specify a column width?

update: and please also uncomment the previous line maybe?

[Enter-tainer]

but honestly i'm not a (n)vim user or expert. i dont really know how to configure lsp in vim. maybe tinymist can print current config when start up so we can see how it is configured

[TimeTravelPenguin]

TimeTravelPenguin/NeoVim@1c7743d/lua/configs/lspconfig.lua#L117-L117

this line looks suspecious, could you try uncomment this line and see how tinymist format your code?

I have tried with this uncommented and there was no change. When I uncomment that line and the line above, formatting occurs but does so strangely.

If there if a way to dump the config, that would be a good place to investigate!

[Myriad-Dreamin]

The default value was 120 but currently it is (badly refactored) as 0. Though, vscode always passes its default value so we didn't find it.

https://github.com/Myriad-Dreamin/tinymist/blob/98570a00f00b575ef02c00b34bc200d67d935e97/crates/tinymist/src/init.rs#L271-L272

[TimeTravelPenguin]

Interesting, thanks for looking into this! I am curious about testing some things out in the future, so I look forward to any changes.

I tried looking into some nvim lsp stuff, but the right documentation is a bit hard to find. I was curious as to whether the lspserver does anything regarding line widths. I know nvim does have an option for it, as I have it set in my config to 120, if I recall correctly. But I haven't found anything besides anything related to ftplugin files.

On that note, I downloaded the files I mentioned in issue #511 in this comment. I think they made some of the behaviours I have less consistent. That is, when I added them to my nvim dir, they made the line breaking more extreme. Since removing them, I think the behaviour is correct as you have been describing, so long as I have the line width set to 120 in the lsp setup config.

So, I think it would be a good idea to look into those files and see if they could possibly be doing something because it could be causing confusing settings or something. Hopefully, they aren't causing an issue and it is just my setup.

[Myriad-Dreamin]

Two things to be done:

Fix default value at the server side

Set the default value if the configuration is not set. Note an explicit formatterPrintWith = 0 from user is legal.

Documentation

The documentation about configuration can be found here. It is just derived from VSCode's configuration definition:

https://github.com/Myriad-Dreamin/tinymist/blob/98570a00f00b575ef02c00b34bc200d67d935e97/editors/vscode/scripts/config-man.cjs#L110-L117

Some configuration items that is not working in neovim are excluded during generation, but I'm not an active neovim user so the documentation so there may still be some bad or wrong documentation. We perhaps need some volunteer to keep checking it.

Edit: looks like it is already containing a lot of configuration items unrelated to neovim. :scream_cat:

[TimeTravelPenguin]

While I can't promise I will be 100% on top of things, I will happily report any issues that I experience. I have really taken a liking to typst, and I certainly prefer to use neovim if I can.