Delimiter moving

[amyjko]

What's the problem?

There are many uses of delimiters in the Wordplay programming language for data structures and evaluations (e.g., [], {}, ()). Frequently, however, when writing some code, a creator will type a new delimiter pair with the intent of wrapping some existing code in a list, set, map, or evaluation. For example, they might start with this program:

1 + 1

And want to transform it into this:

[1 + 1]

One way to do that is to select the + expression and then type [, but another way that is common is typing it out in a sequence of edits like this:

1 + 1
[]1 + 1
[1 + 1
[1 + 1]

The problem with the sequence above is that the second and third states are syntactically invalid, showing parse errors and also causing layout shifts.

What's the design idea?

The design idea is to allow delimiters to be moved to wrap adjacent content. For example, by moving the right delimiter right in the example above, we could move between a series of valid states to the desired one:

1 + 1
[]1 + 1
[1] + 1
[1 + 1]

Who benefits?

Anyone wanting to edit more efficiently without seeing (or being confused by) syntax errors. And if we eventually decide to prevent syntax errors, this would allow edits that wouldn't otherwise be possible.

Design specification

The design would be as follows. When any paired compound expression delimiter ([], {}, ()) is selected in the editor, a command would be enabled that moves the selected delimiter left or right. Movement left or right means moving the the delimiter to the left/right of the nearest expression bounded by another delimiter and then re-parsing. For example if the [ to the left of 3 was selected and left was pressed:

[ 1 2 [ 3 4 ] ]

This would be the result:

[ 1 [ 2 3 4 ] ]

But if the second [ was selected left of the 1 and left was pressed:

[ [ 1 2 3 4 ] ]

There would be no edit, because the first [ is in the way.

These left/right commands could be triggered in one of three ways:

• A keyboard shortcut (alt-left, alt-right)
• Buttons placed to the left and right of the delimiter when selected
• Dragging the delimiter to the nearest left or right location, which would immediately edit the code accordingly.

[amyjko]

@jianna-braza @HarmaZha, did you want to work on this? I see you both assigning and unassigning yourselves. I'm happy to collaborate with you!

[HarmaZha]

Yes @amyjko, I would like to collaborate on this issue :D.

[jianna-braza]

Hello! Right now, I am working on issue #358, but once this is done, I would be willing to collaborate on this issue.

[mmk49]

@amyjko @HarmaZha , I would like to collaborate on this issue as well if thats alright!

[amyjko]

@HarmaZha and @jianna-braza, it's all yours. I'll take myself off, but feel free to tag me with questions about the design spec I wrote.

[HarmaZha]

@jianna-braza @mmk49 what are your usernames on the discord?

[mmk49]

my username is witherkingkiller! Sorry for the late response, I would love to collaborate.

[HarmaZha]

hi @jianna-braza , @mmk49 and I have exchanged met up and exchanged user names on discord so that we can collaborate on this issue, we would love to collaborate with you so whenever you are done with the other issue, respond to this comment with your discord user name and we can make a group.

[amyjko]

It's the end of Winter! Please provide an update on this issue, including:

• Whether you plan to continue work on it
• If you do not, 1) provide a detailed update of its status, 2) add any unfinished work, 3) list any any unmerged branches, and 4) unassign yourself, so someone else can take over the task. Please leave the issue in better shape than you found it, helping future contributors to start from where you left off.

If you do plan to continue work on it, carry on. Otherwise, thank you for your contributions!

[amyjko]

No reply :( Unassigning @jianna-braza @mmk49 @HarmaZha.

[HarmaZha]

I am so sorry for the late reply, I will not be attending the meetings this quarter because I have another commitment. And I do not have much progress on this issue, so I am going to not commit my version because it would confuse future contributors. I will volunteer and work on this issue in my own time and respond if I do make a breakthrough. I am sorry once again for the late reply.

P.S: One suggestion amy and I had was on the topic of which keys to use for moving the delimiter. Using Alt, Shift, or Control combined with "{" (which ever delimiter the user is using) seems like the best combination for this feature.

[m-arquiza]

Hello! Unless otherwise decided on later, I will not be continuing working on this issue (and will not for the forseeable future, as I will be working fulltime for at least the next 6 months). For anybody working on this issue, I don't have very much work on it (so I will not push anything), but I did start developing on the issue minorly.

What I had so far was a new Command in Commands.ts that was supposed to represent moving a specific bracket symbol: EVAL_OPEN_SYMBOL + CONVERT_SYMBOL, description: (l) => l.ui.source.cursor.insertConvert, visible: Visibility.Visible, category: Category.Modify, alt: true, shift: true, control: true, key: 'ArrowRight', keySymbol: CONVERT_SYMBOL, execute: ({ caret }) => { if (caret === undefined) return false; else return caret.moveBracket() ?? false; }, }, But I hadn't gotten any implementation of the moveBracket() function working, so I only wanted to provide this if anybody wanted to build atop it/take my understanding of where to start as their own starting point.

[amyjko]

Thank you for the update @m-arquiza!