StudioInfinity/dyna3
2
0
Fork 2
Code Issues 86 Pull requests 1 Projects 2 Releases 4 Wiki Activity Actions

Make it easy to reassign already-used identifiers #150

New issue
Open
opened 2026-06-08 19:34:34 +00:00 by Vectornaut · 3 comments
Vectornaut commented 2026-06-08 19:34:34 +00:00
Member
Copy link

We'd like to make it easy to change an element's identifier when the desired identifier is already in use. Many mechanisms for this involve stealing the desired identifier.

Example scenario

As an example, suppose we have the following elements

Identifier Color
apple yellow
banana orange
cantaloupe red

and we want to permute their identifiers like this:

Identifier Color
banana yellow
cantaloupe orange
apple red

We don't want to look at the existing identifier list ahead of time, or think about what order to change the identifiers in. To model this, we'll assume that we plan to rename the elements in the order yellow, orange, red.

The bar to clear

To resolve this issue, we need to at minimum come up with a workflow that's smoother than the existing one.

  1. Try to rename the yellow element to banana.
    • Get an error indicator reporting the identifier collision.
  2. Rename the orange element to temp_orange (or something).
  3. Rename the yellow element to banana.
  4. Try to rename the orange element to cantaloupe.
    • Get an error indicator reporting the identifier collision.
  5. Rename the red element to apple.
    • We can only do this if we've noticed that apple is now available. Otherwise, we'd use another temporary identifier, like temp_red, which will take an extra step to change later.
  6. Rename the orange element to cantaloupe.

Implementation ideas for the graphical interface

Steal identifier with warning indicator

When you're typing in an identifier field, it continually checks whether the current value is in use as an identifier already, and shows a warning indicator if so. If you complete the input despite the warning, that means you want to steal the identifier.

Pros:
  • Smooth and unobtrusive
Cons:
  • It might be hard to display a continually updated warning indicator like this for screen reader users.
  • Smooth and unobtrusive also means easy to miss, especially if you're quickly reassigning several identifiers.
Example scenario workflow
  1. Enter banana in the yellow element's identifier field.
    • Hopefully notice the warning indicator before completing the input.
  2. Enter cantaloupe in the orange element's identifier field.
    • Hopefully notice the warning indicator before completing the input.
  3. Enter apple in the red element's identifier field.

Extra enter to steal identifier

If you try to assign an identifier that's already in use to a different element, the identifier doesn't get assigned when you complete the input. Instead, a warning indicator appears. You can then press enter to steal the identifier.

Pros
  • If you type enter to complete the identifier input, a second enter doesn't take much extra hand motion.
Cons
  • It's not clear what should happen when you complete an identifier input by shifting focus rather than typing enter.
Example scenario workflow
  1. Type banana in the yellow element's identifier field and press enter.
    • Notice the warning indicator.
  2. Press enter again.
  3. Type cantaloupe in the orange element's identifier field and press enter.
    • Notice the warning indicator.
  4. Press enter again.
  5. Type apple in the red element's identifier field and press enter.

Shift + enter to steal identifier

When you enter a new identifier, you can complete the input by pressing shift + enter to indicate that you want to steal it. If you complete the input in the usual way, by pressing enter or shifting focus, the identifier only gets assigned if it's not already in use. If it is already in use, it stays unassigned, and a warning indicator appears.

Pros
  • This is a nice way to signal your intention when you complete the input.
Cons
  • For users who usually want to steal identifiers, pressing shift all the time might feel like a pointless burden. A similar thing happens in Mathematica, where you use shift + enter to execute cells, and in chat apps that use shift + enter to input line breaks.
Example scenario workflow
  1. Type banana in the yellow element's identifier field and press shift + enter.
  2. Type cantaloupe in the orange element's identifier field and press shift + enter.
  3. Type apple in the red element's identifier field and press shift + enter.
    • The shift isn't needed in this case, but it's probably easier to press shift it than to think about whether apple is still in use.

Implementation ideas for the command line

To be added.

We'd like to make it easy to change an element's identifier when the desired identifier is already in use. Many mechanisms for this involve *stealing* the desired identifier. ### Example scenario As an example, suppose we have the following elements Identifier | Color --- | --- `apple` | yellow `banana` | orange `cantaloupe` | red and we want to permute their identifiers like this: Identifier | Color --- | --- `banana` | yellow `cantaloupe` | orange `apple` | red We don't want to look at the existing identifier list ahead of time, or think about what order to change the identifiers in. To model this, we'll assume that we plan to rename the elements in the order *yellow*, *orange*, *red*. ### The bar to clear To resolve this issue, we need to at minimum come up with a workflow that's smoother than the existing one. 1. Try to rename the yellow element to `banana`. - Get an error indicator reporting the identifier collision. 2. Rename the orange element to `temp_orange` (or something). 3. Rename the yellow element to `banana`. 4. Try to rename the orange element to `cantaloupe`. - Get an error indicator reporting the identifier collision. 5. Rename the red element to `apple`. - We can only do this if we've noticed that `apple` is now available. Otherwise, we'd use another temporary identifier, like `temp_red`, which will take an extra step to change later. 6. Rename the orange element to `cantaloupe`. ### Implementation ideas for the graphical interface #### Steal identifier with warning indicator When you're typing in an identifier field, it continually checks whether the current value is in use as an identifier already, and shows a warning indicator if so. If you complete the input despite the warning, that means you want to steal the identifier. ##### Pros: - Smooth and unobtrusive ##### Cons: - It might be hard to display a continually updated warning indicator like this for screen reader users. - Smooth and unobtrusive also means easy to miss, especially if you're quickly reassigning several identifiers. ##### Example scenario workflow 1. Enter `banana` in the yellow element's identifier field. - Hopefully notice the warning indicator before completing the input. 2. Enter `cantaloupe` in the orange element's identifier field. - Hopefully notice the warning indicator before completing the input. 3. Enter `apple` in the red element's identifier field. #### Extra *enter* to steal identifier If you try to assign an identifier that's already in use to a different element, the identifier doesn't get assigned when you complete the input. Instead, a warning indicator appears. You can then press *enter* to steal the identifier. ##### Pros - If you type *enter* to complete the identifier input, a second *enter* doesn't take much extra hand motion. ##### Cons - It's not clear what should happen when you complete an identifier input by shifting focus rather than typing *enter*. ##### Example scenario workflow 1. Type `banana` in the yellow element's identifier field and press *enter*. - Notice the warning indicator. 2. Press *enter* again. 3. Type `cantaloupe` in the orange element's identifier field and press *enter*. - Notice the warning indicator. 4. Press *enter* again. 5. Type `apple` in the red element's identifier field and press *enter*. #### *Shift* + *enter* to steal identifier When you enter a new identifier, you can complete the input by pressing *shift* + *enter* to indicate that you want to steal it. If you complete the input in the usual way, by pressing *enter* or shifting focus, the identifier only gets assigned if it's not already in use. If it is already in use, it stays unassigned, and a warning indicator appears. ##### Pros - This is a nice way to signal your intention when you complete the input. ##### Cons - For users who usually want to steal identifiers, pressing *shift* all the time might feel like a pointless burden. A similar thing happens in *Mathematica*, where you use *shift* + *enter* to execute cells, and in chat apps that use *shift + enter* to input line breaks. ##### Example scenario workflow 1. Type `banana` in the yellow element's identifier field and press *shift* + *enter*. 2. Type `cantaloupe` in the orange element's identifier field and press *shift* + *enter*. 3. Type `apple` in the red element's identifier field and press *shift* + *enter*. - The *shift* isn't needed in this case, but it's probably easier to press *shift* it than to think about whether `apple` is still in use. ### Implementation ideas for the command line ***To be added.***
glen commented 2026-06-08 19:44:45 +00:00
Owner
Copy link

@Vectornaut wrote in #150 (comment):

Cons
* It's not clear what should happen when you complete an identifier input by shifting focus rather than typing _enter_.

I think the primary reason it is not clear is that we don't yet have a design for identifier change via direct entry into an editable identifier field. So I think this issue in some sense becomes part of the design of that facility, for which I will file another issue and reference this one (and make this depend on that one).

@Vectornaut wrote in https://code.studioinfinity.org/StudioInfinity/dyna3/issues/150#issue-608: > ##### Cons > > * It's not clear what should happen when you complete an identifier input by shifting focus rather than typing _enter_. I think the primary reason it is not clear is that we don't yet have a design for identifier change via direct entry into an editable identifier field. So I think this issue in some sense becomes part of the design of that facility, for which I will file another issue and reference this one (and make this depend on that one).
glen commented 2026-06-08 20:18:51 +00:00
Owner
Copy link

OK, so having added #151, let's take one example behavior for changing an identifier via a gui, namely the initially recommended one of "close/change focus to submit". In that case,for the "extra enter to steal identifier" option, any gesture to close the text box should display/emphasize the identifier in use indicator, adding the "enter to steal identifier" message, and the close behavior should not fire, leaving the focus on the text entry box. On the other hand, more "passive" changes of focus such as clicking on a different entry box or hitting a change-focus keyboard shortcut (such as, say, tab) are a bit trickier, and may depend on some subtleties of the original ID change text entry box. If in fact that entry box more or less auto-closes on losing focus, which is likely a good design, then certainly a keyboard shortcut change of focus should operate like any other closure of the box per the above. On the other hand, clicking elsewhere to move the focus to that new place shouldn't be disrupted -- I think it's pretty disconcerting to have your specific click ignored/disrupted. So options in that scenario could include:

  • Leave the ID change text box "open" or at least displayed, in a warning but unfocused state, with no effect on the actual ID having taken place
  • Close the ID change text box and revert the ID display to reflect the reality that ID is still what it was before the typing, with an alert visible in some appropriate place that the ID change from "old" to "new" was canceled because "new" is already in use, and perhaps also to retry with explicit "enter" key to steal the "new" id.

There may well be other options worth considering.

OK, so having added #151, let's take one example behavior for changing an identifier via a gui, namely the initially recommended one of "close/change focus to submit". In that case,for the "extra enter to steal identifier" option, any gesture to close the text box should display/emphasize the identifier in use indicator, adding the "enter to steal identifier" message, and the close behavior should not fire, leaving the focus on the text entry box. On the other hand, more "passive" changes of focus such as clicking on a different entry box or hitting a change-focus keyboard shortcut (such as, say, tab) are a bit trickier, and may depend on some subtleties of the original ID change text entry box. If in fact that entry box more or less auto-closes on losing focus, which is likely a good design, then certainly a keyboard shortcut change of focus should operate like any other closure of the box per the above. On the other hand, clicking elsewhere to move the focus to that new place shouldn't be disrupted -- I think it's pretty disconcerting to have your specific click ignored/disrupted. So options in that scenario could include: * Leave the ID change text box "open" or at least displayed, in a warning but unfocused state, with no effect on the actual ID having taken place * Close the ID change text box and revert the ID display to reflect the reality that ID is still what it was before the typing, with an alert visible in some appropriate place that the ID change from "old" to "new" was canceled because "new" is already in use, and perhaps also to retry with explicit "enter" key to steal the "new" id. There may well be other options worth considering.
Vectornaut commented 2026-06-08 20:42:38 +00:00
Author
Member
Copy link

So options in that scenario could include […]

Leaving the identifier field unexpectedly open (with a warning indicator) feels most natural to me. Closing and reverting seems hard to distinguish from what happens when an identifier is assigned successfully.

> So options in that scenario could include […] Leaving the identifier field unexpectedly open (with a warning indicator) feels most natural to me. Closing and reverting seems hard to distinguish from what happens when an identifier is assigned successfully.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
readme-toplevel
kaleidocycle-example
outline-update-fix
lang-trials
seed-problem
demo-summer-2025_update
0.3pre
0.2
v0.1.1
v0.1.0
Labels
Clear labels   
bug
Something is not working

  
ci
Issue concerning the continuous integration system

  
design
Issue that entails architecture/design decisions

  
duplicate
This issue or pull request already exists

  
engine
Issue concerning the engine

  
enhancement
New feature

  
maintenance
Refactors andother behavior-orthogonal tasks

  
prospective
This will become an issue once a particular feature is implemented or pull request is merged

  
question
More information is needed

  
regression
A bug that's resurfaced or a feature that's accidentally been removed

  
stub
We need to fill in the details of this issue

  
todo
Planned step in implementation

  
ui
Issue concerning the user interface

  
wontfix
This won't be fixed

No labels
bug
ci
design
duplicate
engine
enhancement
maintenance
prospective
question
regression
stub
todo
ui
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Depends on
#151 Allow identifier change via direct edit in certain views
StudioInfinity/dyna3
Reference
StudioInfinity/dyna3#150
No description provided.