-
Notifications
You must be signed in to change notification settings - Fork 7.6k
Fix #4333 (Files incorrectly identified as plain text if folder's name has got the "#" char) #4379
Conversation
- Added FileUtils.getBaseName (jsdoc and unit tests included). - Replace usage of path-utils.js with getBaseName.
I also suggest that NativeFileSystem.Entry constructor (which is used to display base names in the project side bar) also takes advantage of the same FilUtils.getBaseName() facility. Currently, it's using splits path by separator and then iterates until the last name to get the base name for an entry. I intentionally programmed getBaseName so that it would support directories as well. |
Related to issues adobe#3269, adobe#4210. Based on the discussion and suggestions in adobe#3310. If a project has a .jslint.json in its root, it gets loaded and passed to each JSLint run within the project. The configuration file gets reloaded each time it is saved or refreshed.
This reverts commit 11dbdfd.
To @RaymondLim |
Yikes, this suggests to me that we should never use PathUtils to parse local paths -- I bet this isn't the only place where a "#" in a file/folder name breaks stuff. It seems only safe to use PathUtils on things that are actually true URLs. I see potentially unsafe uses in DocumandCommandHandlers, JSUtils, FileIndexManager, and UrlCodeHints/main. Should we file a new bug for all that, or try to tackle them here? Also, some unit tests of the actual affected functionality (e.g. LanguageManager APIs) are probably a good idea... |
Yes, PathUtils is a misnomer--it should really be called URLUtils. But we didn't write it so we can't change the name :) I think it would be good to fix all of them at once if it's relatively straightforward to do so. |
I can review the code for misuse of PathUtils. Should I file an issue? |
Here is the report on usage of PathUtils in entire brackets codebase:
In order to fix this, two more methods corresponding to the usage of PathUtils have to be added: getDirectoryName (analogous to dirname(1)) and getFileExtension. I will amend this pull request. |
This pull request is no good as is. Hold on until I update it, please. |
The tests assumed that CodeMirror modes are loaded at the time of test definition.
Conflicts: src/file/FileUtils.js
I need your advice: what is normally done when the unit tests starts failing because of loading sequence/timing has changed due to a fix? I found that the fix is causing some unit tests to fail. I specifically looked into CSSUtils and found (after some banging my head against the wall) that the 43885a6 is changing the load sequence, so b87f6a0 fixes it. The other tests that are failing are trickier... For example some EditorCommandHandler tests do not have Commands loaded at the time of execution. One fails with "cannot read property EDIT_DELETE_LINES of null", for example. When re-ran on its own, it passes. I'm going to resolve all these, but please let me know what you think... |
LanguageManager.getLanguageForPath should not use URLs. Instead, it should use local filesystem paths.
Also: Remove leftover reference to LanguageManager from FileUtils. Use existing code to implement getBaseName.
Implementation changed to use FileUtils.getBaseName and FileUtils.getFilenameExtension.
// verify editor content | ||
var mode = LanguageManager.getLanguageForPath("http://only.org/testing/the/path.css?v=2").getMode(); | ||
var mode = LanguageManager.getLanguageForPath("/only/testing/the/path.css").getMode(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a hypothetical test case. LanguageManager is used strictly to operate on local files. I think it was inspired by the fact that PathUtils was used to parse the file path in the first place.
@RaymondLim @njx @peterflynn this is ready for review. Ended up being not quite starter bug. :) |
@RaymondLim : @busykai is covered under the corporate CLA we have for Intel. |
|
||
/** | ||
* Get the base name of a file or a directory. | ||
* @param {string} full path to a file or directory |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need to add fullPath
right after {string}.
* | ||
* @param {string} full path to a file or directory | ||
* @return {string} Returns the extension of a filename or empty string if | ||
* the argument is a directory |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Append or a filename with no extension.
to this line so that we have more accurate description.
Thank you @adrocknaphobia ! I wasn't sure what's the right way to clarify this. |
Looks good. Merging. |
Fix #4333 (Files incorrectly identified as plain text if folder's name has got the "#" char)
Replaced usage of PathUtils (inappropriate for the task) with new FileUtils.getBaseName. JSDoc and unit tests included.