[Monodevelop-devel] Per-project styles & policies

[Lluis Sanchez Gual]

El dl 29 de 09 de 2008 a les 16:51 -0400, en/na Michael Hutchinson va
escriure:
> Hi everyone,
> 
> Here are my current thoughts concerning per-project styles and
> policies, so that we can discuss it before I go ahead and implement
> it. I also have an number of questions that are interspersed
> throughout this email.
> 
> Rationale
> =======
> There are a number of settings and preferences in MD that should be
> customisable for different solutions/projects. Basically, anything
> that affects the style of the code you write should be able to be set
> for a particular project, since different projects have different
> styles and policies. I've lumped "Styles and Policies" together into
> one heading since I believe they are related.

Regarding styles, I want to stress that they are "anything that affects
the style of the code you write", which means that settings such as
indent mode (auto, smart) are not styles.

> 
> Text Editor Settings
> ==============
> These are the ones that most people care about -- per-mimetype
> settings for the general text editor behaviour such as tabs-to-spaces,
> editor width, tab width, standard headers. Some languages may add to
> this, e.g. C# indenter behaviour, and in future things like
> auto-formatting.

Indenter behavior and auto-formatting are not styles, and should not be
added to project preferences. On the other hand, formatting rules are
styles.

About storing styles per-mimetype, I'm not sure this is needed. It makes
more sense to present styles to the user organized by file type, but at
a higher level than mime type. For example we could present settings for
C#, ASP.NET, XML. Those file types could be sub-divided in mime types if
we really need that level of detail.

> There should also be a "default" style, and the
> per-mimetype settings should override this.
> 
> * Should we allow users to add custom mimetypes for their own file
> formats, or just support the "major" text/code mimetypes registered in
> MD?

I think we should allow binding mime types to file type categories
(e.g. .addin files to XML category).

> * Should we list only the mimetypes used in the project?

We should somehow filter out file types which don't make sense in a
given project. For example, ASP.NET styles should not be shown in a GTK#
project (although makes sense to show XML settings in all kind of
projects).

> * For each mimetype, should there be a checkbox to override the
> "default" text style? Or should there be a UI for adding/removing text
> styles to the tree?

I don't know how you plan to implement the GUI. IMO, style settings
could be implemented just like other project settings, using option
panels. By changing a setting you would be overriding it. There could be
a button for restoring default settings.

> 
> Policies
> ======
> There are a number of other per-project settings that aren't quite
> styles, but also aren't really build options or project properties.
> I'm calling these "policies" for now. The only existing one is
> changelog policies; in future, we could add settings such as "pass
> tests before checkin", "check style before checkin", "must include
> changelog entry", etc.

Sounds good.

> 
> Settings Infrastructure
> ================
> Many of these settings may need to be overridable for individual
> projects within a solution, because a solution's projects may have
> been imported from elsewhere with different coding style. For this
> reason, we need an infrastructure that can be used to get the setting
> for a project, and if the setting has not been overridden, will grab
> the setting from the parent solution.
> 
> * How important is this feature?

I don't think it is important.

> * How many of the settings really need to be overridable at project level?

I don't see why there should be a restriction on that.

> * Should settings be overridable at "solution folder" level too, hence
> allowing a cascade of settings?

We could do it (although it is not so important).

> * Should settings or group of settings be individually overridable? Or
> should it just allow a project to override *all* settings? Does this
> really need any granularity?

Allow overriding at file type level is probably enough.

> * Where should settings be stored? The solution file and the project
> files? I feel this is better than a .userprefs-like file, since it
> makes sure the settings stay with the project/solution.

It has to be stored in the project file, since the idea is to share all
those settings with all developers, and that would not be possible if
you store it in userprefs.

> * Should setting be duplicated in the project in case it's opened
> without the solution? Or should the project have a flag to say that it
> expects settings to be stored in a solution, so MD can warn when the
> solution isn't present?

Since this is an uncommon case, I would just use the default settings.

> * What settings do we default to when opening projects that don't
> contain settings Do we automatically add default settings to the
> solution files? Or fall back to a set of user preferences?

All style and policy settings should be available as user preferences.
Those would be the settings to use when creating a new solution.

> 
> GUI Infrastructure
> =============
> It's difficult to present all of these options in the GUI in a
> scalable way, particularly the per-mimetype editor settings
> * Should the settings be in the main "Project options" dialog or a
> separate "Styles and policies" dialog? The separate dialog has the
> advantage that the same dialog can be used to edit the user's named
> styles and default style. It would also help to not overload the
> setting treeview in the existing project options dialog.

I think they should go in the project options dialog. We can have a
"Coding Style" category and add a subcategory for each file type.

> * Should each panel have "use parent solution's style", "load/save
> named style" etc options? Or should these apply to all styles?

Load/save can be done at project level. Overriding at file type level.

> * VS has a setting panel that can be used to add "file types" and set
> the editing experience that's used for them. maybe we could do
> something similar with per-mimetype styles -- the top-level panel for
> editor setting would contain this list, and adding a file type would
> cause it and its options to appear in the tree. Files not handled this
> way would fall back to the "Other files" style (VS has an "All files"
> option which aggregates the common settings from all files, with
> tri-state checkboxes etc, but I feel this is overcomplex).

In general, editing experience settings are not styles, they are about
editor behavior. However it makes sense to allow binding a mime type to
a known file type for which behavior and style settings can be set.

> 
> Named Styles
> ==========
> It should be possible to save a project's style, and apply this style
> to other solutions/projects. However, I don't think it's viable or
> desirable to synchronise these in any way. Once a project is created,
> its settings should remain constant unless they are explicitly
> changed.

Agreed.

> 
> I also have a number of mockups on my whiteboard which aren't so easy
> to express in email :-)
> 

Cool, feel free to post.

Lluis.