#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)
Change History (17)
comment:1 Changed 5 years ago by Andrea.Bartolini
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.
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: ↓ 9 ↓ 10 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
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
It seems that if you work directly on the entire package, i.e. if you use the following procedure:
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.