Hi Christoph,

On Sun, Dec 26, 2021 at 6:52 AM <christoph.thiede at student.hpi.uni-potsdam.de>
wrote:

> Hi all,
>
>
>
> *Ad discussion theme #1: *
> > If you really want to mess around with this kind of thing I'd suggest
> making a proper config tool that let's you configure every available key
> and meta combination, with saveable mappings attached to the prefs so you
> can have whatever you personally want.
>
> Sure, why not? But definitely not before the release. :D
>
> > That's why I would vote for showing off all the bells and whistles by
> default, and make it easy to disable them if they are annoying.
>
> +1
>
> > "Did you find that useful? If not you can disable it in the preferences
> _here_ ..."
>
> +1, but only if it can be turned off, and only after the release, of
> course. :D
>
>
>
> *Ad discussion theme #2: *
> > Just a remark: out of the box, Cmd-[ is not accessible on a German
> Windows-type quertz keyboard because we have to use Alt Gr (which is
> equivalent to Ctrl+Alt) + 8 to type [ in the first place, so all modifiers
> that could possibly map to Cmd are already held down. Same issue with curly
> braces.
>
> Just to note what I have already written to Jakob in private: Even when
> switching my keyboard layout from Qwertz to Qwerty, I was not able to make
> use of Ctrl-[ or Alt+[ (Win32, VM 202112201228). Is this feature only
> available on Linux/macOS?
>
>
>
> *Ad discussion theme #3: *
> > General purpose, programmable, mumble, see above. It seems as if you are
> making the mistake of assuming there can only be one editor setup.
> Currently in Squeak we do rather do that, with the editors for pretty much
> all text-things being the same with the same menu even when inappropriate.
> We should do better.
>
> +1. We already have #pluggableTextSpec vs #pluggableCodePaneSpec but
> something like a #contentType flag would not harm, too. :-)
>
> > > I did *not* request to remove this shortcut because I understand that
> some long-standing Squeakers might have gotten used to it. My argument was
> only not to cement this kind of "leaky abstractions". IMHO the editor
> should be a tool that is suitable for all applications or domains in the
> same way, without putting advantages or disadvantages to certain domains.
> >
> > But the editor is explicitly divided into a domain-independent
> TextEditor and a domain-specific SmalltalkEditor anyway. So your objection
> is not relevant. We?re discussing (I hope) the accelerator keys for the
> SmalltalkEditor.
>
> IMO this should rather be part of a separate subclass of SmalltalkEditor:
>
> Editor: Minimal tool for editing strings (e.g., backspace).
> TextEditor: Tool for editing formatted strings (e.g., adding/removing
> attributes).
> SmalltalkEditor: Tool for editing Smalltalk code (e.g., <opt>1 for adding
> method parameters).
> ControlFlowStyleSmalltalkEditor: Tool for editing Smalltalk code in the
> style of low-level control-flow operations such as #whileTrue,
> #ifTrue:/#ifFalse:, etc.
>
> > > A developer working in another domain (that abstracts from
> booleans/for instance, a query DSL) will be less likely interested in
> special shortcuts for ifTrue:/ifFalse: but more likely interested in
> shortcuts for message sends such as #collect:, #select:, etc. I only wanted
> to present this perspective before we start occupying even more shortcuts
> for randomly chosen selectors that might be of increased importance for a
> subset of users of the Smalltalk workspace.
> >
> > ifTrue:/ifFalse: are hardly randomly selected selectors, now are they?
>
> They don't play a special role in the Smalltalk syntax, do they? Booleans
> are just objects like Collections or Morphs. #ifTrue: is just a selector
> like #select: or #openInWorld. They are only handled differently by the
> VM/interpreter for the sake of optimization (value types, inlined special
> selectors, ...). But conceptually, they are nothing special in our
> beautifully minimal Smalltalk grammar. They do not need to be mentioned on
> the Smalltalk Postcard.
>
> Statistically, you are right of course that #ifTrue: might be one of the
> most popular selectors in most Smalltalk programs. But that is not an
> intrinsic property of Smalltalk [...]


but it is.  In fact, it is a general property of programming languages.
Choice is intrinsic in general purpose programming (less so in stream
oriented programming), so much so that it is available in many
different forms.  Smalltalk provides polymorphic dispatch and closures,
from which we derive ifTrue:ifFalse: et al.  In functional languages one
sees pattern matching.  In machine languages one sees conditional jumps and
conditional skips.  In fact it is definitional that interesting programs
involve choice.  Even the Mandelbrot set depends on choice: the typical
implementation is to ask how many iterations of [image: {\displaystyle
f_{c}(z)=z^{2}+c}] does it take for z to converge or diverge to infinity.

So you can rail against ifTrue:/ifFalse: but you are pissing in the rain.

Now let's have a look at the numbers.  One might think one could could
keywords using:

    | keywordCounts |
    keywordCounts *:=* Bag new.
    CurrentReadOnlySourceFiles cacheDuring:
        [self systemNavigation allSelect:
            [:cm|
            cm selectorsDo:
                [:s|
                s isKeyword
                    ifTrue: [keywordCounts addAll: s keywords]
                    ifFalse: [keywordCounts add: s]].
            false]].
    keywordCounts sortedCounts

but of course this doesn't count inlined messages.  So we have to
decompile; amd let's generate a report in percentage terms:

    | keywordCounts keywordCount |
    keywordCounts *:=* Bag new.
    CurrentReadOnlySourceFiles cacheDuring:
        [self systemNavigation allSelect:
            [:cm|
            cm methodNode nodesDo:
                [:n|
                n isMessageNode ifTrue:
                    [n selector key isKeyword
                        ifTrue: [keywordCounts addAll: n selector key
keywords]
                        ifFalse: [keywordCounts add: n selector key]]].
            false]].
    keywordCount *:=* keywordCounts size.
    String streamContents:
        [:s|
        (keywordCounts sortedCounts first: 100) do:
            [:assoc|
            s nextPutAll: assoc value; space; print: assoc key * 100.0 /
keywordCount maxDecimalPlaces: 2; cr]]].

#(ifTrue: 5.31
ifFalse: 3.13
= 2.65
at: 2.5
+ 2.36
assert: 1.98
== 1.82
new: 1.57
to: 1.41
, 1.41
- 1.35
do: 1.32...

So ifTrue: and ifFalse: are more popular than the next three combined,
almost the next four.  ifTrue: is twice as likely as the third (=).  And
lest you think this is my style, the percentages in a VMMaker image are
slightly less: ifTrue: 5.24%, ifFalse: 3.05%.

[...] and personally I dislike the idea of coupling statistic insights
> about API usage to globally predefined shortcuts in the default Trunk
> image. It is possible to write Smalltalk programs that use alternative APIs
> (the Collection API would just be one example) that never make use of the
> Boolean protocol.
>

Personal preference is no argument for changing the behaviour of a
community-developed programming system, is it?


>
> Best,
> Christoph
>
> ---
> *Sent from **Squeak Inbox Talk
> <https://github.com/hpi-swa-lab/squeak-inbox-talk>*
>
> On 2021-12-25T16:03:32+01:00, marcel.taeumel at hpi.de wrote:
>
> > Hi all --
> >
> > Done. See Morphic-mt.1829. cmd+[ etc. is back if you enable the "legacy
> shortcuts" preference.
> >
> > Best,
> > Marcel
> > Am 25.12.2021 12:47:15 schrieb Marcel Taeumel <marcel.taeumel at hpi.de
> >:
> > Hi all --
> >
> > I am currently collecting the US-specific TextEditor shortcuts that got
> lost since Squeak 5.3 to make them available again as a preference-driven
> event filter on instances of TextEditor. Shouldn't be that hard. I will
> call the preference "Legacy keyboard shortcuts (US only)" or something like
> that.
> >
> > You can help me do that by answering here:
> >
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217783.html
> [
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217783.html
> ]
> >
> >
> > Thanks. :-)
> >
> > Best,
> > Marcel
> > Am 23.12.2021 21:09:53 schrieb tim Rowledge <tim at rowledge.org>:
> >
> >
> > > On 2021-12-23, at 4:39 AM, Jakob Reschke wrote:
> > >
> > > I believe that because Squeak does not have a
> > > reputation of being a state of the art, customizable code editor, as
> > > far as I am aware. (Admittedly, no hard facts in this paragraph.)
> >
> > Which is kind of sad because of course all the code is right there and
> is almost infinitely customizable. :-(
> >
> > tim
> > --
> > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> > Eagles may soar, but weasels aren't sucked into jet engines.
> >
> >
> >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <
> http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211225/321ca36f/attachment.html
> >
> >
> >
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211226/d4a38d48/attachment-0001.html>