Hi Chris,
A single "closer" hot-key sounds very logical... Would it work for all enclosing symbols, even for | and " ? Not only pair-like ones like {}, <>, () and [] ? How about something like CMD + Backspace (or CTRL + Backspace in Windows). Picking just one of the closer brackets might be a bit confusing for closing " or | pairs... Well, actually, using a closer bracket to remove one level of brackets isn't really a hot-key use (how I understand it), it's just a different semantics of a regular key in a specific context, I think. So maybe just add a universal "closer" hotkey and keep the existing closer brackets functionality?
No strong opinion though :)
Thanks, jaromir
--
Jaromír Matas
mail@jaromir.net
From: Chris Mullermailto:asqueaker@gmail.com Sent: Wednesday, June 1, 2022 1:19 To: The general-purpose Squeak developers listmailto:squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Merge Request: autoEncloseBeforeSpace.cs
Without answering Christoph's question, I'd like to ask an additional one about this topic: I think it's wasteful and complicated to use so many different keys for removing the bracket layer. I liked this idea of separate closer command at first but, after using it a bit, I don't. Now, not only does the user have to think about the different keys for "adding vs. removing", they also have to consider *which* closer bracket to press -- e.g., close bracket? close brace? close paren? -- even though the context makes that burden unnecessary for the user, lest they should press the wrong one and be disrupted even more. It really does force me to "pause" where, with toggle, it didn't.
It also means we now consume... 4(?!) hot keys for a function that used to only consume 1.
If there's no way to go back to toggle, we should at least consume only one hot-key for "removing a level" -- either ) or ] -- that will work on any of the three.
On Fri, May 27, 2022 at 4:10 PM <christoph.thiede@student.hpi.uni-potsdam.demailto:christoph.thiede@student.hpi.uni-potsdam.de> wrote: Hi Jaromir, Marcel, all,
with Morphic-mt.1824 in current Trunk, we have the following behavior for closer brackets:
Via "enclose selection" preference, an opening bracket adds a level and a closer bracket removes a level. No toggling anymore.
So pressing a closer bracket removes the pair of brackets that is *enclosing* the selection. However, I still wonder whether we should also remove the pair of brackets *inside* the selection if there is no further pair of brackets.
So that
[123] (entire line selected)
when pressing
]
becomes
123 (entire line selected)
instead of (as in current Trunk)
] (nothing selected)
Or would this be more inconsistent than convenient? Wdyt?
Best, Christoph
--- Sent from Squeak Inbox Talkhttps://github.com/hpi-swa-lab/squeak-inbox-talk
On 2022-02-07T23:33:53+01:00, christoph.thiede@student.hpi.uni-potsdam.demailto:christoph.thiede@student.hpi.uni-potsdam.de wrote:
Just a quick note to myself, compensating for the lack of meta information on the list: This issue has been resolved via Morphic-mt.1809. Thanks. :-)
Best, Christoph
Sent from Squeak Inbox Talk
On 2021-11-01T22:09:46+01:00, christoph.thiede at student.hpi.uni-potsdam.dehttp://student.hpi.uni-potsdam.de wrote:
Hi all!
This changeset refines the existing autoEnclose mechanism. Instead of having inserted enclosing brackets always, you can now activate a new preference to only insert these characters if there is any space after the cursor. This matches VS Code's setting value "beforeWhitespace" for "editor.autoClosingBrackets".
To me, this mode feels much more convenient because when having traditional autoEnclose enabled, I have been getting angry again and again when I wanted to bracketize an existing expression in some code and suddenly was disrupted by an unneeded closing bracket.
The changeset does not manipulate any defaults. The PreferenceWizard and the ReleaseBuilder are updated, too. Please honor the postscript of the changeset when merging it.
Best, Christoph
Sent from Squeak Inbox Talk