Skip to content
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.

Deleting a file should remove entry from inline editor #1256

Closed
DennisKehrig opened this issue Jul 14, 2012 · 8 comments · Fixed by #1769
Closed

Deleting a file should remove entry from inline editor #1256

DennisKehrig opened this issue Jul 14, 2012 · 8 comments · Fixed by #1769
Assignees

Comments

@DennisKehrig
Copy link
Contributor

QuickEdit allows the user to select between multiple relevant files. If one of those files is deleted outside of Brackets, Brackets should reflect that when regaining focus.

Currently the inline editor is closed completely when the currently shown file was deleted (even if the inline editor offers other files that still exist).

If a different file from the list was deleted, nothing happens. If I then select that file, it seems like it's still there (maybe only when I opened it since Brackets is running). Leaving Brackets and returning then closes the inline editor, as the previously deleted file is now the current file in the inline editor.

@ghost ghost assigned peterflynn Jul 18, 2012
@pthiess
Copy link
Contributor

pthiess commented Jul 24, 2012

Reviewed. Moving to Backlog.

@peterflynn
Copy link
Member

@pthiess: I actually think this is a straightforward bug. In fact, I could swear it used to work. I'm removing the 'backlog' tag for now, but feel free to ping me if you want to discuss more.

@pthiess
Copy link
Contributor

pthiess commented Aug 14, 2012

@peterflynn: Please elaborate on what has been working before - afaik, there was no mechanism in place to update the rule list. That seems to be a backlog item which is updating the rule list when the rule is deleted, selector changed, etc.

@peterflynn
Copy link
Member

Oops, nm -- on closer reading, I see this bug acknowledges that we do already detect file deletion and remove the result (by closing the whole inline editor). The request here is to be finer-grained: leave the inline editor open and just remove results from the list that come from that deleted file. My bad!

Re-adding "backlog" tag (although this is still probably bug-sized in terms of effort).

@pthiess
Copy link
Contributor

pthiess commented Aug 14, 2012

Thanks Peter - will move it to Trello Card #569.

@DennisKehrig
Copy link
Contributor Author

Hey @peterflynn,

I was about to take a stab at this, but then I saw your comment in InlineTextEditor.js:252:

        // Note: this closes the entire inline widget if any one Editor loses sync. This seems
        // better than leaving it open but suddenly removing one rule from the result list.

Is this opinion restricted to losing sync, i.e. does not relate to deleted files? How does an editor lose sync?
Thanks!

Dennis

@DennisKehrig
Copy link
Contributor Author

Found the answer to my last question in Editor.js:

"lostContent -- When the backing Document changes in such a way that this Editor is no longer able to display accurate text. This occurs if the Document's file is deleted, or in certain Document->editor syncing edge cases that we do not yet support (the latter cause will eventually go away)."

@DennisKehrig
Copy link
Contributor Author

On my machine entries for deleted files are now removed from an inline editor.

However, when the selected file is deleted, the entire inline widget is closed because that's how InlineTextEditor deals with the lostContent event. I would like to override this in MultiRangeInlineEditor.js so that the widget is only closed if the last remaining entry becomes invalid. For that purpose I would need to prevent the InlineTextEditor from closing the widget.

Any thoughts on how to best do this? At the moment I favor making the event handler for the lostContent event a property of InlineTextEditor so that I can override it in MultiRangeInlineEditor. For this I'm wondering whether _onLostContent or onLostContent would be more appropriate names. What do you guys think?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants