[CLOSED] Update color picker when user makes edits in host editor #2068
Comments
|
Assigning to |
|
OK, this should be ready for review. Note that in the scenario in #2140, we now collapse the editor. I had originally made it so that we would keep the editor open on the chance that the user might make the color valid again (and correctly update the range in that case), but since we can't really tell whether the user is going to do that in the future, it seems safer to just collapse the editor immediately. We could try to make some smarter UI for this in the future. |
|
Fixes pushed, ready for re-review. |
|
Done reviewing. |
|
Updates pushed. |
|
Cool, looks good then |
Sunday Nov 18, 2012 at 22:21 GMT
Originally opened as adobe/brackets#2147
In addition to that behavior change, I also factored out logic for getting the current host editor range associated with the inline editor. I also tweaked that logic to make it a little more robust to host edits--if the end bookmark goes stale, instead of just assuming that the relevant range still corresponds to the original color length, we first re-check the color regex to try to determine the end.
Note that this is currently independent of #2142. We might want to reuse the logic from that pull request that avoids synchronizing when the text input field contains an invalid color value, and apply that to changes from the host editor as well. However, this pull could be reviewed independently of that, and we could merge the implementations later; the change would be to make
handleHostEditorChange()call that factored-out logic instead of directly callingcommitColor().njx included the following code: https://github.com/adobe/brackets/pull/2147/commits
The text was updated successfully, but these errors were encountered: