adobe / brackets

An open source code editor for the web, written in JavaScript, HTML and CSS.

⚠️ On September 1, 2021, Adobe will end support for Brackets. If you would like to continue using, maintaining, and improving Brackets, you may fork the project on GitHub. Through Adobe’s partnership with Microsoft, we encourage users to migrate to Visual Studio Code, Microsoft’s free code editor built on open source.

Welcome to Brackets!

Brackets is a modern open-source code editor for HTML, CSS and JavaScript that's built in HTML, CSS and JavaScript.

What makes Brackets different from other web code editors?

• Tools shouldn't get in your way. Instead of cluttering up your coding environment with lots of panels and icons, the Quick Edit UI in Brackets puts context-specific code and tools inline.
• Brackets is in sync with your browser. With Live Preview, Brackets works directly with your browser to push code edits instantly and jump back and forth between your real source code and the browser view.
• Do it yourself. Because Brackets is open source, and built with HTML, CSS and JavaScript, you can help build the best code editor for the web.

Brackets may have reached version 1, but we're not stopping there. We have many feature ideas on our trello board that we're anxious to add and other innovative web development workflows that we're planning to build into Brackets. So take Brackets out for a spin and let us know how we can make it your favorite editor.

You can see some screenshots of Brackets on the wiki, intro videos on YouTube, and news on the Brackets blog.

How to install and run Brackets

Download

Installers for the latest stable build for Mac, Windows and Linux (Debian/Ubuntu) can be downloaded here.

Usage

By default, Brackets opens a folder containing some simple "Getting Started" content. You can choose a different folder to edit using File > Open Folder.

Most of Brackets should be pretty self-explanatory, but for information on how to use its unique features, like Quick Edit and Live Preview, please read How to Use Brackets. Also, see the release notes for a list of new features and known issues in each build.

In addition to the core features built into Brackets, there is a large and growing community of developers building extensions that add all sorts of useful functionality. See the Brackets Extension Registry for a list of available extensions. For installation instructions, see the extensions wiki page.

Need help?

Having problems starting Brackets the first time, or not sure how to use Brackets? Please review Troubleshooting, which helps you to fix common problems and find extra help if needed.

Helping Brackets

I found a bug!

If you found a repeatable bug, and troubleshooting tips didn't help, then be sure to search existing issues first. Include steps to consistently reproduce the problem, actual vs. expected results, screenshots, and your OS and Brackets version number. Disable all extensions to verify the issue is a core Brackets bug. Read more guidelines for filing good bugs.

I have a new suggestion, but don't know how to program!

For feature requests please first check our Trello board to see if it's already there; you can upvote it if so. If not, feel free to file it as an issue as above; we'll move it to the feature backlog for you.

I want to help with the code!

Awesome! There are lots of ways you can help. First read CONTRIBUTING.md, then learn how to pull the repo and hack on Brackets.

The text editor inside Brackets is based on CodeMirror—thanks to Marijn for taking our pull requests, implementing feature requests and fixing bugs! See Notes on CodeMirror for info on how we're using CodeMirror.

Although Brackets is built in HTML/CSS/JS, it currently runs as a desktop application in a thin native shell, so that it can access your local files. (If you just try to open the index.html file in a browser, it won't work yet.) The native shell for Brackets lives in a separate repo, adobe/brackets-shell.

I want to keep track of how Brackets is doing!

Not sure you needed the exclamation point there, but we like your enthusiasm.

What's Brackets working on next?

• In our feature backlog, the columns to the right (starting from "Development") list the features that we're currently working on. "Ready" shows what we'll be working on next.
• Watch our GitHub activity stream.
• Watch our Waffle Kanban board: Work items in are next. The entire development process is outlined in the Developer Guide.

Contact info

• E-mail: [email protected]
• Slack: Brackets on Slack (You can join by sending a mail to [email protected] with the subject line slack registration request specifying the email addresses you would like to register).
• Developers mailing list: http://groups.google.com/group/brackets-dev
• Twitter: @brackets
• Blog: http://blog.brackets.io/
• IRC: #brackets on freenode

---

Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.

brackets's Issues

Descenders are clipped in .toolbar .title

Text descenders (lowercase j, p, y) are visibly clipped in the project title and the editor file name. Use a file or project name with a lowercase j to see the bug.

Scrub code to use === where appropriate

Our code isn't currently consistent about using == vs. ===. In general, it's probably safer for us to use === everywhere, since == does type conversion. (For example, if you compare an object to a string, the object's toString() method will be called.) We need to establish rules for this, and then fix up the codebase where necessary.

Tighten up padding in the file list

We probably shouldn't do a ton of visual tweaking until we have actual visual designs, but if it's easy, we should reduce the padding between the items in the file list--the spacing feels a little loose. Might also want to consider using a smaller font size, more similar to what Finder uses. (We'd probably also want to reduce the default editor font size as well.)

Horizontal scrollbar intermittently disappears in first file opened

Steps:

1. This bug only repros with the multi-file stuff, so until it's merged you'll need to be on the implement-file-working-set branch
2. Launch Brackets (important -- will not repro if Brackets has been open for a while)
3. Open brackets.js
   -- Note horizontal scrollbar
4. Scroll down to the top of the $.ready() listener in the code

Result:
Horizontal scrollbar disappears. It reappears if you scroll back up.

Expected:
Horizontal scrollbar visibility should not change depending on scroll position.

Once you've opened a second file, the bug no longer repros in any file (including the original).

Should block UI during most asynchronous operations

Currently, we don't do anything to block UI while waiting for an asynchronous step in the middle of an operation, even when that overall operation should probably feel atomic. We probably already have many buggy cases is an async operation were to run slowly.

Here's one example:

1. Click on a file to open it
2. Loading is taking a long time... get bored and click on another file to open it
3. For whatever reason the 2nd file loads much faster, so now it's shown in the editor UI, and you start editing it
4. Later, the original file's async load request finally completes -- and the editor UI you're using is yanked out from under you and replaced with the editor for the original file. Ugh!

In practice, most of the APIs we treat as async today are actually implemented synchronously, so many potential bugs (including the above example) don't happen today. But as soon as we have to a Node- or cloud-based backend, all of these bugs will come to the surface at once.

We should probably have an overarching architecture to deal with marking the start/end of "blocking" operations to eliminate this entire class of bugs.

JS crash when trying to save over read-only file

Steps:

1. Open a file that is read-only in the filesystem
2. Make some edits
3. Cmd+S

Result:
Crash in FileCommandHandlers, in the writer.onerror handler nested within handleFileSave().
It looks like it is expecting to be called with a dispatched event as its argument, while NativeFileSystem is invoking it directly and simply passing it an un-wrapped error object (not an event).

Expected:
No crash. User-friendly error dialog appears indicating file not saved.

Selection range is not restored after undo

1. Select some text
2. Hit delete
3. Undo

Result:
Deleted text is restored, but selection is not. You're left with just a blinking cursor where the end of the selection range was.

Expected:
Selection should be restored too. This is what pretty much every other text editor I've ever used does.

Inconsistent selection when closing subfolder of project folder

1. open file in a subfolder of project
2. make edit in so file is displayed in Open files folder
3. close subfolder using triangle icon

Results:
folder is selected

Expected:
folder is not selected

1. re-open folder

Results:
folder is still selected

E-mail thread comments:

[ty] Bug, looks like the default jstree implementation is to select the parent

[peter] I’m not sure what the expected result should be here. In Windows, when you collapse a subtree containing the selection, this is what happens. On Mac, the rule seems to be that we clear the selection instead. In Espresso, this actually clears the editor too (i.e. it closes the open doc from the hidden subtree and doesn’t open any other doc).

[randy] It doesn't make sense to me to clear the editor. I'd rather see the current working set file displayed until something meaningful is selected in the project folder. I suggested to not select the folder for the sake of consistency.

Missing error when writing locked file

1. Lock a file (in Finder)
2. Modify file contents and save in brackets
3. Use another editor to inspect contents

UI shows that the file is still dirty. Looks like Chris' fix for #52 (in pull request #78) to pass a fake event with target=_FileWriter should fix it.

Uncaught TypeError: Cannot read property 'error' of undefined

Unexpected results for file drag/drop in editor window

1. drag file from Finder to Brackets editor window

Results:
contents of dragged file is embedded in existing file at the point where it was dropped

Expected
either open file for editing, insert a file reference, or nothing

Should add dummy editor content when running in the browser

Currently, when you run Brackets in the browser, we add dummy content to the tree, but don't have any content in the browser. We should add dummy content there as well, so we can test editor functionality in the context of the browser.

Scroll position is lost when switching editors

1. Open two files (so that both are listed in the working set)
2. Scroll to the bottom of file A
   (3. optional: Place the cursor down there, maybe even select some text)
3. Switch to file B, then switch back to file A

Result:
View of file A is scrolled back to the top. The cursor location (and selection) is still preserved at the bottom of the file, so if you hit the arrow keys the view will jump back down to (approximately) where it was before.

Expected:
Scroll position is preserved.
(The behavior is the window has been resized since last viewing the file is a little tricky, but I think essentially we should aim for keeping the same line at the top of the viewport).

Handle existing Untitled.js file for File > New

When creating multiple new files, File > New should initially propose a unique name like Untitled-1, Untitled-2, etc if Untitled-N already exists.

Can't trigger UI events from Jasmine

This might need to get translated into a task for a sprint, but I wanted to start by capturing it here as an issue

Look at the follow unit test in WorkingSetView-test.js (code sample below)

it("should close a file when the user clicks the close button", function() {

        // make both docs clean
        var docList = DocumentManager.getWorkingSet();
        docList[0].markClean();
        docList[1].markClean();

        // make the first one active
        DocumentManager.showInEditor( docList[0]);

        // click on close icon of 2nd one
        var listItems = this.app.$("#open-files-container").children("ul").children();
        var closeIcon = $($(listItems[1]).find(".file-status-icon"));
        //expect( closeIcon.toBe(1);

        // simulate click
        closeIcon.trigger('click');

        var listItems = this.app.$("#open-files-container").children("ul").children();
        expect( listItems.length ).toBe(1);
        expect( listItems.find("a").get(0).text == "file_one.js" ).toBeTruthy();



    });

The closeIcon.trigger('click') does not trigger the click event handler. If I use the same code in the console of CES it works. There is probably a inter-window security issue here we need to solve

Code editor should have I-beam cursor, not box

Ever since our LESS refactoring, the text cursor in the code editor has been a solid blue box the full width of one char. Previously, it was a thin vertical line at the left edge of the char's bounds.

Normally, a full-width box is only shown in an editor when in 'overwrite' mode, and the thin I-beam cursor is shown most of the time (i.e. when in 'insert' mode). We should follow this convention too.

Keystrokes ignored after full undo

1. Create a new empty file
2. Type something
3. Undo until the document is empty again
4. Try typing

Keystrokes are ignored. Exception thrown in codemirror:

Uncaught TypeError: Cannot read property 'length' of undefined - codemirror.js:2286
copyStyles - codemirror.js:2286
Line.replace - codemirror.js:2073
updateLinesNoUndo - codemirror.js:550
updateLines - codemirror.js:510
replaceRange1 - codemirror.js:661
replaceSelection - codemirror.js:652
readInput - codemirror.js:716

Opening certain folders in the file navigator throws exceptions and the folder fails to open

1. Launch branckets
2. Choose "Applications" as your root directory
3. Try to open various folders. On my machine quite a few of them fail to open and the console shows exceptions.

The exceptions are coming form the definition of brackets.fs.readdir in brackets_extensions.js. It looks like JSON.parse doesn't like some of the JSON we are passing it

requestNativeFilesystem cannot take relative paths

NativeFileSystem.requestNativeFileSystem does not currently accept relative paths. Currently, asking for path "." gives the directory "/"

It should return the directory that the window's HTML file is in.

This may be an issue with the brackets-app side of the bridge.

File menu remains open while Open dialog is visible

Steps:

1. File > Open

Result:
Native "Open File" dialog appears, but File menu is still open in the background behind it.

Expected:
File menu closes before dialog appears -- this is how all native apps behave.

I assume to fix this we have to open the dialog a little asynchronously to give the browser time to render the DOM update after closing the menu. Seems a little tricky since we'd probably just be guessing how long that will take, making the "fix" just a probabalistic race condition.

File > Open doesn't remember last folder

Steps:

1. File > Open
2. Choose a file somewhere outside the project (e.g. on your desktop)
3. File > Open again

Result:
Both times you open the dialog, you start in the root folder of the project.

Expected:
The second time, you should start in whatever folder you selected from within the first time (e.g. your desktop).

Double-click-drag doesn't select properly

1. Type some words
2. Double-click on a word, then drag with the mouse still held down

Result: doesn't properly extend the selection. This gesture should start by selecting the double-clicked word, and then extending the selection to include other words as you drag.

Double-clicking on item in file tree prevents typing in code editor

This is reproducible in both master and the new implement-file-working-set branch.

1. Double-click on the name of a file in the file tree
2. Start typing
   -> Nothing happens
3. Click back in the code editor and try to type again
   -> Nothing happens--you can select and scroll around, but you can't type

If you single-click on another file, typing starts working again.

Lion: typing a character in editor causes scroll bars to appear

Steps to reproduce:

1. Be running Lion
2. Open a file with horizontal and vertical scrolling content
3. Type into the file
4. Observe the scroll bars. Both horizontal and vertical scroll bars appear if there is horiz/vert scrollable content

Brackets doesn't lay out properly in Firefox

1. Open brackets/src/index.html in Firefox

Result: App doesn't lay out correctly. This is probably because we're using (the older version of) flexbox layout, which might not be supported the same way in Firefox.

Brackets app is replaced with file dragged/dropped into Open files folder

1. drag file from Finder to Open files folder

Results
file replaces entire Brackets app!

Expected
file is opened in editor, or nothing

Selection drawing is broken

Steps to repro:

1. Give the div with class ".content" a background color. For example:
   $(".content").css("background-color", "#aaa")
2. Select some text

Result: text selection is not drawn.

FileCommandHandlers-spec unit tests purport to reload the window between tests, but effectively do not

In our unit tests for FileCommandHandlers, there is a beforeEach() function that purports to reload the window in between tests, ensuring a blank slate for each test. Although it does so, it always hangs onto the JS module objects from the initial window load, meaning that all tests share the same module state -- not a blank slate at all.

It turns out this is quite tricky to fix, because it's difficult in JS to wait for a window to reload. The old document does away asynchronously, so it's hard to know when to attach load/ready listeners. If you attach them too soon, you'll attach them to the old document -- meaning, depending on which call you're using to attach them, they will either run immediately (too early) or will never run (since the old document goes away).

This isn't a problem on master because the file commands are essentially stateless. However, the working set stuff makes them not stateless, so that having all these supposedly independent tests sharing state becomes a problem.

Jason and I are looking into this.

File > New fails silently if folder is read-only

Steps:

1. Create a folder that you do not have write access to (i.e. that you cannot create new files within)
2. Point Brackets at this folder
3. File > New
4. (optional) Type a new file name
5. Hit Enter

Result:
The new item in the folder tree disappears. No file is created or opened in the editor, but no error message is shown either.

Expected:
Error dialog appears.

add check to all public constructors to ensure they are called with 'new'

All public constructors should verify that they were called with 'new'. If they were not, they should throw an Error.

It should look something like this:

function Waffle(diameter) {
    if (!(this instanceof Waffle)) { // ERROR: constructor called without 'new'
        var e = new Error("Waffle constructor must be called with 'new'");
        e.detail = { waffleSizeDesired: diameter };
        throw e;
    }
    this.diameter = diameter;
    this.tastes = "yummy";
}

Can't dismiss error dialog with keyboard

1. In navigator, select a non-text file (e.g. jpg)
2. Modal dialog is displayed with "Error opening file" message.

Result
Cannot dismiss dialog with keyboard. Must use mouse. Note that any keystrokes go a dummy file in the editor!

Expected
There is at least 1 key (or key combination) that dismisses dialog.

Expanding Empty Folder losses widget

1. Open a project folder that contains an empty folder
2. Click on the arrow to expand the empty folder

Result: Arrow disappears (and now you can't tell it's a folder)

Expected: I think having the arrow point down with no children should be enough of an indication.

Tab key inserts tab character, not spaces (unless entire line selected)

Steps:

1. Place the cursor anywhere (without selecting any text)
2. Press tab
3. Use the arrow keys to move past the inserted space

Results:
The inserted space is a tab char: the cursor jumps from one end of space to the other with a single press of the arrow key.
(You can also confirm this by cutting & pasting the text into another editor and inspecting it there).

Expected:
Eventually this should be configurable, but for now we should default to spaces, not tabs -- otherwise we can't dogfood with Brackets.

Note that if you select one or more entire lines of text, then press tab, the indentation added that way does use four spaces.

Default indentation should be 4 spaces

1. Create a new JS file
2. Type function foo() { and hit Return

Result: next line is indented 2 spaces. Should default to 4 as this is more common (and happens to be our default as well).

Folder tree should hide .DS_Store & friends

1. View a folder in Finder
2. Open that folder in Brackets

Result:
.DS_Store file is listed in root of project folder tree UI

Expected:
Low-level OS files like .DS_Store and Thumbs.db should be hidden from view pretty much always.

Debatably, all dotfiles should be hidden from view... at least by default. (examples: .git folder, .svn folder)

ProjectManager refactoring suggestions

Currently, there is some code (initProject()) related to the initialization of the project UI in brackets.js (it attaches various event handlers to items inside the project panel). In general, it seems like any initialization of UI that's associated with a module should be moved into that module.

A bigger issue is that ProjectManager really includes both model and view code, whereas our other Managers are really models, I think. It might make sense to factor the UI code out into a separate ProjectView, and have the ProjectManager dispatch events to the view. (Or perhaps we should just rename ProjectManager to ProjectView.)

Selecting a folder in navigator shows "Error opening file"

1. Set current folder to a folder with sub-folders
2. Select a sub-folder

Result
"Error opening file" error is displayed

Expected
Folder opened/closed state should be toggled (same as clicking arrow).

Use mock persistent storage in PreferencesManager for unit tests

With preferences stored in the browser's local storage, unit tests are now side-affecting the running brackets workspace by persisting the last open project.

add more actual colors to the code coloring mappings

To make the work that @chrisbank did more beautifuler.

File > Open results in runtime error

Steps to repro:

1. Launch Brackets
2. Open the developer tools
3. Select File > Open (from the main toolbar, not the os menubar)

Results:
Runtime error reported in console

color literals should be factored out of jsTreeTheme.less

Note: This can't be done until the less-cleanup branch is merged into master.

File tree/header looks a little odd when scrolled

1. Open a project with a lot of files (or expand a lot of subfolders)
2. Scroll down in the file tree so that the top of one of the filenames is clipped

Result: Looks a little odd when it's clipped, because there's no visible affordance underneath the "Project Files" header that's clipping it. One solution I saw recently that I liked is in Gmail: when you scroll the content, a shadow appears underneath the header area. Seems simple to implement.

Opening file via menu does not update navigator selection

1. Open any file in navigator
2. Use File > Open menu to open a different file

Results:
First file is still selected in navigator

Expected:
If second file is under current folder, then it should be selected in navigator. If second file is not under current folder, then we should probably show nothing as selected in navigator (I don't think we want to change current folder).

File names in LowLevelFileIO-test-files/special_char_files are illegal on Windows, breaking git pull/merge

This commit added two files that are illegal filenames on Windows:
46e006f
This was a change by Ty that Glenn merged in this pull request #27.

Attempting to git pull or git merge this commit on Windows causes errors and leaves your source tree in an inconsistent state (a mix of unstaged changes, untracked new files, and files that never even got updated... thus the project is broken because some of the code is updated and some isn't).

Ideally, we would just use a unit-testing shim that feeds fake filenames to the native JSON encoding stuff, rather than having actual bad filenames checked into our source tree. Failing that, maybe we can segregate them into a Mac-only part of the source tree that can be left out on Windows? (That feels like a very Perforce-ey approach, but there must be some way to do that on Git too).

Opening a project with a long file name messes up UI

Opening a project with a long file name causes the "Open" button to wrap to next line, which is half off the header bar.

Extra file created when trying to create new file in empty folder

1. Create a new folder in your project (using Finder).
   
   NOTE: do not expand or drill down into the folder in Finder, since this may create a .DS_Store file inside it, making it non-empty. (Once issue #98 is fixed, however, this precaution presumably won't be necessary in order to repro).
2. In the containing folder of this new folder, place a .js file
3. Open the containing folder in Brackets
4. Select the newly-created empty folder
5. File > New
   
   ---> nothing appears to happen; you can try to type a filename and hit enter (thinking the inline editor is just invisible), but no file is actually created. Hitting the disclosure triangle does nothing.
6. Select the .js file from step 2
7. File > New again
   
   ---> inline editor appears in the containing folder (next to the .js file), as expected
8. Type a filename -- say, foo.js -- and hit Enter

Result:
Two files are created, both with the name you typed in step 8 -- one file in the containing folder, and one file in the (previously empty) subfolder.

Expected:

• After step 5, the subfolder should pop open and show an inline editor (just as it would if it was non-empty).
• After step 8, a file should only get created in the containing folder (where the inline editor appeared).

I assume something is blowing up in the first invocation of File > New, and its Deferred object (or some other event listener) is somehow getting intertangled with the next invocation of New.

Opening empty folder shows "Loading..." forever in project panel

1. Create an empty folder on disk
2. Run Brackets
3. In the Project panel, click "Open" and browse to the empty folder

Result: Project panel shows "Loading..." forever. Even if you create a new file, "Loading..." still appears in the tree.

NPE, and ProjectManager loadProject never resolves, if open folders are missing

Steps:

1. Open a project containing a disposable subfolder
2. Expand the subfolder in the project tree
3. Quit Brackets
4. Delete the subfolder
5. Re-launch Brackets

Result:

1. Crash in jsTree code -- looks like because ProjectManager's reopen.jstree handler sets data.inst.data.core.to_open to [undefined]
2. The Deferred returned by ProjectManager.loadProject() is never resolved. Any listeners will wait indefinitely (this can cause unit test failures because the test will time out waiting for the test-driven Brackets window to finish initializing).

Workaround: Delete your cache at /Users//Library/Application Support/com.adobe.Brackets.cefCache. This only has to be done once. Following unit test runs will complete without issue.

turn "selectability" off in most UI elements

Right now, you can "select" (i.e. text select) most UI elements.

This should probably be turned off by default (inherited) for everything, and turned on for things we want to be able to select (code).

Close file icon is not displayed until mouse is moved

1. open 2 files in working set
2. move mouse over first filename in list
3. move mouse over (x) icon
4. click on (x) icon without moving mouse

Results:
first file is closed, and mouse is over filename that was second (now first), but (x) icon is not displayed. I have to move mouse to get (x) icon.

Expected:
(x) icon is immediately displayed

Clicking anywhere in tree row should select the file and selection should fill full row

1. Run brackets
2. Click in the space to the right of "index.html"

Result: Doesn't select the item. On Mac, the expectation would be that clicking anywhere in the row selects the item.