Hi Eliot,<br>
<br>
Nothing more to add. Of course, conditionals have their place and n-ary dispatch is not always the most elegant solution. :-)<br>
<br>
> Well, I think there's a lot of work still remaining to do with completion.<br>
> I find completion great only some of the time.  I find myself fighting the<br>
> completion tool a lot when I'm done and want to exit from selecting a<br>
> completion and return to normal typing.  Is it better that, for example, up<br>
> or down arrow would cause one to exit completion if doing up-arrow on the<br>
> first completion or down arrow on the last, or that one is trapped within<br>
> the completion menu and has to type escape to leave it?  Would a right<br>
> arrow be a good escape choice?  I think we shoudl be video taping people's<br>
> editing sessions and analysing it to do a better job because my<br>
> relationship with completion verges on love/hate :-)<br>
<br>
Yes, this is also an interesting construction site. I'm assuming you are using oCompletion? Personally, I'm often using the Autocompletion fork <https://github.com/LeonMatthes/Autocompletion> which does not only have nice contextual and type-guessed suggestions but also some changes to the keyboard handling iirc. However, most of the time I'm not noticing at all when I am using Autocompletion, which speaks for the intuitivity of the keyboard shortcuts. If you did not try it out yet, you also might want to check Sandblocks <https://github.com/hpi-swa/sandblocks> with a refreshingly new approach on typing. :-)<br>
<br>
Happy Squeaking,<br>
Christoph<br>
<br>
<font color="#808080">---<br>
</font><font color="#808080"><i>Sent from </i></font><font color="#808080"><i><a href="https://github.com/hpi-swa-lab/squeak-inbox-talk"><u><font color="#808080">Squeak Inbox Talk</font></u></a></i></font><br>
<br>
On 2022-02-07T17:01:13-08:00, eliot.miranda@gmail.com wrote:<br>
<br>
> Hi Christoph,<br>
> <br>
> On Mon, Feb 7, 2022 at 3:05 PM <christoph.thiede at student.hpi.uni-potsdam.de><br>
> wrote:<br>
> <br>
> > Hi Eliot,<br>
> ><br>
> > I was not sure whether we should continue this debate, because I believe<br>
> > that we are actually not disagreeing but just talking about different<br>
> > things. :-) Anyway, it is an interesting debate and I thank you for your<br>
> > insightful comparison of different language models for choice.<br>
> ><br>
> <br>
> Agreed.  It *is* interesting.  One of the things I've found in working on<br>
> Smalltalk and on the VM in Smalltalk is that avoiding conditionals by using<br>
> polymorphism is great, a very powerful style, but one that works at a<br>
> granularity of class hierarchies, and is not one that works, for example,<br>
> on bit level twiddling.  So in the VM there are points where the caseOf:<br>
> statement is very important, and useful (and the same goes for<br>
> ifTrue:/ifFalse:).  I also find that it takes time to evolve a beautiful<br>
> polymorphic solution and sometimes we are in a position where there is code<br>
> to be written quickly, and its quality is of less importance than its<br>
> timeliness.  When we're lucky we get to revisit and replace the old crud<br>
> with nicer, better designed code.  But I do know that not all code is able<br>
> to be so reduced to a beautiful minimum, and that caseOf: &<br>
> ifTrue:/ifFalse: have their place, and hence that ifTrue:/ifFalse:'s<br>
> static frequency argues strongly for the keyboard shortcuts.<br>
> <br>
> > So in general, I was talking about an abstract/conceptual/a priori<br>
> > argument about the pure syntax only where all selectors are equal. I claim<br>
> > that you could *describe* an algebra or a state machine in Smalltalk<br>
> > without using conditional selectors. #ifTrue:/#ifFalse: is common but not<br>
> > without alternatives. As stated before, I did not request to change the<br>
> > existing behavior.<br>
> ><br>
> <br>
> OK.<br>
> <br>
> > On the other hand, you are talking about statistics and numbers, and I<br>
> > agree with you that #ifTrue:/#ifFalse: are definitively under the top five<br>
> > (how could I deny it...). Actually, in my image, #at: is used more<br>
> > frequently than #ifFalse: (#(ifTrue: 4.56 at: 3.16 ifFalse: 2.7 = 2.33<br>
> > assert: 1.93)). So consequently, we would also have to talk about mapping<br>
> > Cmd + Shift + A to #at:, since I do think that dynamic state accesses are a<br>
> > general property of programming languages just like explicit conditional<br>
> > choice. Please pardon me if this is an uninteded straw man, in this case<br>
> > I'm interested about learning the difference between those two fundamental<br>
> > properties. :-)<br>
> ><br>
> <br>
> I don't find it a straw man.<br>
> <br>
> ><br>
> > > Personal preference is no argument for changing the behaviour of a<br>
> > community-developed programming system, is it?<br>
> ><br>
> > You're right. :-) Neither we should break a harmless feature that many<br>
> > people are used to (again: I never requested this...), nor we should ignore<br>
> > statistical evidence when publishing a new tool. I guess I was rather<br>
> > having the idea of a minimum complete tool in mind which is intrinsic to<br>
> > Smalltalk, and which would not require any shortcuts at all. Just treat it<br>
> > as a small thought experiment ... :-)<br>
> ><br>
> <br>
> Well, I think there's a lot of work still remaining to do with completion.<br>
> I find completion great only some of the time.  I find myself fighting the<br>
> completion tool a lot when I'm done and want to exit from selecting a<br>
> completion and return to normal typing.  Is it better that, for example, up<br>
> or down arrow would cause one to exit completion if doing up-arrow on the<br>
> first completion or down arrow on the last, or that one is trapped within<br>
> the completion menu and has to type escape to leave it?  Would a right<br>
> arrow be a good escape choice?  I think we shoudl be video taping people's<br>
> editing sessions and analysing it to do a better job because my<br>
> relationship with completion verges on love/hate :-)<br>
> <br>
> <br>
> > Best,<br>
> > Christoph<br>
> ><br>
> > ---<br>
> > *Sent from **Squeak Inbox Talk<br>
> > <https://github.com/hpi-swa-lab/squeak-inbox-talk>*<br>
> ><br>
> > On 2021-12-26T12:26:19-08:00, eliot.miranda at gmail.com wrote:<br>
> ><br>
> > > Hi Christoph,<br>
> > ><br>
> > > On Sun, Dec 26, 2021 at 6:52 AM <christoph.thiede at<br>
> > student.hpi.uni-potsdam.de><br>
> > > wrote:<br>
> > ><br>
> > > > Hi all,<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > *Ad discussion theme #1: *<br>
> > > > > If you really want to mess around with this kind of thing I'd suggest<br>
> > > > making a proper config tool that let's you configure every available<br>
> > key<br>
> > > > and meta combination, with saveable mappings attached to the prefs so<br>
> > you<br>
> > > > can have whatever you personally want.<br>
> > > ><br>
> > > > Sure, why not? But definitely not before the release. :D<br>
> > > ><br>
> > > > > That's why I would vote for showing off all the bells and whistles by<br>
> > > > default, and make it easy to disable them if they are annoying.<br>
> > > ><br>
> > > > +1<br>
> > > ><br>
> > > > > "Did you find that useful? If not you can disable it in the<br>
> > preferences<br>
> > > > _here_ ..."<br>
> > > ><br>
> > > > +1, but only if it can be turned off, and only after the release, of<br>
> > > > course. :D<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > *Ad discussion theme #2: *<br>
> > > > > Just a remark: out of the box, Cmd-[ is not accessible on a German<br>
> > > > Windows-type quertz keyboard because we have to use Alt Gr (which is<br>
> > > > equivalent to Ctrl+Alt) + 8 to type [ in the first place, so all<br>
> > modifiers<br>
> > > > that could possibly map to Cmd are already held down. Same issue with<br>
> > curly<br>
> > > > braces.<br>
> > > ><br>
> > > > Just to note what I have already written to Jakob in private: Even when<br>
> > > > switching my keyboard layout from Qwertz to Qwerty, I was not able to<br>
> > make<br>
> > > > use of Ctrl-[ or Alt+[ (Win32, VM 202112201228). Is this feature only<br>
> > > > available on Linux/macOS?<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > *Ad discussion theme #3: *<br>
> > > > > General purpose, programmable, mumble, see above. It seems as if you<br>
> > are<br>
> > > > making the mistake of assuming there can only be one editor setup.<br>
> > > > Currently in Squeak we do rather do that, with the editors for pretty<br>
> > much<br>
> > > > all text-things being the same with the same menu even when<br>
> > inappropriate.<br>
> > > > We should do better.<br>
> > > ><br>
> > > > +1. We already have #pluggableTextSpec vs #pluggableCodePaneSpec but<br>
> > > > something like a #contentType flag would not harm, too. :-)<br>
> > > ><br>
> > > > > > I did *not* request to remove this shortcut because I understand<br>
> > that<br>
> > > > some long-standing Squeakers might have gotten used to it. My argument<br>
> > was<br>
> > > > only not to cement this kind of "leaky abstractions". IMHO the editor<br>
> > > > should be a tool that is suitable for all applications or domains in<br>
> > the<br>
> > > > same way, without putting advantages or disadvantages to certain<br>
> > domains.<br>
> > > > ><br>
> > > > > But the editor is explicitly divided into a domain-independent<br>
> > > > TextEditor and a domain-specific SmalltalkEditor anyway. So your<br>
> > objection<br>
> > > > is not relevant. We?re discussing (I hope) the accelerator keys for the<br>
> > > > SmalltalkEditor.<br>
> > > ><br>
> > > > IMO this should rather be part of a separate subclass of<br>
> > SmalltalkEditor:<br>
> > > ><br>
> > > > Editor: Minimal tool for editing strings (e.g., backspace).<br>
> > > > TextEditor: Tool for editing formatted strings (e.g., adding/removing<br>
> > > > attributes).<br>
> > > > SmalltalkEditor: Tool for editing Smalltalk code (e.g., <opt>1 for<br>
> > adding<br>
> > > > method parameters).<br>
> > > > ControlFlowStyleSmalltalkEditor: Tool for editing Smalltalk code in the<br>
> > > > style of low-level control-flow operations such as #whileTrue,<br>
> > > > #ifTrue:/#ifFalse:, etc.<br>
> > > ><br>
> > > > > > A developer working in another domain (that abstracts from<br>
> > > > booleans/for instance, a query DSL) will be less likely interested in<br>
> > > > special shortcuts for ifTrue:/ifFalse: but more likely interested in<br>
> > > > shortcuts for message sends such as #collect:, #select:, etc. I only<br>
> > wanted<br>
> > > > to present this perspective before we start occupying even more<br>
> > shortcuts<br>
> > > > for randomly chosen selectors that might be of increased importance<br>
> > for a<br>
> > > > subset of users of the Smalltalk workspace.<br>
> > > > ><br>
> > > > > ifTrue:/ifFalse: are hardly randomly selected selectors, now are<br>
> > they?<br>
> > > ><br>
> > > > They don't play a special role in the Smalltalk syntax, do they?<br>
> > Booleans<br>
> > > > are just objects like Collections or Morphs. #ifTrue: is just a<br>
> > selector<br>
> > > > like #select: or #openInWorld. They are only handled differently by the<br>
> > > > VM/interpreter for the sake of optimization (value types, inlined<br>
> > special<br>
> > > > selectors, ...). But conceptually, they are nothing special in our<br>
> > > > beautifully minimal Smalltalk grammar. They do not need to be<br>
> > mentioned on<br>
> > > > the Smalltalk Postcard.<br>
> > > ><br>
> > > > Statistically, you are right of course that #ifTrue: might be one of<br>
> > the<br>
> > > > most popular selectors in most Smalltalk programs. But that is not an<br>
> > > > intrinsic property of Smalltalk [...]<br>
> > ><br>
> > ><br>
> > > but it is. In fact, it is a general property of programming languages.<br>
> > > Choice is intrinsic in general purpose programming (less so in stream<br>
> > > oriented programming), so much so that it is available in many<br>
> > > different forms. Smalltalk provides polymorphic dispatch and closures,<br>
> > > from which we derive ifTrue:ifFalse: et al. In functional languages one<br>
> > > sees pattern matching. In machine languages one sees conditional jumps<br>
> > and<br>
> > > conditional skips. In fact it is definitional that interesting programs<br>
> > > involve choice. Even the Mandelbrot set depends on choice: the typical<br>
> > > implementation is to ask how many iterations of [image: {\displaystyle<br>
> > > f_{c}(z)=z^{2}+c}] does it take for z to converge or diverge to infinity.<br>
> > ><br>
> > > So you can rail against ifTrue:/ifFalse: but you are pissing in the rain.<br>
> > ><br>
> > > Now let's have a look at the numbers. One might think one could could<br>
> > > keywords using:<br>
> > ><br>
> > > | keywordCounts |<br>
> > > keywordCounts *:=* Bag new.<br>
> > > CurrentReadOnlySourceFiles cacheDuring:<br>
> > > [self systemNavigation allSelect:<br>
> > > [:cm|<br>
> > > cm selectorsDo:<br>
> > > [:s|<br>
> > > s isKeyword<br>
> > > ifTrue: [keywordCounts addAll: s keywords]<br>
> > > ifFalse: [keywordCounts add: s]].<br>
> > > false]].<br>
> > > keywordCounts sortedCounts<br>
> > ><br>
> > > but of course this doesn't count inlined messages. So we have to<br>
> > > decompile; amd let's generate a report in percentage terms:<br>
> > ><br>
> > > | keywordCounts keywordCount |<br>
> > > keywordCounts *:=* Bag new.<br>
> > > CurrentReadOnlySourceFiles cacheDuring:<br>
> > > [self systemNavigation allSelect:<br>
> > > [:cm|<br>
> > > cm methodNode nodesDo:<br>
> > > [:n|<br>
> > > n isMessageNode ifTrue:<br>
> > > [n selector key isKeyword<br>
> > > ifTrue: [keywordCounts addAll: n selector key<br>
> > > keywords]<br>
> > > ifFalse: [keywordCounts add: n selector key]]].<br>
> > > false]].<br>
> > > keywordCount *:=* keywordCounts size.<br>
> > > String streamContents:<br>
> > > [:s|<br>
> > > (keywordCounts sortedCounts first: 100) do:<br>
> > > [:assoc|<br>
> > > s nextPutAll: assoc value; space; print: assoc key * 100.0 /<br>
> > > keywordCount maxDecimalPlaces: 2; cr]]].<br>
> > ><br>
> > > #(ifTrue: 5.31<br>
> > > ifFalse: 3.13<br>
> > > = 2.65<br>
> > > at: 2.5<br>
> > > + 2.36<br>
> > > assert: 1.98<br>
> > > == 1.82<br>
> > > new: 1.57<br>
> > > to: 1.41<br>
> > > , 1.41<br>
> > > - 1.35<br>
> > > do: 1.32...<br>
> > ><br>
> > > So ifTrue: and ifFalse: are more popular than the next three combined,<br>
> > > almost the next four. ifTrue: is twice as likely as the third (=). And<br>
> > > lest you think this is my style, the percentages in a VMMaker image are<br>
> > > slightly less: ifTrue: 5.24%, ifFalse: 3.05%.<br>
> > ><br>
> > > [...] and personally I dislike the idea of coupling statistic insights<br>
> > > > about API usage to globally predefined shortcuts in the default Trunk<br>
> > > > image. It is possible to write Smalltalk programs that use alternative<br>
> > APIs<br>
> > > > (the Collection API would just be one example) that never make use of<br>
> > the<br>
> > > > Boolean protocol.<br>
> > > ><br>
> > ><br>
> > > Personal preference is no argument for changing the behaviour of a<br>
> > > community-developed programming system, is it?<br>
> > ><br>
> > ><br>
> > > ><br>
> > > > Best,<br>
> > > > Christoph<br>
> > > ><br>
> > > > ---<br>
> > > > *Sent from **Squeak Inbox Talk<br>
> > > > <https://github.com/hpi-swa-lab/squeak-inbox-talk>*<br>
> > > ><br>
> > > > On 2021-12-25T16:03:32+01:00, marcel.taeumel at hpi.de wrote:<br>
> > > ><br>
> > > > > Hi all --<br>
> > > > ><br>
> > > > > Done. See Morphic-mt.1829. cmd+[ etc. is back if you enable the<br>
> > "legacy<br>
> > > > shortcuts" preference.<br>
> > > > ><br>
> > > > > Best,<br>
> > > > > Marcel<br>
> > > > > Am 25.12.2021 12:47:15 schrieb Marcel Taeumel <marcel.taeumel at<br>
> > hpi.de<br>
> > > > >:<br>
> > > > > Hi all --<br>
> > > > ><br>
> > > > > I am currently collecting the US-specific TextEditor shortcuts that<br>
> > got<br>
> > > > lost since Squeak 5.3 to make them available again as a<br>
> > preference-driven<br>
> > > > event filter on instances of TextEditor. Shouldn't be that hard. I will<br>
> > > > call the preference "Legacy keyboard shortcuts (US only)" or something<br>
> > like<br>
> > > > that.<br>
> > > > ><br>
> > > > > You can help me do that by answering here:<br>
> > > > ><br>
> > > ><br>
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217783.html<br>
> > > > [<br>
> > > ><br>
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217783.html<br>
> > > > ]<br>
> > > > ><br>
> > > > ><br>
> > > > > Thanks. :-)<br>
> > > > ><br>
> > > > > Best,<br>
> > > > > Marcel<br>
> > > > > Am 23.12.2021 21:09:53 schrieb tim Rowledge <tim at rowledge.org>:<br>
> > > > ><br>
> > > > ><br>
> > > > > > On 2021-12-23, at 4:39 AM, Jakob Reschke wrote:<br>
> > > > > ><br>
> > > > > > I believe that because Squeak does not have a<br>
> > > > > > reputation of being a state of the art, customizable code editor,<br>
> > as<br>
> > > > > > far as I am aware. (Admittedly, no hard facts in this paragraph.)<br>
> > > > ><br>
> > > > > Which is kind of sad because of course all the code is right there<br>
> > and<br>
> > > > is almost infinitely customizable. :-(<br>
> > > > ><br>
> > > > > tim<br>
> > > > > --<br>
> > > > > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim<br>
> > > > > Eagles may soar, but weasels aren't sucked into jet engines.<br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > > -------------- next part --------------<br>
> > > > > An HTML attachment was scrubbed...<br>
> > > > > URL: <<br>
> > > ><br>
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211225/321ca36f/attachment.html<br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> > > ><br>
> > ><br>
> > ><br>
> > > --<br>
> > > _,,,^..^,,,_<br>
> > > best, Eliot<br>
> > > -------------- next part --------------<br>
> > > An HTML attachment was scrubbed...<br>
> > > URL: <<br>
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211226/d4a38d48/attachment-0001.html<br>
> > ><br>
> > ><br>
> > ><br>
> ><br>
> <br>
> <br>
> -- <br>
> _,,,^..^,,,_<br>
> best, Eliot<br>
> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220207/bc287a0b/attachment.html><br>
> <br>
>