Easy shortcut for setting operand label

[ejelly]

Often when I'm on an instruction, I want to rename the operand to something else than the automatic label it had, because the surrounding code informs me of the (probable) meaning of the operand.

Currently, it seems like the fastest way to do this is to hit Ctrl-O for "Edit Operand", then Alt-L as shortcut for the "Edit Label" button.

However, I find myself doing this sequence much more often than anything else in "Edit Operand", so a dedicated shortcut would be helpful. SourceGen's shortcuts are otherwise very convenient, so this stands out a little.

[BacchusFLT]

I might misunderstand you, but isn't this a thing you can also do by double clicking on the label? /Pontus Berg +46 735 082860 Den sön 23 feb. 2025 21:02ejelly ***@***.***> skrev:

…

Often when I'm on an instruction, I want to rename the operand to something else than the automatic label it had, because the surrounding code informs me of the (probable) meaning of the operand. Currently, it seems like the fastest way to do this is to hit Ctrl-O for "Edit Operand", then Alt-L as shortcut for the "Edit Label" button. However, I find myself doing this sequence much more often than anything else in "Edit Operand", so a dedicated shortcut would be helpful. SourceGen's shortcuts are otherwise very convenient, so this stands out a little. — Reply to this email directly, view it on GitHub <#166>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGZWZSUQ2CF4IEM27QIPAOD2RISL5AVCNFSM6AAAAABXWUDTHWVHI2DSMVQWIX3LMV43ASLTON2WKOZSHA3TGNBTGUYDCMY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> [image: ejelly]*ejelly* created an issue (fadden/6502bench#166) <#166> Often when I'm on an instruction, I want to rename the operand to something else than the automatic label it had, because the surrounding code informs me of the (probable) meaning of the operand. Currently, it seems like the fastest way to do this is to hit Ctrl-O for "Edit Operand", then Alt-L as shortcut for the "Edit Label" button. However, I find myself doing this sequence much more often than anything else in "Edit Operand", so a dedicated shortcut would be helpful. SourceGen's shortcuts are otherwise very convenient, so this stands out a little. — Reply to this email directly, view it on GitHub <#166>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGZWZSUQ2CF4IEM27QIPAOD2RISL5AVCNFSM6AAAAABXWUDTHWVHI2DSMVQWIX3LMV43ASLTON2WKOZSHA3TGNBTGUYDCMY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ejelly]

But I don't want to change the label of the address I'm currently on, I want to change the label of the address that is the operator. Double clicking on the operator just opens the "Edit Operator..." dialogue.

[fadden]

The existing scheme is itself a shortcut. You could Ctrl+J (or double-click on the opcode) to jump to the referenced address, Ctrl+L (or double-click on the label) to edit the label, and then Alt+Left to jump back.

"Edit Label" means "go edit the label that's way over there"; the fact that the operand changes is just part of the automatic label matching. It's very convenient but also potentially confusing.

One approach would be to embed the Edit Label dialog fully inside the Edit Instruction Operand dialog. The dialog is already different for internal vs. external references, e.g.

vs.

The Edit Label dialog has a bunch of logic in it for uniqueness checking and local vs. global scope. The controls and guideline / complaint messages would need to be carried over, and it might be useful to have the visuals emphasize that you're editing something in a completely different part of the project.

BTW, here's how that dialog used to look in v1.0:

[ejelly]

The existing scheme is itself a shortcut. You could Ctrl+J (or double-click on the opcode) to jump to the referenced address, Ctrl+L (or double-click on the label) to edit the label, and then Alt+Left to jump back.

I tried exactly that before, but it does not mesh well with "Seek nearby targets" unfortunately, as Ctrl-J jumps to the nearby target, not to the exact location specified by the operand.

"Edit Label" means "go edit the label that's way over there"; the fact that the operand changes is just part of the automatic label matching. It's very convenient but also potentially confusing.

Yep, effectively I'm looking for a way to directly get me into the "far" "Edit Label" dialogue that I entered through "Edit Operand", though admittedly "Ctrl-O Alt-L" isn't too bad.

