save as not working

This topic contains 4 replies, has 2 voices, and was last updated by  Brian Fernandes 1 month, 1 week ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #629597 Reply

    cleca
    Participant

    Steps to produce:

    Open eclipse workspace
    Click on obj3.js file in Project explorer to open in Javascript::Codemix editor
    Click on Eclipse menu File > Save As …
    Enter file name obj4.js and click ok
    Receive “Resource “/breakHier/combine/obj4.js” does not exist

    In the Linux shell the file also is not visible and has not been created.

    As a side effect of this error now some .js files become uneditable in the sense that the editor pane, which already was open before this error occurred, does not react to nay key presses any more. Also, in these edit panes do not show highlighting any more. The side effect vanishes after an Eclipse restart.

    This is on CodeMix 3 Release CI 2019.9.25 and Eclipse Oxygen 3a release 4.7.3a

    Currently it renders Codemix unusable for any larger edit tasks… 🙁

    #629626 Reply

    cleca
    Participant

    Uhh. Ohh. Ooooooh.

    There seems to be more broken with the save file feature.

    When I edit a file, the file is unsaved and I move the file in the project explorer into a different directory I get all kinds of weird effects.

    Ok. I understand that a file which is unsaved and open for edit should not be moved (and, actually, I would be perfectly happy receiving a message that I should first close that file, similar as most editors I know do).

    However what happens is: The system permits and executes the move (according to the view seen in the project explorer) but then the editor content behaves completely weird. It looks like the content consists of two different parts, one which shows but cannot be edited (ie. the cursor jumps around, as if this uneditable content would not exist, nevertheless it shows up in the view, albeit in a different color). Upon save then only one content portion is saved and the rest is JUSt GONE. As in “oops, nice that you worked on that file for 1/2 hour but the stuff is now GONE. Sorry.”

    During the move the editor content was not yet completely syntactically correct .js but just some text fragments. Maybe this is an aspect here.

    An hour ago I unexpectedly lost some 300 lines of code that way. Since I am usually not that dumb to produce such effects by mere accident, I did a bit of testing and can pretty much more or less reproduce this effect reliably. Steps are:

    1) doubleclick on an existing .js file with some content in project explorer
    2) edit file a bit
    3) move file in project explorer to different directory
    4) continue editing (you will see incorrect cursor behavior)
    5) click on save icon of eclipse, everything looks fine
    6) close editor panel with click into X symbol
    7) doubleclick on file in project explorer (at new location)
    8) observe that considerable parts of the edit is missing

    I am not aware to which extent this effect happens in ALL scenarios, since I am currently working in a fresh project directory which already
    consists of some 3, 4 directories with some 3, 4 files each and the problem showed up only now. As “save as” (see above post) and moving files around is part of my usual workflow, I am a bit astonished that I did not notice such behavior earlier. There might some other aspect in my workflow which might have triggered that and here I can only guess. I did a chmod 755 in the shell for one or two files to enable a babel-node she-bang (but did an explorer refresh and even eclipse restart since)

    However, the problem now shows up quite consistently and reproducibly.

    Of course I cannot tolerate unexpected loss of edited code and thus I am throwing CodeMix off my eclipse for now until getting some indication that this got fixed or addressed somewho.

    #629627 Reply

    cleca
    Participant

    Uhh. Ohh. Ooooooh.

    There seems to be more broken with the save file feature.

    When I edit a file, the file is unsaved and I move the file in the project explorer into a different directory I get all kinds of weird effects.

    Ok. I understand that a file which is unsaved and open for edit should not be moved (and, actually, I would be perfectly happy receiving a message that I should first close that file, similar as most editors I know do).

    However what happens is: The system permits and executes the move (according to the view seen in the project explorer) but then the editor content behaves completely weird. It looks like the content consists of two different parts, one which shows but cannot be edited (ie. the cursor jumps around, as if this uneditable content would not exist, nevertheless it shows up in the view, albeit in a different color). Upon save then only one content portion is saved and the rest is JUSt GONE. As in “oops, nice that you worked on that file for 1/2 hour but the stuff is now GONE. Sorry.”

    During the move the editor content was not yet completely syntactically correct .js but just some text fragments. Maybe this is an aspect here.

    An hour ago I unexpectedly lost some 300 lines of code that way. Since I am usually not that dumb to produce such effects by mere accident, I did a bit of testing and can pretty much more or less reproduce this effect reliably. Steps are:

    1) doubleclick on an existing .js file with some content in project explorer
    2) edit file a bit
    3) move file in project explorer to different directory
    4) continue editing (you will see incorrect cursor behavior)
    5) click on save icon of eclipse, everything looks fine
    6) close editor panel with click into X symbol
    7) doubleclick on file in project explorer (at new location)
    8) observe that considerable parts of the edit is missing

    I am not aware to which extent this effect happens in ALL scenarios, since I am currently working in a fresh project directory which already
    consists of some 3, 4 directories with some 3, 4 files each and the problem showed up only now. As “save as” (see above post) and moving files around is part of my usual workflow, I am a bit astonished that I did not notice such behavior earlier. There might some other aspect in my workflow which might have triggered that and here I can only guess. I did a chmod 755 in the shell for one or two files to enable a babel-node she-bang (but did an explorer refresh and even eclipse restart since)

    However, the problem now shows up quite consistently and reproducibly.

    Of course I cannot tolerate unexpected loss of edited code and thus I am throwing CodeMix off my eclipse for now until getting some indication that this got fixed or addressed somewho.

    #629695 Reply

    Brian Fernandes
    Moderator

    Clemens,

    First – good news, we’re putting out a release in the next couple of days which should have both these issues fixed. We were due to release today, but have pushed the release out to ensure these fixes are correctly made, tested, and included in the release.

    On to the actual issues you raised:

    We did not have move protection built into the product, something we somehow overlooked. Without the protection in, nothing could really be expected to work correctly once the file was moved, which would explain all the issues you see (from bad highlighting, to unexpected cursor behavior). Like regular Eclipse editors, you will now be prevented from making unsafe changes if there are unsaved changes in your editors.

    Unfortunately, Save As had a regression in a recent release as part of some other optimizations, and as it was stable for so long, we missed it in our regression suite – it has now been added to our automated tests.

    Sorry you had a negative experience in areas that we completely agree should be rock solid. Especially appreciate you taking the time to send in your feedback, despite uninstalling CodeMix, at least for now.

    #630051 Reply

    Brian Fernandes
    Moderator

    Clemens,

    The release from a couple of days ago includes fixes for Save-As and Move (we’re going to make move a bit more flexible in upcoming versions). We’ve also exposed the CA on trigger checkbox so you can basically make all those settings without having to go to the settings.json file.

    For more on what’s been fixed in this version, please see our blog post.

    Again, thank you for the feedback.

Viewing 5 posts - 1 through 5 (of 5 total)
Reply To: save as not working

You must be logged in to post in the forum log in