Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#5187 closed defect (fixed)

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

Reported by: casella Owned by: adeas31
Priority: blocker Milestone: 1.13.1
Component: OMEdit Version: v1.14.0-dev-nightly
Keywords: Cc: Andrea.Bartolini, sjoelund.se

Description

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.

Attachments (3)

P.mo (19 bytes) - added by casella 5 years ago.
P.zip (839 bytes) - added by casella 5 years ago.
script.mos (656 bytes) - added by adeas31 5 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 Changed 5 years ago by 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.


comment:2 Changed 5 years ago by adeas31

Can you guys share a test package?

comment:3 Changed 5 years ago by 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.

Changed 5 years ago by casella

comment:4 Changed 5 years ago by adeas31

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in 14a8e7b/OMEdit.

I have also pushed it to 1.13 release maintenance branch.

comment:5 Changed 5 years ago by casella

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

comment:6 Changed 5 years ago by casella

  • Milestone changed from 1.13.0 to 1.14.0
  • Priority changed from high to blocker
  • Version set to v1.14.0-dev-nightly

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.

Last edited 5 years ago by casella (previous) (diff)

Changed 5 years ago by casella

comment:7 Changed 5 years ago by casella

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:8 follow-ups: Changed 5 years ago by adeas31

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).

comment:9 in reply to: ↑ 8 Changed 5 years ago by 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?

comment:10 in reply to: ↑ 8 Changed 5 years ago by 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

Last edited 5 years ago by casella (previous) (diff)

comment:11 Changed 5 years ago by casella

  • Milestone changed from 1.14.0 to 1.13.1

Changed 5 years ago by adeas31

comment:12 Changed 5 years ago by adeas31

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

comment:13 Changed 5 years ago by adeas31

  • Cc sjoelund.se added

comment:14 Changed 5 years ago by casella

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.