-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CLOSED] Expand options for preferences lookups #6093
Comments
|
|
The current implementation of PreferencesSystem (the object that implements the new preferences management code) is simpler than the previous prototype implementation. In that previous prototype (and the current implementation), I was able to opportunistically support an EditorConfig-style model where settings files could appear in any directory above the file being edited (I call these path-based Scopes). Note the "file being edited" part of that. Peter Flynn has brought up cases like whole-project linting or even split views where you need the preferences for a specific file. This gets further complicated by the fact that you may have a file open which is not even in the current project. I've been thinking about how to implement proper support for all of that and my thinking is that this will add a good deal of additional complexity to the implementation of path-based Scopes. I suggest that we actually rip out the code for path-based Scopes, because I don't think the complexity is worthwhile.
Essentially, what I'm proposing is that the complexity be moved from Brackets core code into any EditorConfig extension that people might write. If we decide to support EditorConfig in code that we support, we could still implement it in an extension. What do you think, |
let me see if i get it right: instead of having PathScopes, there will be a fixed (non-globbed or static) "project" scope and PathLayers (and other type of layers later) will still be supported. default scope order will be "session", "project", "user", "default" if it is so, it makes a lot of sense to me. firstly, it will be much easier (predictable) to work with scopes from an extension (project will be named and known instead of dynamic as with path scopes now). secondly, it's hard to predict what pattern may become popular upfront and adopting an established pattern of working with/structuring config files later makes sense. |
Yes, you've got my plan exactly right. With this change as it is now, If someone wanted to add EditorConfig support in the future, I'm thinking |
Oh, I should mention that there is another way in which path-based Scopes are superior: when you’re editing files that are outside of your current project. If you edit a file within your project, the project Scope will be loaded and settings from it will be applied to the files within the project. However, if you drag a random file into Brackets, even if there’s a .brackets.json somewhere in the file tree above it, only the user and default settings will be applied for editing that file. With path-based Scopes, the .brackets.json file above the outside-of-project-file would be found and its settings applied. That’s more compelling to me than the EditorConfig case, but I don’t know if it’s worth adding complexity for. It is also behavior we can choose to adopt later. |
FYI, I've pushed commits that move things forward in the path I wrote about above. At this point, there's some tying up of loose ends I need to do as well as testing.
|
i'm seeing you've yanked some tests related to the path scopes. i wanted to refactor them to catch async failures. some that should fail now (due to my changes) actually pass. i believe, though it would be better if we make it a separate step -- i'll merge after you finish this one and refactor the tests. |
This is ready for review. I haven't had a full run of the integration tests yet and I intend to do some manual testing, but I've checked off everything on my list so far and done some initial testing. |
|
Adding a separate ProjectScope module would have a circular dependency again: PreferencesManager depends on ProjectScope which depends on ProjectManager which depends on PreferencesManager. Basically, my dislike for circular dependencies is greater than my dislike for things like ProjectManager needing to know that there's a preferences manager that's interested in what project is being edited... |
Just found a funny bug. This looks normal:
If I drag a file from outside the project into Brackets, this happens:
I'll have to track this down later. I also want to do some profiling after I've finished the PreferencesManager change to reduce the construction of new contexts. |
i guess my idea was simpler: separate |
It looks like the DocumentCommandHandler tests are passing again. |
I am seeing 1 test fail: PreferencesManager: "should find preferences in the project" |
Done with review. |
OK, I've addressed the review comments. The PreferencesManager integration test is passing for me. Can you update and try it again? |
I am seeing JSLint errors in: Editor.js, PreferencesBase.j, and PreferencesManager.js. |
Ugh. I had accidentally collapsed my error panel and so I missed the one in Editor.js. The other two files (PreferencesBase and PreferencesManager) don't have JSLint errors for me. Those two files, possibly not coincidentally, rely on the jslint.options from .brackets.json (they don't have a What kind of JSLint errors are you seeing? Is there anything in your console? (And what Brackets are you running?) |
My Brackets version is your branch :) Here is what I have in my user options:
Here are the first 50 errors:
|
Did you open brackets at the top level folder, or at the src folder? |
Ah. My project was set to the src folder. |
I don't think there's anything else to be done for this pull request. In a subsequent one with |
|
Merging. |
Friday Jan 31, 2014 at 16:00 GMT
Originally opened as adobe/brackets#6715
This is a fix for #6578, along with an API improvement as discussed briefly in 6578. The API improvement is backwards compatible, with the exception of a change to the Editor's
optionChange
event which has been noted in the Release Notes for sprint 37.[redmunds] This also fixes #6682 and #6756.
cc
@
busykai@
peterflynndangoor included the following code: https://github.com/adobe/brackets/pull/6715/commits
The text was updated successfully, but these errors were encountered: