Specify different code formatter settings per package

[daniels220]

I personally prefer periodsAtEndOfMethod: true for my own code, but I see that this is not the convention in Dolphin core. It would be nice if I could specify different settings depending on what code I'm editing—doing this at the package level seems the most obvious place.

I imagine this is nontrivial—with the settings stored in class vars, seems like a fair bit of refactoring would be needed. Unfortunately I don't think Pharo has this capability either (to crib from). If you like the concept, and have an idea of the approach you'd like to take, I might be able to work on it.

[blairmcg]

If it's something you find important, then why not. I agree it sounds like a per-package setting is probably best.

I think it makes sense to store a generic settings Dictionary on Package that could contain such things and any other metadata that might be needed, and file it out as part of the .pax. Storing it in STON pretty-printed format would make a lot of sense. To avoid load order the settings could be saved in serialised STON string form into the existing properties Dictionary at load time, and then de-serialised out into an instance variable on demand when required. The reference to STON could either be dynamic, or put the Package settings accessor method in the Development System package. We can neaten it up later if necessary.

[fxgallego]

Does this mean if you want a custom setting in all your packages then you would change it in each one? How would you inherit the settings at "folder" level, for example?
I think that Dolphin development (this project) should be done using a Dolphin image, not your development image so I don't see the problem. But maybe there is a good explanation 😄
It would be useful to save the user preferences locally, some IDE's do that in a "dot folder/file" inside the project's root folder so you can commit the preferences with your source code, if you want. I usually ignore the preferences.

[blairmcg]

Good points from @fxgallego. Storing at the package level would be too awkward to manage, at least for this.

[daniels220]

Fair point about the awkwardness of handling settings across a large number of packages—I was aiming for a minimum-viable solution and planning on just using a script to automate applying the settings to a large number of packages. Inheritance would be great, but since there's no persistent object representing a folder that would be harder. It might make sense to create one—certainly other languages have systems of inheriting settings files that apply to everything in the folder they're in—but that's a lot more work.

As for keeping Dolphin development in a Dolphin image...I think that's throwing away one of the huge advantages of Smalltalk, which is precisely that the development tools are always open to modification and you don't have to open a separate project/tool/image to work on them—and, having made whatever changes, they become immediately available to you to work on whatever actual business problem. I've never sat down and said "okay, I'm going to work on X development feature now"—rather, I'm working on another problem, need a tool to help me solve it, write the tool, solve the problem. So keeping that workflow fluid is important to me.