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

Make getModeForRange() behave like getModeForSelection() when mode is not mixed #7775

Merged
merged 1 commit into from
May 7, 2014

Conversation

njx
Copy link
Contributor

@njx njx commented May 7, 2014

For #7764. This isn't the cleanest fix, but it exactly preserves the existing behavior for the case where getModeForRange() is called from getModeForSelection(), while fixing the behavior for the case where getModeForRange() is called directly from the commenting operations in EditorCommandHandlers.

The EditorCommandHandlers unit tests all pass with this fix.

@peterflynn /cc @TomMalbran

@njx njx added this to the Release #39 milestone May 7, 2014
@njx
Copy link
Contributor Author

njx commented May 7, 2014

BTW, I tested C++ (line and block comments) and bash (line comments) and they seem to work fine with this fix.

@peterflynn
Copy link
Member

Looks good to me. This keeps the master behavior when getModeForSelection() calls into getModeForRange(), but reverts to the pre-Sprint 38 behavior when EditorCommandHandlers calls it. Seems like exactly what we want for now.

#7345 remains to track a larger, longer-term cleanup. Our APIs are very inconsistent and ambiguous right now about when "mode" means the CM base mode name vs. the mimetype string vs. a mode object with config properties.

peterflynn added a commit that referenced this pull request May 7, 2014
Make getModeForRange() behave like getModeForSelection() when mode is not mixed
@peterflynn peterflynn merged commit 187f5fc into master May 7, 2014
@peterflynn peterflynn deleted the nj/issue-7764 branch May 7, 2014 21:14
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants