We attempt to open binary files on Windows about brackets-app HOT 7 CLOSED

I think this bug actually cuts across brackets + brackets-app. It appears that our impl of fs.readFile() (and thus also FileReader.readAsText()) is wrong; it errors out on Mac when trying to read binary data when it should actually return some sort of (garbled) string. Our UI code is also wrong because it determines whether a file is openable or not by expecting this (erroneous) error signal... which means on Win, where the APIs work the way they're supposed to, the UI proceeds to open the garbled text instead of showing an error.

from brackets-app.

We should fix this in sprint 3 - adding label.

from brackets-app.

It's relatively easy to determine if a file is ASCII or not, but when you start considering UTF-8, UTF-16, and other encodings, it's not easy to determine. Take a look at the algorithm discussed in this post:
http://stackoverflow.com/questions/277521/how-to-identify-the-file-content-is-in-ascii-or-binary

Some of our competitors determine this, at some level, anyway, but others display garbage as we currently do.

Should this be required for Sprint3? Which types of text should we detect?

from brackets-app.

Could we do a simple extension check for now? Eventually, if (when?) we show image previews in Brackets, we'll need to be looking at file extensions anyway.

from brackets-app.

I agree with Glenn's suggestion. That's basically what Dreamweaver does. It has a table of file extensions it knows it can't open and if the file extension isn't on that list, it tries to open it. The algorithm approach sounds like it might be expensive.

from brackets-app.

The DW approach is acceptable because that list can easily be updated via DW preferences. But there is a group of developers (not sure how large) that like to use files with no file extensions which is not possible in DW.

from brackets-app.

Closing and moving to the Product Backlog.

from brackets-app.