It's just that this sequence seems to be by far one of the most actions I perform when understanding and annotating code. I'm not actually sure I perform a normal "Ctrl-L" more often, since I usually do that on code labels only. For data labels, I almost always name them when I'm looking at some instruction that has them as an operand, as that is usually what makes me understand what the operand memory is used for.

[fadden]

Another approach would be to create a top-level "edit the operand target's label" command, bypassing Edit Operand altogether. Makes some sense, since you're not really trying to edit the operand. Maybe Ctrl+Shift+L to invoke.

Ctrl-O Alt+L is annoying because you have to change which modifier key you're holding down. (Create/Edit Visualization Set is mapped to an Alt key so you can just Alt+V Alt+V when creating a new one.)

[ejelly]

That sounds good.

By the way, I just ran into a slightly different situation where that would be good.

I auto-formatted a jump-table which is just a list of words, where each word is a jump target. Here, the position in the jump table directly informs me what the name of each code label should be. In this case, I don’t even want to do ctrl-L on the actual jump table entries at all, since they never seem to be individually referenced. But when on such a “.dd2 Txxxx” entry, with “Txxxx” being the automatically generated label, I get a different “Edit Operand” Dialog box that does not even offer the “Edit Label” button, so I have to jump with ctrl-J first now, before I can edit the “far” code label.

[ejelly]

By the way, I do appreciate how you are considering ergonomics in general. For me, reverse engineering code is a special activity, where being able to very quickly and easily perform common actions is important for two reasons:

1. You want the action to be done really quickly, because you are performing it a lot, and you don’t want to impede progress more than necessarily.
2. More importantly, RE is an activity which requires a lot of focus and management of your own (your brain’s) working memory, so you want to be taken out of your “flow” of understanding and annotating code as little as possible. If my attention has to switch context, or be hijacked by a bunch of tedious actions to reach a simple goal, it risks taking over my working memory with this tedium.

