Can't get the context menu of a binary file

[JeffryBooher]

WHen right clicking on files that cannot be opened by brackets,
You get a "file cannot be opened" alert and then you cannot do other things to the file
such as rename, delete or "show in finder"

[lkcampbell]

@JeffryBooher, I'm thinking this issue may be at least a partial duplicate of #4690. It stresses what I believe is the most critical piece of the issue though. What are your thoughts?

[TomMalbran]

En easy fix for this is to add a Custom Viewer for the audio and binary languages and try to change the language of a file that was not on the list but couldn't be opened to binary. The Custom Viewer could just show basic info on the file and maybe some message, and maybe an icon.

If we do that, we won't have any issue with showing the file on a right click.

[JeffryBooher]

a custom viewer seems like a lot of work.

[TomMalbran]

It is not really that complex. Is just an html file with like 10 lines of code and like 50 lines of JavaScript. It will just show basic information, so it won't be as complex as the images viewer. My fonts viewer is more complex than this and the JavaScript file is about 100 lines of codes with lots of comments.

It will also make it a lot better experience than showing a popup when selecting a binary file.

[JeffryBooher]

I said "seems-like" :) and I meant "for me". It does raise a few questions though. I'm guessing it works sort of like images do so they aren't in the working set. This will eventually change as we plan to do split view with things in the working set that aren't necessarily editable. Let me take a look at your fonts viewer I'm thinking we would definitely like to fix #4690 as you suggested but this may be something to ponder.

[TomMalbran]

I don't think that it would be a bad idea to place the binary files with their custom viewers in the working set. It might be better to just treat those files as normal files. This will fix this, but is mostly a fix for #7608.

Issue #4690 should be fixed since is not only an problem for binary files, but also for huge minified files, that will still open but take a long time.

[bchintx]

Assigning to @TomMalbran

[peterflynn]

@TomMalbran One tricky part is that custom viewers are currently keyed off of LanguageManager language id, which in turn is driven by file extensions alone. But we probably want to write this in such a way that it works for all binary files, not just the ones we explicitly put in our list of known-binary file extensions. Ditto for non-UTF-8 files, which have the same problem (e.g. see #8083) and which will have the same extension as an existing plain text language. The "view factory" idea that's coming as part of split views may give us an easier path to solving these issues cleanly, though...

@JeffryBooher It seems like the 'in working set' bit gets solved for free with the split view work, so hopefully that's a non-issue here soon.

[peterflynn]

Note: I've closed #8083, which is describing the same exact problem except for non-UTF-8 files -- which are effectively the same as binary files from Brackets's standpoint. We should try to fix both cases together.

[JeffryBooher]

@peterflynn I think that comes at the end with Images in the working set but I agree and we should probably add that the the test plan.