New approach to OMEdit text editing

[Francesco Casella]

I report here the results of a discussion on omusability@….

Keeping the formatting consistent on models and packages spread over multiple files while hiding the file structure is an implementation nightmare, and also obscure and confusing to people using file-based revision control systems (SVN, GIT, etc.).

Proposal: whenever a specific class is selected in the package browser, the entire file where the class is defined is shown in the text mode editor, with this additional features:

• the part of the file where the code of the selected class resides is clearly marked (e.g, with a white background, while the rest of the file might have a grey background or something similar)
• the cursor is brought at the first line of the selected class automatically
• there is proper indentation support when hitting the newline key: if the model is nested several levels in a subpackage contained in one file, and the package is organized with proper indentations, one should not have to enter 12 or 16 spaces manually to keep the indentation consistent. Note that Dymola hides the indentation of a class definition in a package when showing it in the editor, and then somehow reapplies it back to the code, which is somewhat arbitrary and potentially error- prone, see above)
• the line numbering of errors and warnings given by omc matches the line numbering in the editor

At this point, whatever changes one makes to the entire file (possibly not limited to the selected class!) are accepted by OMEdit (as long as they are syntactically correct) when the focus is changed to another window, and the package browser will automatically reflect the new situation.

This should be relatively straightforward to implement, much easier to understand for end-user, and a lot better for managing files on RCSs without messing up things.

Members of the OMEdit usability group, please state your opinion on this ticket.

[Adeel Asghar]

I think you meant "package with multiple classes stored in one file" instead of "models and packages spread over multiple files".

This is possible but will make OMEdit very slow. Consider a package P with 20 nested classes named as A1, A2....A20. If user just want to update A10, we actually have to reload all classes since we are displaying the whole package contents and user has the liberty to update whatever he wants. This will affect the performance by the factor of N. The bigger the package the slower OMEdit.

Right now we do it as Dymola, we store the indentations and removes them before showing the nested class text to user. Once the user is done with editing we glue the nested class back in the package and put back the stored indentations.

[Francesco Casella]

Replying to adeas31:

I think you meant "package with multiple classes stored in one file" instead of "models and packages spread over multiple files".

Yes, of course, sorry.

This is possible but will make OMEdit very slow. Consider a package P with 20 nested classes named as A1, A2....A20. If user just want to update A10, we actually have to reload all classes since we are displaying the whole package contents and user has the liberty to update whatever he wants. This will affect the performance by the factor of N. The bigger the package the slower OMEdit.

Not necessarily. One can make a diff between the new text and the old text, and only reload those classes that are touched by the patch file. In most cases, one would only work on the class he has selected, and then there will only be one class that needs to be reloaded. A text diff should be no big deal.

[Adeel Asghar]

Replying to casella:

Replying to adeas31:

I think you meant "package with multiple classes stored in one file" instead of "models and packages spread over multiple files".

Yes, of course, sorry.

This is possible but will make OMEdit very slow. Consider a package P with 20 nested classes named as A1, A2....A20. If user just want to update A10, we actually have to reload all classes since we are displaying the whole package contents and user has the liberty to update whatever he wants. This will affect the performance by the factor of N. The bigger the package the slower OMEdit.

Not necessarily. One can make a diff between the new text and the old text, and only reload those classes that are touched by the patch file. In most cases, one would only work on the class he has selected, and then there will only be one class that needs to be reloaded. A text diff should be no big deal.

No that's not entirely true. OK we can avoid loading all classes but we anyway have to update the text of all classes. We also have a to update the text of all classes, when lets say user adds A21. This change should be shown in text of all classes then.

To be honest, I was the one who discussed and proposed this solution with Martin. I already tried to implement it but its not that easy. The way we have it now is quite fine and preserves indentations rather well.

[Christoph <buchner@…>]

To be honest, OMEdit hiding the file structure, and faking "files" for classes (making up line numbers and all that) was really really confusing when I started working with OM (using an RCS, too, of course).
Add the fact that at the time OMEdit was messing up package structure when you tried to divide your code in several files (has been fixed already), and I tried to correlate what OMEdit showed with what was in the text files, and what changes I saw in version control when OM made my code disappear, and nothing matched up! Quite a nasty surprise, and I'd also prefer that OM show the plain file structure, especially considering new users.

[Francesco Casella]

I agree with Christoph completely. People developing Modelica code (or any kind of code, actually) should always use an RCS. I'm trying hard to educate my students and colleagues to this basic concept, when they start sending me zipped files with Modelica code, God forbid. Trying to hide the file structure from the GUI just makes the whole thing confusing and unnecessarily harder to grasp.

As a consequence, Modelica tools should make life as easy and intuitive as possible to them. And it shouldn't be and expensive add-on, it should be built-in by design.

Some competitor tools have never shined on this front, I'm afraid, and this has impacted the community for a long time. I wish I had a more "text-editor"-oriented Modelica tool back in 2005-2007, when I was actively contributing to the Modelica.Media library, and I had to use a text editor if I wanted my intended changes only to show up in the SVN diffs (just change that single line in package.mo, please...). I am still resorting to text editors to develop portable Modelica code, for the very same reason. OK, I could use Eclipse for that, buth then I'd lack the GUI when it makes sense to use it.

In general, commercial Modelica tools try to hide the Modelica details to various extents (up to and including not actually showing the Modelica code at all). I think OpenModelica's approach has to be more transparent, that is, more open and more Modelica oriented :)

Let's do this right this time, and let's try to avoid copying features of other tools that have not proven to be satisfactory for RCS-based code development.

OMusability group members, please give your opinion by adding a comment to this ticket.