[Monodevelop-devel] Per-project styles & policies

[Michael Hutchinson]

On Tue, Sep 30, 2008 at 8:47 AM, Levi Bard
<taktaktaktaktaktaktaktaktaktak at gmail.com> wrote:
>> * Should we allow users to add custom mimetypes for their own file
>> formats, or just support the "major" text/code mimetypes registered in
>> MD?
>> * Should we list only the mimetypes used in the project?
>
> If the answer to the latter is yes, then the answer to the former
> should also be yes.
>
>> * 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?
>
> Probably it would be a good idea to have a store of different styles
> created by the user.

See "named styles" :)

>> 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?
>
> IMO it's as important to have per-project settings as it is to have
> per-solution settings.
> As an example, I have a solution with some C# projects and a C
> project. For external reasons, the coding standard for the C project
> is different than for the C# project. I suspect that, as MD becomes
> more mature and well-known as a solid, general-purpose IDE, there will
> be more and more mixed-language solutions that will lend themselves to
> different styles per project.

Mixed-language solutions does NOT mean you need to override things at
the project level. I think the only real case for project-level
overriding is when different project use the same language but
different styles.

>> * How many of the settings really need to be overridable at project level?
>
> All of the ones that are overridable at the solution level.

Including things like commit policies?

My question was really meant as, should we make everything
overridable, or evaluate it on a per-case basis? Allowing the user to
override things adds UI, which just clutters things when it's not
necessary.

>> * 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.
>
> Is there some way to do this such that the settings will be ignored
> and won't be stripped if the project/solution is opened in another
> IDE?

We can write settings into MSBuild files so that VS won't touch them.

>> * 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?
>
> I would think it makes sense to store the settings at the tree level
> at which they're set. (Solutionwide => solution settings,
> Project-specific=> project settings)

In terms of storage, that makes perfect sense. The potential problem
is when a project is opened independently of the solution.

>> 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.
>
> --
> http://homes.eff.org/~barlow/EconomyOfIdeas.html
> http://www.dreamsongs.com/MobSoftware.html
> http://www.gnu.org/philosophy/shouldbefree.html
>

-- 
Michael Hutchinson
http://mjhutchinson.com