Hi Tim, yes, it is known that Preferences has "evolved" over time, and
one of the areas I want to clean up, and I think Marcel and others
too.  I posted my Preferences requirements and goals for what I wanted
to accomplish in the refactor earlier this year.  It didn't happen
this release, but something possibly for the next.  Marcel has already
collapsed several preferences into the new Theming architecture,
probably some more can be next release as well, and some of the ones
you mentioned could too.

I think you have a pretty good list, but we will use a thoughtful and
logical approach and not a snarky one for determining the fate of each
and every Preference.  Preferences are supposed to resolve our
differences, not create them.

re: autoEnclose -- Marcel and I spared the squeak-dev list an
excruciatingly detailed discussion about autoEnclose, taking into
account multiple requirements, editing styles, and keyboard layouts.
A ton of thought and discussion went into it with the goal of
maximizing the UX and achieve as many use-case combinations as we
could.

Best,
  Chris

On Thu, Aug 11, 2016 at 1:24 PM, tim Rowledge <tim at rowledge.org> wrote:
> I actually sat and read through, and tried, all the preferences. It was not a lot of fun. Here are some notes resulting from that marathon of pain.
>
> Basic points
> ========
>
> Ridiculous mix of upper and lower cased and camel-cased preference names. Some with spaces, some not. Accompanying help text often needs spelling, grammar or factual fixes.
> The 'help' button window refers to a non-existent 'theme...' button. And has mis-spelllings.
> In general we have an insane number of preferences that seem to do nothing interesting . Probably time to get rid of a lot of them and simplify life.
>
> Specific items, with often snarky commentary.
> =============================
>
> block assignments - should not be allowed
>
> underscore assignments  - should not be allowed; see Cuis for a way to do it right.
>
> Examples - why are they in the tool? Several appear to be unused anyway
>
> subpixel rendering - not able to see any difference; is it actually in use?
>
> auto-enclose - doesn't match capability with autoEnclose. See TextEditor>>dispatchOnKeyboardEvent: Also, one has char as arg, other has event. Yuck!
>
> highlight hovered row in lists - seems wrong to have the preference in PluggableListMorph but used in just two classes that are not related.
>
> 'Menu request updates list/tree selection' help text is gibberish
>
> 'Use new style balloon morphs' why bother offering the choice instead of dropping the old ones?
>
> Browse with drag'n'drop - does this need to be a pref?
>
> syntaxHighlightingAsYouType - none of th three seem to have any users
>
> Use the new color-picker - is this of any use?
>
> Corner Grip * - ditto
>
> Flaps - are they still in there?
>
> Thorough senders - dump it
>
> automaticPlatformSettings - what?
>
> modalColorPickers - seems pointless
>
> readOnlyMode - no usages?
>
> alternateHandlesLook - why?
>
> biggerHandles - why? has some interaction with tinyDisplay/bigDisplay
>
> haloTransitions - I don't think so
>
> magic/maintain/mouseOver-Halos - what?
>
> generally halo stuff seems to have an insane number of preferences that are not used.
>
> keyboard duplicate/swap stuff - way too complex and poorly explained
>
> simpleMenus - doesn't really have much effect
>
> timeStampsInMenuTitles - can't see what it is for
>
> menuBorderWidth - doesn't actually seem to relate to menus at all
>
> menuTitleBorderWidth - ditto
>
> - in fact none of the menuXX items seem to be used for menus
>
> Show wrap border in code panes & Wrap border limit - why in 'performance' and what are they supposed to be for?
>
> alternativeButtonsInScrollbars - any use?
>
> too many scrollbar options. must be a better way to make such choices, or actually decide on something and stick to it.
>
> inlineServicesInMenu - comment makes no sense.
> - do we still need the preferences if we always have services?
>
> 'Offer native fonts' only works with an apparently unused set of StrikeFont code (#fromUser: etc) and the code even breaks on linux since there are no truetype fonts (on my machine at least) Thuse the list of fonts is nil and the TTFileDescription class>>frontFromUser:allowKeyboard: code breaks.
>
> 'Selections may shrink' - is there any case where that would not be true?
>
> Font choosing
> =========
> not part of preferencebrowser, which seems odd.
> appearance->systemfonts menu seems to not be matched to the themes fonts stuff? Preferences class>>restoreDefaultFont probably needs to use the theme data.
> #setDemoFonts likely simialr, and a 'return to normal' is needed too.
> 'Offer native fonts' only works with an apparently unused set of StrikeFont code (#fromUser: etc) and the code even breaks on linux since there are no truetype fonts (on my machine at least) Thuse the list of fonts is nil and the TTFileDescription class>>frontFromUser:allowKeyboard: code breaks.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Spell checkers at maximum!  Fire!
>
>
>