Smalltalk › Squeak › Squeak - Dev

Preference settings for 5.3 release

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

31 messages Options

Chris Muller-4

Re: autoEnclose preference (was: Preference settings for 5.3 release)

> On 2019-12-23, at 7:41 PM, Chris Muller <[hidden email]> wrote:
>
> It is only the autoEnclose preference that causes problems in
> workspaces,
>
> What "problems" are those? Just as you see in the subject-line of this email, for every open-parenthesis, there's a closing, as well as for every open bracket, a closing. That's the structure of these characters in every normal context. "Problems" arise when they get out of balance, which is why other editors have this feature too. IIRC, eclipse was doing it in 2005.
>
> IMO, it's a good thing for developers and users alike.

Problem is that when you type a ( you get () - which is fine if you're about to type (fooble +2) but really irritating if you already have fooble + 2) and want to add the ( in front. Which seems to be something that happens frequently enough to me that the irritation level is very considerable.

Now, the 'enclose selection with brackets' option is much less annoying *to me* - apart from anything else I got used to it decades ago. It's useful when editing, as opposed to 'streaming', code. Of course, it gets annoying if you wanted to replace the selection with (.
Happily cmd-shift-( actually does a "wrap selection with ( and leave selection as-is" so it is possible to do both ways almost without any problem. With both the auto-enclose and enclose-selection disabled you can
type (foo
type foo, go back and add ( in front
type foo, select it, wrap with cmd-( to get (foo)
type cmd-(foo and get (foo)
So *at worst* you'd have to hit cmd-( to get the () you want, and of course the preference is still there for you and any other people that are able to stream out code without having to stop and ponder after every (small prime number of) characters.

I think it boils down to whether you want to edit "expressions" or edit "text". The preferences are optimized to let you choose one or the other and, if you stick to it, serve you well. As someone who prefers the expression-editing style, I never run into "fooble + 2)" because I never type a closing paren-bracket, ever, I just don't, because it means you're instantly out of balance which, I simply can't do in my editing. Unbalanced paren-brackets forces me into tedious "text editing" mode where all analysis stops so I can hunt down the missing whatever just to get back to syntactical validity. If I need to enclose an expression, I always only select it and use the hot key. In that way of working, autoEnclose is always fine.

- Chris

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Computers are only human.

K K Subbu

Re: autoEnclose preference

In reply to this post by Chris Muller-3

On 24/12/19 9:11 AM, Chris Muller wrote:
>
> What "problems" are those? Just as you see in the subject-line of this
> email, for every open-parenthesis, there's a closing, as well as for
> every open bracket, a closing. That's the structure of these characters
> in every normal context. "Problems" arise when they get out of balance,
> which is why other editors have this feature too. IIRC, eclipse was
> doing it in 2005.
One of the problems I face frequently is because autoEnclose inserts a )
when I type ( but does not remove it when I backspace over (. For
instance, I type (teh, realize my typo and backspace over it including
the ( but I am left with a dangling ). I prefer typing cmd-( when I need
matching ().

Regards .. Subbu

Karl Ramberg

Re: autoEnclose preference

autoEnclose is one of the first preference in turn of in a new image. Please leave it off in new release.

Best,

Karl

On Tue, 24 Dec 2019 at 15:02, K K Subbu <[hidden email]> wrote:

On 24/12/19 9:11 AM, Chris Muller wrote:
>
> What "problems" are those? Just as you see in the subject-line of this
> email, for every open-parenthesis, there's a closing, as well as for
> every open bracket, a closing. That's the structure of these characters
> in every normal context. "Problems" arise when they get out of balance,
> which is why other editors have this feature too. IIRC, eclipse was
> doing it in 2005.
One of the problems I face frequently is because autoEnclose inserts a )
when I type ( but does not remove it when I backspace over (. For
instance, I type (teh, realize my typo and backspace over it including
the ( but I am left with a dangling ). I prefer typing cmd-( when I need
matching ().

Regards .. Subbu

Eliot Miranda-2

Re: autoEnclose preference

Hi All,

some people really like auto enclose and dine people hate it. Similarly some people like update menu selection on mouse click and others hate it. We are unlikely to find a compromise, or be able to vote and find a substantial majority one way or the other. It is also true that not having the preference the way one wants us extremely irritating for each side. The experience is of a system that is fighting you at every turn and is hugely frustrating.

So this group of preferences is the kind of thing that should be offered to the user as a configuration choice at setup. Marcel abd the Potsdam folks did a brilliant job writing the initial preference configuration and it’s a pleasure to use. I suggest, and ask for effort in implementing, that in this release one of the configuration options is a group preference for editing & selection which offers either the “old crusty“ choices of no automatic anything in editing and mouse selection (please Santa, I want an “I am an old crusty tee shirt for Xmas), and the young skywalker use-the-force alternatives. We still need to make an exhaustive list beyond auto enclose and update menu selection, but please can we offer this as a choice to users and emphatically not choose a default one way or the other? We should have sufficient respect for each other’s muscle memory to realise this is one example where a default simply isn’t god enough.

_,,,^..^,,,_ (phone)

On Dec 24, 2019, at 6:31 AM, karl ramberg <[hidden email]> wrote:

autoEnclose is one of the first preference in turn of in a new image. Please leave it off in new release.

Best,
Karl

On Tue, 24 Dec 2019 at 15:02, K K Subbu <[hidden email]> wrote:
On 24/12/19 9:11 AM, Chris Muller wrote:
>
> What "problems" are those? Just as you see in the subject-line of this
> email, for every open-parenthesis, there's a closing, as well as for
> every open bracket, a closing. That's the structure of these characters
> in every normal context. "Problems" arise when they get out of balance,
> which is why other editors have this feature too. IIRC, eclipse was
> doing it in 2005.
One of the problems I face frequently is because autoEnclose inserts a )
when I type ( but does not remove it when I backspace over (. For
instance, I type (teh, realize my typo and backspace over it including
the ( but I am left with a dangling ). I prefer typing cmd-( when I need
matching ().

Regards .. Subbu

timrowledge

Re: autoEnclose preference

Chris, I happily accept that for each ( there should be a ) *but* I think you skipped over what happens when you want to change where the ( is. Maybe you're just in the habit of streaming out code so efficiently that you never need to change that sort of thing but I make mistakes (occasionally, let's not get excited here) and want to delete a ( and type it somewhere else in the code. Habits are like Hobbits; they live deep in the ground and have hairy feet and are hard to get rid of.

> On 2019-12-24, at 7:12 AM, Eliot Miranda <[hidden email]> wrote:
>
> Hi All,
>
> some people really like auto enclose and dine people hate it. Similarly some people like update menu selection on mouse click and others hate it. We are unlikely to find a compromise, or be able to vote and find a substantial majority one way or the other. It is also true that not having the preference the way one wants us extremely irritating for each side. The experience is of a system that is fighting you at every turn and is hugely frustrating.

Yup.

>
> So this group of preferences is the kind of thing that should be offered to the user as a configuration choice at setup. Marcel abd the Potsdam folks did a brilliant job writing the initial preference configuration and it’s a pleasure to use. I suggest, and ask for effort in implementing, that in this release one of the configuration options is a group preference for editing & selection which offers either the “old crusty“ choices of no automatic anything in editing and mouse selection

For the sake of brevity in the setup Whizzard I'd suggest having just one or maybe two choices along with an explanation that more detailed preferences can be found in the Preferences tool. And that your preferences can be saved and reloaded. And a reminder that when you set them in an image and save the image they are remembered.

We could also do with an improved UI for saving and loading those preferences since at the moment they only go to/ come from a file in the image directory which is a real pain for people working in multiple images across directories and machines.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
He who hesitates is probably right.

timrowledge

Re: Preference settings for 5.3 release

In reply to this post by timrowledge

There's an extra complication I notice after trying out my submission for saving/loading preferences - if you click on the 'default' button in the PreferencesBrowser you get a strange set of options derived from Preferences class>>#chooseInitialSettings (including a very different set of halo icons)
This uses the default values set in each preference see Preferences class>>#alternateHandlesLook for one example. In at least a few cases these don't agree with the values set in ReleaseBuilder class>>#setPreferences.

So we have a default setup created when building the release, a default set made from the code versions and some set via pragmas. And some via themes - which can get set via the dock Extras->Themes & Colors menu, or differently via the world->appearance->choose set of preferences and probably other ways.

I think maybe we should try to simplify this for the next release...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"How many Motie Mediators does it take to chage a lightbulb?”
"Are you insane? Only Crazy Eddie would want to change *anything*!"

Chris Muller-3

Re: autoEnclose preference

In reply to this post by K K Subbu

On Tue, Dec 24, 2019 at 8:02 AM K K Subbu <[hidden email]> wrote:

On 24/12/19 9:11 AM, Chris Muller wrote:
>
> What "problems" are those? Just as you see in the subject-line of this
> email, for every open-parenthesis, there's a closing, as well as for
> every open bracket, a closing. That's the structure of these characters
> in every normal context. "Problems" arise when they get out of balance,
> which is why other editors have this feature too. IIRC, eclipse was
> doing it in 2005.
One of the problems I face frequently is because autoEnclose inserts a )
when I type ( but does not remove it when I backspace over (. For
instance, I type (teh, realize my typo and backspace over it including
the ( but I am left with a dangling ). I prefer typing cmd-( when I need
matching ().

I must've forgotten that eclipse did that, too, because now that you mention that, I think it did...

It was not too hard to fix. Please try Morphic-cmm.1613 in the inbox.

Best,

Chris

Regards .. Subbu

Chris Muller-3

Re: autoEnclose preference

In reply to this post by timrowledge

On Tue, Dec 24, 2019 at 1:16 PM tim Rowledge <[hidden email]> wrote:

Chris, I happily accept that for each ( there should be a ) *but* I think you skipped over what happens when you want to change where the ( is.

Maybe you're just in the habit of streaming out code so efficiently that you never need to change that sort of thing but I make mistakes (occasionally, let's not get excited here) and want to delete a ( and type it somewhere else in the code.

Okay, nothing wrong with that, but I don't do that in my style because it instantly unbalances my parentheses and forces me into text editing mode. Since I only ever want to do expression editing, I:

1) select the expression (alt+[space], swipe, or double-click),

2) remove the existing ( by pressing Control+9,

3) expand / reselect the new enclosure

4) Control+9, to re-surround the selection with ().

Best,

Chris

Karl Ramberg

Re: Preference settings for 5.3 release

In reply to this post by timrowledge

It could nice if we could use Monticello for saving and loading personal preferences also :-)

Best,

Karl

On Wed, 25 Dec 2019 at 00:29, tim Rowledge <[hidden email]> wrote:

There's an extra complication I notice after trying out my submission for saving/loading preferences - if you click on the 'default' button in the PreferencesBrowser you get a strange set of options derived from Preferences class>>#chooseInitialSettings (including a very different set of halo icons)
This uses the default values set in each preference see Preferences class>>#alternateHandlesLook for one example. In at least a few cases these don't agree with the values set in ReleaseBuilder class>>#setPreferences.

So we have a default setup created when building the release, a default set made from the code versions and some set via pragmas. And some via themes - which can get set via the dock Extras->Themes & Colors menu, or differently via the world->appearance->choose set of preferences and probably other ways.

I think maybe we should try to simplify this for the next release...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"How many Motie Mediators does it take to chage a lightbulb?”
"Are you insane? Only Crazy Eddie would want to change *anything*!"

Chris Muller-3

Re: Preference settings for 5.3 release

Well, you can, of course, just codify it. Here's my MyInstaller>>#configure, which I call from its class-side #initialize. Feel free to copy and tweak as you please.

By using a hierarchy of Installers, each automatically configures the code AND Preferences appropriately for that context.

Installer

MaInstaller "generic framework stuff, very few preference settings"

MaCommercialInst "Proprietary, some options set"

CmmInstaller "Personal. Many preferences, my fully custom IDE"

It's a nice setup, indeed. :)

- Chris

On Wed, Dec 25, 2019 at 4:56 AM karl ramberg <[hidden email]> wrote:

It could nice if we could use Monticello for saving and loading personal preferences also :-)

Best,
Karl

On Wed, 25 Dec 2019 at 00:29, tim Rowledge <[hidden email]> wrote:
There's an extra complication I notice after trying out my submission for saving/loading preferences - if you click on the 'default' button in the PreferencesBrowser you get a strange set of options derived from Preferences class>>#chooseInitialSettings (including a very different set of halo icons)
This uses the default values set in each preference see Preferences class>>#alternateHandlesLook for one example. In at least a few cases these don't agree with the values set in ReleaseBuilder class>>#setPreferences.

So we have a default setup created when building the release, a default set made from the code versions and some set via pragmas. And some via themes - which can get set via the dock Extras->Themes & Colors menu, or differently via the world->appearance->choose set of preferences and probably other ways.

I think maybe we should try to simplify this for the next release...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"How many Motie Mediators does it take to chage a lightbulb?”
"Are you insane? Only Crazy Eddie would want to change *anything*!"

MyInstaller-configure.st (4K) Download Attachment

Christoph Thiede

Re: Preference settings for 5.3 release

In reply to this post by Eliot Miranda-2

Hi Eliot,

I guess we are talking about different things :-)

I was talking about the compiler preferences - how to handle an underscore assignment, for example - and proposed to replace these preferences with special Deprecation warnings. You are talking about the bytecode set, what is the relation? :) If I load old code via Monticello, for example, I will load the source only which will be compiled on my VM, won't it? So it is always compiled with the latest bytecode. This might be different when loading a project file that includes CompiledMethods, though.

However, thanks for your crash course about bytecode sets! They're an interesting concept, and I will be happy to take a closer look at them at some time.

Best,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Eliot Miranda <[hidden email]>
Gesendet: Dienstag, 24. Dezember 2019 02:50:54
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Preference settings for 5.3 release

Hi Christophe,

On Mon, Dec 23, 2019 at 11:25 AM Thiede, Christoph <[hidden email]> wrote:

Hi all,

just my two cents :)

> Compiler

> I claim we are long past the point where enabling block argument assignments or underscore assignment should be a default. Fix your damn code!

> Are we sticking with the EncoderForV3PlusClosures encoder?

IIRC someone explained recently that disabling this preference would make it impossible to load old code? I would not like to make this unnecessary restriction.

Instead, I would suggest - provided that the following is implementable - to raise a special kind of warning if deprecated syntax is used. Users can then decide to suppress or not suppress these warnings. During loading old code, we can catch and ignore them. (And yes, we sometimes should work at improving/exchanging the UI of warnings).

I think that they;'re wrong :-) Let me explain why.

The Cog VM supports up to two bytecode sets, selected by the sign bit of the method header. If the sign bit is not set the "primary" bytecode set is selected, and if set the "secondary" bytecode set is selected. Both the primary and secondary bytecode sets are "installed" by setting a couple of class variables in CompiledCode, one for the PrimaryBytecodeSetEncoderClass and one for the SecondaryBytecodeSetEncoderClass. Which bytyecode set is the preferred one is selected by yet another class variable, PreferredBytecodeSetEncoderClass.

By default these variables have these values (they have these values ion trunk currently)

PreferredBytecodeSetEncoderClass nil

PrimaryBytecodeSetEncoderClass EncoderForV3PlusClosures

SecondaryBytecodeSetEncoderClass EncoderForV3PlusClosures

What setting the preferred bytecode selector set to SistaV1 does is to set these variables to these values:

PreferredBytecodeSetEncoderClass EncoderForSistaV1

PrimaryBytecodeSetEncoderClass EncoderForV3PlusClosures

SecondaryBytecodeSetEncoderClass EncoderForSistaV1

So what it *does not do* is change the meaning of the bit in the method header. A non-negative method header still means the method uses the old bytecode set. So old code continues to load. It is entirely unaffected. What it does mean is that any methods that are compiled (that are not quick methods (*)) are compiled using the new bytecode set and will have negative method headers. So if you export them, e.g. via an ImageSegment, they will use the SistaV1 bytecode set in the receiving image whether it has the preference set or not. Further, the VM will happily run the new bytecode set because for a whole now the VM has had the two bytecode sets compiled in in this way. What will happen ion the image that doesn't have the SecondaryBytecodeSetEncoderClass set to EncoderForSistaV1 is that the debugger, etc, will get confused because they will interpret the new byetcodes using the old encodings.

(*) quick methods don't have bytecodes, just a primitive number. So these methods keep being expressed in the old bytecode set because I've been too lazy to rewrite quick method generation to respect the PreferredBytecodeSetEncoderClass, because for the moment it makes no difference.

Does this make sense or am I being too detailed and confusing?

Executive summary, the design was careful to *not* invalidate the old bytecode set, to make using the new bytecode set an option that does not break backwards compatibility.

In future if we want to jettison the old bytecode set and design a third set, that's when we introduce backwards com potability issues, and we introduce the need to express quick methods using the SistaV1 bytecode set. But for the moment we're safe.

> 'ignore style if only bold'?

Didn't we talk about this recently? It is related to storing all TextAttributes into a compiled method. See here. According to Tobias, it sounds like something that has developed historically, so I proposed to deprecate it.

But yes, loosely related to browsing, I guess.

> 'Use the new color picker' - is the new color pick not our pick for picking colors? If it still isn't the sensible choice more than 10 years later, maybe we should dump it completely.

There still might be one feature which the classical color pick does have, but the new one is missing: Really "picking" a color from any pixel of the screen. Maybe we should add this feature. Or am I missing something?

Merry Christmas,

Christoph

Von: Squeak-dev <[hidden email]> im Auftrag von Nicola Mingotti <[hidden email]>
Gesendet: Montag, 23. Dezember 2019 10:56:36
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Preference settings for 5.3 release

Hi Elliot,

Forgive me for encouraging you to proselytize on e.g. Quora. Do you have a blog? I'd love to read your impressions and criticisms.

I am flattered, really:)

At the moment I am putting some effort in the Video medium. I think it is extremely important to get people to try Squeak, they must see it in action. It is very very difficult to explain in textual form what it can do and why it is different. It is difficult for the reader to get the idea. (it was very difficult for me, and I am very much trained in learning by the book)

When I produce something new I publish it in Linkedin.

https://www.linkedin.com/in/nicola-mingotti-2612a940

I usually copy the link also in Reddit "smalltalk" channel.

I try to keep updated also the Swiki.

If you have other suggestion of where to publish/link things or share points of view let me know. I will try to be there as well.

bye

Nicola

Opinion of total beginners (so, partially also mine) should be weighted less, because they do not know what is coming. Like opinion of students, let them choose democratically and Calculus would be deleted from any curriculum. :P

bye
nicola

> On Dec 23, 2019, at 1:59 AM, David T. Lewis <[hidden email]> wrote:
>
> I am sure that both of those preferences will remain.
>
> I also agree with your view of colorful windows, and I always turn
> this preference on in my image(s). But I recall that this was discussed
> for the 5.2 release, and we had feedback from new users who did
> not like the window coloring. For that reason, we should probably
> keep the preference turned off in the release image.
>
> But I am not a "new user" any more, so if there are any fresh opinions
> on the subject of colorful windows, please speak up :-)
>
> Dave
>
>
> On Mon, Dec 23, 2019 at 12:29:03AM +0100, Nicola Mingotti wrote:
>>
>> I am totally 'pro' on reducing the number of preferences.
>>
>> But I ask you this:
>>
>> [1] Do not remove the preference to keep different windows in different colors. That is one of the most useful decision you can make IMHO. Why would you color the Browser, Workspace and Debugger in the same way?
>>
>> I understand that all grey may seems more a "professional/industrial" interface, but I guess we can leave that aim to Pharo and go on on our way.
>>
>> [2] "do not remove the possibility of having larger fonts".
>>
>> With high High-DPI Squeak would be unusable out of the Box.
>>
>> bye
>> Nicola
>>
>>
>>
>>
>>> On Dec 20, 2019, at 11:18 PM, David T. Lewis <[hidden email]> wrote:
>>>
>>> A preference elimination initiative would be *very* welcome, but
>>> it is something that we should start working on immediately after
>>> the 5.3 release.
>>>
>>> Preferences are like other bad habits: easy to get into, and
>>> hard to eliminate. So let's all make a New Year's resolution to
>>> lose weight, exercise more, eat healthier food, and get rid of
>>> unnecessary preferences in Squeak.
>>>
>>> For the current release, I think that we should limit discussion
>>> to specific default preference settings that we might want to
>>> change for the upcoming release.
>>>
>>> Dave
>>>
>>> On Fri, Dec 20, 2019 at 12:57:15PM -0800, tim Rowledge wrote:
>>>> We have a *lot* of preferences - in my view way too many - and there should be at least some discussion about the default values we provide for 5.3
>>>> tl;dr - Too many preferences, too badly organised. reduce, make decisions, simplify.
>>>>
>>>> I can't imagine I'll hit all of them here but let's try to get something done -
>>>>
>>>> Arithmetic
>>>> Should we have these as preferences? How many people understand enough about Burnikel-Ziegler recursion splits to make it sensible to easily change?
>>>>
>>>> Compiler
>>>> I claim we are long past the point where enabling block argument assignments or underscore assignment should be a default. Fix your damn code!
>>>> Are we sticking with the EncoderForV3PlusClosures encoder?
>>>>
>>>> Examples
>>>> These are for the test suite and if possible should be hidden
>>>>
>>>> Files
>>>> The one entry here relates to the encoding of stdio streams so maybe this category should be renamed?
>>>>
>>>> Graphics
>>>> Both entries relate to sub-pixel font rendering, so again, rename?
>>>>
>>>> Morphic
>>>> So. Many. Preferences.
>>>> Surely at least the text edit related ones ought to be removed and kept to the 'editing' section?
>>>>
>>>> OLPC
>>>> Really?
>>>>
>>>> TextDiff
>>>> Could be better placed; in Tools?
>>>>
>>>> Tools
>>>> 'Use unified message labels' What does this do? Is it worth allowing a choice for this sort of thing?
>>>>
>>>> browsing
>>>> Aargh! More options than 31 flavour ice-cream stores! How many are actually of value?
>>>> 'ignore style if only bold'?
>>>> 'menu button in tool pane' - no actual senders, for example
>>>>
>>>> colors
>>>> 'Use the new color picker' - is the new color pick not our pick for picking colors? If it still isn't the sensible choice more than 10 years later, maybe we should dump it completely.
>>>>
>>>> fileout
>>>> are there ever good reasons to not have 24 hr timestamps? For not checking for slips?
>>>>
>>>> general
>>>> Wow, still more flavours of ice-cream.
>>>> 'Read only mode' - no senders. It's so old there is no timestamp.
>>>> 'Use locale' is there any reason to ever not use it?
>>>>
>>>> .... and my brain melted at this point.
>>>>
>>>>
>>>>
>>>> tim
>>>> --
>>>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>>>> Useful random insult:- Couldn't pour water out of a boot with instructions on the heel.
>>>>
>>>>
>>>>
>>>
>>
>>
>

--

_,,,^..^,,,_

best, Eliot

_,,,^..^,,,_

best, Eliot

Carpe Squeak!