Large File Association with added editors and content types

[ajohnson1]

Eclipse Memory Analyzer handles huge heap dump files and generates giant index files. It has content type / editor associations for those files. It is an RCP application, and doesn't include the General>Editors>Large File Associations preference page. It can be installed into the Eclipse IDE. If the large file association 'not listed types' preference is turned on, then the end user would have to configure all the Memory Analyzer types to avoid a prompt from the large files associations.

1. Is there a way for the Eclipse Memory Analyzer feature to automatically turn on the file types / editors when it is installed / activated?
2. Eclipse Memory Analyzer operates on content types, not just file extensions. Some of the content types are provided to Eclipse Memory Analyzer by extensions, so Eclipse Memory Analyzer doesn't know at compile time the extensions. How should those extensions be provided?
3. How should files ending ".hprof.gz" be handled? Memory Analyzer doesn't know in general how to handle gz files, so shouldn't register for large files for .gz.
4. Should large file association be enhanced to work with content types?

[mickaelistria]

I think Platform can be improved to only prompt in case of a File Editor is used. IIRC MAT doesn't use such a File Editor so the size restrictions shouldn't really affect it.

[ajohnson1]

I think MAT does use implement file editor org.eclipse.mat.ui.editor.PathEditorInput.

This is used if there is a heap dump in a project explorer tree etc.

Perhaps Large File Associations for the IDE should just be set by the user - as limits depend on the user's machine. MAT has handled a heap dump file of 159Gbytes, but with a 172GB heap! There might be a use case for suggesting an external tool instead.

I think the way forward would be for large file association to also work with content types. This would require a bit of design though.

E.g. the preference page would also have a 'Content types' table below the 'File types' table. An 'Add' button would bring up a selection dialog with a tree view of existing content types.

The associated editor table would then operate on the selected item. Perhaps the add associated editor button should be disabled if there is a selection in both the file type and content type tables. Or the two tables could be combined?

Then, when there is a large file for consideration. If there are large file associations for content types, then content types are found via the Platform.getContentTypeManager().findContentTypesFor(). For each type, look for a match, or go to the parent etc.. The multiple types are then returned, and the largest file size handler is chosen as before? Also add the results from the file extension search.

The editor selection dialog could also have a check box for 'Use this editor for files with size over XXX bytes.'

[ajohnson1]

I have prototyped this, and while not complete it does work, with some rough edges.

The content types for the file need to be found, and processed in an appropriate order, more specific first, but also considering parent types. If there is a large file preference for the type, and the preference is active (large enough) for the file, then use that selection. Otherwise, revert to matching for large file preference via file extension. It isn't a good idea to put all the preferences for all the types in the list - as a more general content type which suggest 'prompt' could override a more specific preference for an editor.

If the large file preference from a content type is 'ask via pop-up' then the content type, not the extension, needs to be used for the 'Use this editor for ? files of size over ? bytes' button / check box. That can then be used to change the preference on return.

I think it would also be useful to display a tree of valid content types for the file, and if any are selected, also update the large file preference for those.

Then these is the choice of how to store these preferences. To keep things simple I chose to keep the same preferences, and overload the meaning of some of them:

So instead of org.eclipse.ui.workbench/largeFileLimits_types=java,xml,txt this would be for a content type as well org.eclipse.ui.workbench/largeFileLimits_types=java,xml,txt,org.eclipse.core.runtime.text and org.eclipse.ui.workbench/largeFileLimits.org.eclipse.core.runtime.text=4096,org.eclipse.ui.DefaultTextEditor,8192,largeFileLimits_prompt

That should work provided no content type is simple, without a dot, or the large file extensions is extended to try to consider long extensions, e.g.: .txt.gz

Then the preferences page would need to be updated. For testing, I just modified the add test to allow dots if the name was a valid content type ID. Really, it would be better selecting from a tree view of content types, perhaps displayed below the file types section. A selected content type would then allow the user to add the associated editors. The tree would be have check boxes for the content types, to enable/disable the file types for a content type. That should only update org.eclipse.ui.workbench/largeFileLimits_disabled or org.eclipse.ui.workbench/largeFileLimits_type if there were some editors configured.