Reconsider "smart characters" preferences

[LinqLover]

While investigating recent issues with the auto enclose functionality in Squeak 6.0Alpha Trunk¹, @j4yk identified some overlapping preferences of Autocompletion related to the term "smart characters". Without having analyzed their functionality and behavior in-depth, I just wanted to note this down here and propose to revise these preferences to address the following concerns:

• Do they add any value in present Squeak that is not available via the default preferences?
• Should they maybe be removed, deprecated, or at least disabled by default to avoid confusing behavior when a user changes the different settings and does not aim the desired goal?

HNY :-)

Footnotes

1. http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217304.html ↩

[LeonMatthes]

I believe eCompletion (which Autocompletion is a fork of) added smart characters (adding a closing brace when typing an opening one) before they were available in Squeak by default.

They shouldn't really conflict with the built-in ones as long as both aren't active. Not sure if there's a good point in removing them, as they should still be able to act as a backup to the built-in ones.

[LinqLover]

Alright, so this decision should be addressed in eCompletion instead.

[LinqLover]

Turns out that smartCharacters is still something that is only supported by Autocompletion/eCompletion. We might want to merge this into the Trunk at some day, but before that, deleting this feature from Autocompletion/eCompletion would not make sense. (Btw, eCompletion seems not to be maintained actively, last version on SqueakSource seems to be from 2010.)

[LeonMatthes]

The auto enclose brackets settings is the Squeak default implementation of this I think, together with Enclose selection with brackets.

That should be part of the default image.
These settings don't seem to conflict with eCompletion (speak: Autocompletion, as it's a fork of eCompltion) smart characters. I have both enabled and no issues.

[LinqLover]

I think there is at least one conflict indeed: In plain trunk, pressing " while selecting a inside "a" removes the surrounding quotes. With Autocompletion's smart characters, the expression is converted to ""a"" instead ...