Can the editor wrap long strings when formatting files?

Syside Feature Requests
1

It would be a fantastic feature for the editor in VS Code to wrap long strings across the wrapping boundary configured in the settings. Right now, if the line is too long, it will wrap the assignment to the next line, but for very long strings it would be great if SysIDE would break those at the same boundary to keep files more readable.

2

Hi Jonathan,

You can already formatting configure this using Editor settings or a config file (see Configure Editor).

image
image2608×1288 180 KB

If you mean VS Code’s word wrapping capability (Ctrl+Z), you can tweak that in VS Code settings as well:

image
image1122×664 26.3 KB

3

That is kind of working, but it does not split strings. If I have a really long requirement string, it will not break it across lines. For example:

requirement <REQ.1> MyCoolRequirement {
  attribute rationale : ScalarValues::String = "This is my long-winded, detailed rationale for this requirement. This can get *really* long at times, depending on what the rationale or the attribute being defined needs to contain. If this can be split across multiple lines when formatting, then we can read it a lot better in a code editor."
}

VS Code will wrap this like so:

requirement <REQ.1> MyCoolRequirement {
  attribute rationale : ScalarValues::String = 
    "This is my long-winded, detailed rationale for this requirement. This can get *really* long at times, depending on what the rationale or the attribute being defined needs to contain. If this can be split across multiple lines when formatting, then we can read it a lot better in a code editor."
}

But I’d like to see it wrap more like this:

requirement <REQ.1> MyCoolRequirement {
  attribute rationale : ScalarValues::String = "This is my long-winded, 
      detailed rationale for this requirement. This can get *really* long 
      at times, depending on what the rationale or the attribute being 
      defined needs to contain. If this can be split across multiple lines 
      when formatting, then we can read it a lot better in a code editor."
}

I get this adds line-breaks into the string since SysML does not concatenate string literals, but this makes the file much more readable in my mind. Especially when that string gets even longer.

And this is the setting I’ve been working with:

image
image367×128 2.94 KB

This wraps on formatting where I want it, but if it could split strings as well that would be fantastic. Even if this is an option that is disabled by default that is fine.

The behavior I would expect is that it would split strings on word boundaries at the line length and tab the next line in. This is similar to how clang-format works with the ReflowComments option.

4

Technically, SysML specification grammar does not allow multiline strings and they are a bug that others have started to depend on while also matching the behaviour of Pilot implementation. For long strings doc is preferred as it is explicitly set up to handle doc-like multiline strings with optional leading *s. Even more so for requirements where owned documentation texts are accessible through a derived texts attribute.

requirement <'REQ.1'> MyCoolRequirement {
  doc Rationale
  /* This is my long-winded, detailed rationale for this requirement. This can
   * get *really* long at times, depending on what the rationale or the
   * attribute being defined needs to contain. If this can be split across
   * multiple lines when formatting, then we can read it a lot better in a code
   * editor.
   */
}

Additionally, docs are used for hover contents.

Regarding formatting, we leave strings and annotation bodies as-is because we cannot assume any one specific language. The former cannot be formatted without automatic string literal concatenation like in Python, C, or C++, while converting it to a multiline string with indentation would change its value. Annotation bodies are difficult because the language used is a user preference - if we just did paragraph splitting on words it could break markdown formatting that is trailing whitespace sensitive. Not to mention tables, lists, and code blocks. As such, we are currently focusing on other more important features.

As a side note, Neovim has gq and gw commands which can be used to format selected paragraphs only. Since 0.12, Neovim automatically infers KerML and SysML languages based on file extensions and inserts leading * on annotation body formatting.

5

Interesting - I didn’t realize that the language did not technically support it. I can see the challenges, but it would still be a useful feature (at least for my use case), even if disabled by default.

Thanks for the feedback!