Luckily, SourceGen is already pretty good at this overall. I do sometimes wish that things like purely renaming something would not pop up a Dialog Box at all, but let me perform it "inline" in the code list, but I do realize that may be a bigger feature to implement, and the Dialog Boxes are not that much of a problem if they have good defaults and are predictable (e.g. I don't usually even have to look at the ctrl-L Dialog Box).

The only other thing that tends to mess with my working memory a little is following references to a symbol, especially when I started from an operand. There seems to be no "running list" of followed references, so I have to remember myself which references I've already looked at when I want to quickly browse through them. That's an entirely separate issue, though. (And also not simple to solve, it seems.)

Overall I really enjoy using this tool.

[fadden]

The Edit Data Operand dialog hasn't changed as much since v1.0, and doesn't have the fancy shortcuts. Part of the reason for this is that the dialog is expected to work on multiple items, e.g. you can select 40 bytes and format them as one string, or as 20 16-bit addresses, or 10 32-bit words. Formatting a label at a single target address is very situational and harder to present in a lucid way.

I think the specific case of a data address reference could work off the same "edit the operand target's label" command. It would only be enabled for a data item if a single line with an address reference were selected.

IIRC, editing text directly in the field isn't supported by WPF ListView. (It is by DataGrid, but that has a bunch of other problems.) I think the difference is mostly visual rather than functional: either way you hit Ctrl+L, type text, and hit Return. (Most dialogs with text fields will start with the text area selected and focused, and will close when Return or Ctrl+Return is hit.) "Inline" editing looks a little cleaner, but you lose the scope buttons and it's harder to notify you when you picked a duplicate label.

Re: flow. I believe good tools should help you work without getting in the way. If you feel like you're interacting with the tool, rather than solving a problem, then something is off. There are still many opportunities for improvement. Some of them require substantial changes, but I think what we're talking about here is pretty simple. The only drawback I can think of is that it's one more item in a rather long Actions menu.

Re: symbol refs. Walking through all references to a symbol can't be done effectively with the References window, because it's dynamic. It could be done by generating a separate list, like the "find all" feature in Visual Studio. Since the list doesn't change without a specific command, the set of entries and current selection wouldn't change as you moved around the file. I have a "to do" item in the wiki to add something like this to the "find" feature, but it could also be useful for reference-chasing. SourceGen doesn't have "dockable" windows, but it could pop up like the messages window, or be a floater. Maybe a "copy references window contents to separate list" command would create it.

Thank you for all the feedback. I think we have a similar way of thinking about tools, but after a while you sort of settle into a "that's just how it works" mindset and don't necessarily see the opportunities for improvement.

[fadden]

I poked at this a bit more. There are five possible paths for a top-level "edit operand target label" command:

1. For an instruction with an address operand, when the address is within the file, we edit the label at the best offset for that address. (We support overlays and multi-bank ROMs, so there can be more than one offset for a given address.)
2. For an instruction with an address operand, when the address is outside the file, we can create or edit a project symbol. If the operand's target is defined by a platform symbol, i.e. it's in a .sym65 file, we can't edit it, but we can create a project symbol that overrides it. So for platform symbols, we can either open a "create project symbol" dialog or just refuse to edit it.
3. For an instruction with an address operand, when the address is a zero-page value defined in a local variable table, we should edit the appropriate LVT entry.
4. For a single data item with an address operand (e.g. .dd2) within the file, edit the label at the target address, as above.
5. For a single data item with an address operand (e.g. .dd2) outside the file, do the project/platform symbol stuff, as above.

In all cases, the target offset may not exactly match the target address, because e.g. an instruction can reference bytes inside a multi-byte instruction for self-modifying code. In such cases it's necessary to back up to the byte at the start of the line.

In the current implementation, items 1-3 are recognized by the Edit Instruction Operand dialog init code, which configures the "Numeric Address Reference" sub-panel appropriately based on context, and allows you to choose between treating a zero-page value as global (project symbol) or local variable. Items 4-5 aren't handled at all, because the Edit Data Operand dialog doesn't have an "edit label" shortcut.

Handling a subset of these paths isn't really viable, because it leads to a "WTF why isn't this working" moment. I need to refactor some of the logic out of the operand edit dialog so it's not in multiple places. For the ambiguous case of a zero-page operand with no existing platform/project/LVT symbol, I think it's reasonable to default to creating a new project symbol.

---

I was curious about why the Ctrl+J behavior seemed slightly different. The "jump to operand" code prefers to jump to the offset associated with a symbol when one has been supplied by the user for the operand. For example, if you have:

$0800  FOO .dd2 123
$0802      .dd2 456
$0804 START lda $0802

If you edit the operand at $0804, the "edit label" button would edit a label at $0802. Suppose you give the operand the symbol FOO, which will appear as "FOO+2" in the listing. If you double-click on the operand, the selection jumps to FOO at $0800. (The instruction operand edit dialog disables the Edit Label button when a symbol is defined for the operand to avoid confusion.)

It looks like the behavior used to favor the operand address, but was changed to favor the symbol during some work on OMF relocation data handling (notably this change).

[ejelly]

In all cases, the target offset may not exactly match the target address, because e.g. an instruction can reference bytes inside a multi-byte instruction for self-modifying code. In such cases it's necessary to back up to the byte at the start of the line.

Careful with assumptions there! Almost every time I want to edit the operand of an instruction, I want to edit or create a label at the actually referenced address, not at a previous one that “Seek nearby targets” identified with an offset. It’s basically me telling the system “no, this is a separate variable”.

[fadden]

Careful with assumptions there! Almost every time I want to edit the operand of an instruction, I want to edit or create a label at the actually referenced address, not at a previous one that “Seek nearby targets” identified with an offset. It’s basically me telling the system “no, this is a separate variable”.

There are two related but different situations:

1. Reference to the middle of a multi-line object.
2. Reference to the middle of a single line object.

You always need to back up to the start of the line, because you can't put a label in the middle of a line. For example:

  $0800 START lda $1234
  $0803       sta $0801  <-- ops must jump to or edit label at $0800

Situation (1) is where the Ctrl+J and "edit label" behaviors differ... one jumps to the line with the label that matches the symbol, the other edits the label on the line that matches the operand's value. The goal of "edit operand target label" would be to match the "edit label" behavior, which is what you want.