OMEdit does not keep formatting when single-file packages are used

[Francesco Casella]

Steps to reproduce the problem:

• create a new package P and save it in a single file
• create a model M in the package with some whitespace formatting in it
• save M

All the formatting in M is lost upon saving, as OMEdit does some unwanted and unrequested pretty-printing of its own.

[Andrea Bartolini]

It seems that if you work directly on the entire package, i.e. if you use the following procedure:

• open the package instead of the model
• find the model inside the package using the "find" function
• modify the model and save
• open the single model for check & run

can be a workaround, but it is very boring and time consuming, because each time you save the model all the package is checked.

This issue makes practically impossible to save a library inside a single package, if you are developing a complex library, for example for industrial use.

[Adeel Asghar]

Can you guys share a test package?

[Francesco Casella]

Steps to reproduce:

• load the attached P.mo
• create a new model M inside P
• paste the following formatted code in the window with model M

  model M
    parameter Real p = 3
      "This has some formatting on its own";
    Real x,     y,      z "Variables with some whitespace";
  equation
       x  +  10*y + 20*z = 10;
    10*x  +  20*y +    z = 30;
                y        = p;
  end M;
  

• hit Save: the formatting is gone

There is no such problem if you open the whole package P in a window and then paste the code of M in there, but this is not convenient for packages with many lines of code.

[Adeel Asghar]

Fixed in 14a8e7b/OMEdit.

I have also pushed it to 1.13 release maintenance branch.

[Francesco Casella]

Great! This helps a lot using OMEdit for serious development using revision control systems.

[Francesco Casella]

We still have a similar problem for packages where entire sub-packages are kept as single files.

Steps to reproduce:

• load the attached package P.zip
• open package.mo
• select P.P1.M in the Libraries browser
• add the Real y = 10; declaration below Real x = 2;
• hit save
• the formatting of P.P1.M is completely screwed up

Please make sure the formatting is preserved also in this case.

I would suggest to push the fix to this issue also to maintenance/v1.13, just in case we release a 1.13.1 maintenance version.

[Adeel Asghar]

Should be fixed by 7074e48/OMEdit. Francesco can you please test it? If it looks good then I will push it to maintenance/v1.13.

I found one case where formatting is lost,

Steps to reproduce:

• load the attached P.mo
• create a new model M inside P
• paste the following formatted code in the window with model M

  model M
    parameter Real p = 3
      "This has some formatting on its own";
    Real x,     y,      z "Variables with some whitespace";
  equation
       x  +  10*y + 20*z = 10;
    10*x  +  20*y +    z = 30;
                y        = p;
  end M;
  

• hit Save: the formatting is preserved.
• create a new model MM inside P
• hit Save: the formatting of M is lost

This is because the diff algorithm fails and as a fallback OMC's pretty printing is used. But this is another story and I guess we have a separate ticket about it (perhaps #3424, #3743).

[Francesco Casella]

Replying to adeas31:

Francesco can you please test it?

I'll do it asap.

This is because the diff algorithm fails and as a fallback OMC's pretty printing is used.

Why should it fail in the first place?

[Francesco Casella]

Replying to adeas31:

Should be fixed by 7074e48/OMEdit. Francesco can you please test it?

Seems to work fine. I have added a reference to the test case of comment:8 to #3424, so we can close this one after @adeas31 has pushed the change to maintenance/v1.13

[Adeel Asghar]

The change is pushed to maintenance/v1.13.
I have added a very simple script that shows the problem with diffModelicaFileListings.