[squeak-dev] Merge Request: autoEncloseBeforeSpace.cs
christoph.thiede at student.hpi.uni-potsdam.de
christoph.thiede at student.hpi.uni-potsdam.de
Sun Dec 26 14:49:39 UTC 2021
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.
> "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 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.
Sent from 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.
> 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. :-)
> 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 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>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev