Bug 549447 - [Preferences] Allow to set preferences on a per contentType basis
Summary: [Preferences] Allow to set preferences on a per contentType basis
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Runtime (show other bugs)
Version: 4.13   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: platform-runtime-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-21 13:04 EDT by Jonas Hungershausen CLA
Modified: 2020-02-12 14:18 EST (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonas Hungershausen CLA 2019-07-21 13:04:16 EDT
It would be nice to have the ability to set preferences based on contentTypes of a file. 

For example, Dart is very strict on its indentation settings. It requires two-spaces indentation and its formatter doesn't allow to set these either.
Since I'd like to refrain from setting this globally, it would be nice to set this only for our Dart contentType (in the generic editor).
Comment 1 Mickael Istria CLA 2019-07-22 04:52:00 EDT
This would involve adding a new preference scope (possible via extension point already), and adding it to the "stack" of scopes used here and there to poll preferences.

For programmatical use only and usage in specific preference pages, it should be affordable.
However, if you want to expose a generic way for the user to modify these preferences, it would be hard to properly handle the modification workflow: when is user modifying only a preference for the scope vs a general preference...? Do you have need fr the later?
Comment 2 Jonas Hungershausen CLA 2019-07-22 08:15:47 EDT
> However, if you want to expose a generic way for the user to modify these preferences, it would be hard to properly handle the modification workflow: when is user modifying only a preference for the scope vs a general preference...? Do you have need fr the later?

I don't feel like that's necessary currently. As I said, the Dart formatter is very strict, and as it seems there are currently no plans to loosen this up. 

Maybe it would be feasible for us to add the appropriate settings to our own preference page if it's required in the future.
Comment 3 Eclipse Genie CLA 2019-08-07 13:01:42 EDT
New Gerrit change created: https://git.eclipse.org/r/147216
Comment 4 Mickael Istria CLA 2019-08-07 17:34:34 EDT
This requirement is not specific to Generic Editor. A new preference scope can apply to the whole IDE.
Comment 5 Jonas Hungershausen CLA 2019-08-08 06:00:48 EDT
(In reply to Mickael Istria from comment #4)
> This requirement is not specific to Generic Editor. A new preference scope
> can apply to the whole IDE.

I see, could you tell me in what project this would have to be implemented?
Comment 6 Mickael Istria CLA 2019-08-08 13:05:58 EDT
I think this work should be placed in org.eclipse.core.contenttype
Comment 7 Nitin Dahyabhai CLA 2019-08-08 14:10:20 EDT
I'm unclear on practical uses for this, apart from the Generic Editor.
Comment 8 Jonas Hungershausen CLA 2019-08-09 02:48:55 EDT
(In reply to Nitin Dahyabhai from comment #7)
> I'm unclear on practical uses for this, apart from the Generic Editor.

This could be useful for other editors used with different content types as there might be different preferences for different file types. Though, this would most likely be mainly used in the Generic Editor. 

For now the scope of the proposed patch would be to supply an extension point for devs. But later on it could be feasible to also have preference pages for each content type with the scoped preference (talking about indentation, and other editor related preferences).
Comment 9 Jonas Hungershausen CLA 2019-08-09 15:26:44 EDT
So, what do you think, Mickael? I could try myself on an IDE-wide solution soon, but would like to have an outcome of this discussion first, before spending time on that.
Comment 10 Mickael Istria CLA 2019-08-09 15:46:09 EDT
I think a content-type isn't a Generic Editor specific issue. So I have the feeling such preferences have to be generic and part of the org.eclipse.core.contenttype bundles.
But Nitin quesiton is relevant to ensure a good design. At the moment, I don't have obvious ideas of where cotent-type preferences may be used in practice out of Generic Editor; but I'll give it some thoughts and try to find other possible use-cases to drive us to the best decisions.
I agree that non-textual editors (like Diagram editors) may be interesting places where content-type specific preferences can be interesting. I also think the Project Explorer can be too; but this is still not precise enough to be interesting at the moment.
Comment 11 Mickael Istria CLA 2019-08-12 04:54:15 EDT
So I could think a bit about it, and the story of customizing for instance the formatting of the indentation for a text file according to the content-type is not speciifc to the generic editor, but instead to any text editor.
Ie a plain text editor could leverage content-type specific preferences.

For diagram editors, we could also imagine that some generic editor (like the reflective EMF or Sirius ones) that could read content-type preferences when opening a file to decide of some palette to use or of the default direction of the diagram (left to right; or top to bottom).

Content-type specific preferences would also be a more elegant way to store some content-type/editor associations built by user.
They could also be a nice way to allow user to override the content-type icon and some parts of the content-type definition.

In the Project Explorer, they could be a way to specify some options according to each file type, such as whether for a given content-type, we expand the children greedily or not.
Comment 12 Jonas Hungershausen CLA 2019-12-23 13:38:27 EST
I've tried looking for the best place to do this. But I can't really find a solution, that just sits in between components, to minimize refactoring.

Could you advise me on where to look?
Comment 13 Mickael Istria CLA 2020-01-06 04:54:18 EST
I think org.eclipse.core.runtime could be the best candidate as
1. it depends on org.eclipse.core.contenttype
2. it defines (thus can extend) the org.eclipse.core.runtime.preferences/scope extension to define some new scope.

Once we have a new scope, the hard(er) part becomes deciding how we chain it with existing one, which one has higher priority, and where to set/consume it.
Trying to use a new scope to implement the user-story defined in comment #0 (with Dart indentation settings) should give the right directions.