Python files are marked as saved when the netlist is saved

[RenWal]

Describe the bug When saving a netlist as .hal file, all open python editors with pending changes are marked saved. This is only partially correct: When the HAL file is saved, the unsaved Python files are included, so no work is lost. However, the actual Python files are not saved individually.

To Reproduce Steps to reproduce the behavior:

1. Open any netlist
2. Open a .py file in the python editor and type something, this will cause an asterisk to appear in the tab
3. Hit [Ctrl-S]
4. See that the asterisk is gone

Expected behavior Users will expect the asterisk to disappear iff the actual script file has been saved.

Additional context We should clearly document what gets saved where and when.

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label Type: Bug to this issue, with a confidence of 0.96. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[dertob]

I think we need to discuss when an asterisk has to be added to the tab or define what the asterisk actually means. Usally it means there are unsaved changes. Save the HAL file and the python scripts which don't have a *.py file on disk are technically saved nonetheless in that HAL file.

In my opinion the whole system how python scripts are saved and associated with the HAL file is the cause of all evil here.

Edit1:

Expected behavior Users will expect the asterisk to disappear iff the actual script file has been saved.

Does this mean it should also warn the user on exit that the content of the python script has not been saved altough it actually has been saved in the HAL file? Because the asterisks and the warning message on exit should always go hand in hand.

That's how it was implemented before actually. That was considered undisired behavior however.

Edit2:

I can only repeat myself, but I think the HAL file should not contain any python script content. At maximum the path to scripts associated with the HAL file should be saved or establish the link somewhere else.

It all boils down to how convinient it should be for the user. Do we want them to save twice? The HAL file and the content in the python editor? Or once and live with the confusion where some stuff is saved in the HAL file and some is not.

[Slowpoke42]

I think python scripts should only be written to their individual source files. I do not know of any other editor that saves opened files twice, once in the actual file and once in some kind of project file (excluding temporary backups). Seems unnatural and overcomplicated to me.

The only benefit of the current system seems to be that the python scripts are still available if you move or delete (intentionally or accidentally) the source files, but...

a) How often does that happen? It seems kind of contrived. b) Even if it does happen, it's not our problem. Thats the users problem. If you delete your files, your stuff is gone - thats how it works. If the user wants additional security he is free to use any backup or redundancy system he wants.

One could argue that there is the additional benefit of being able to share your entire project with other people, python scripts included, by sending them the project file, but once again thats a non problem. Zipping a folder takes like 3 seconds, we dont need a custom solution for that.

[RenWal]

I have previously suggested splitting this saving mechanism between never saved files and modified files. The first ones go into the HAL file. The second only go to their script file, but HAL remembers their path in the HAL file. Thus, unsaved files are not lost and external modifications of scripts while HAL is closed don't collide with what is saved in the HAL file. If the user deletes the script, it's gone.

I do not know of any other editor that saves opened files twice

VSCode does that. If you modify a file and just close the IDE, the file sits in the temporary storage of the IDE. Saved files are only remembered by file path. This, however, does cause the problem of external changes not being detected when the file is in that temporary storage and you change the original file.