hex editor mappings of HOME and END keys

[pvmm]

Pressing the END key on the large window of the hex editor will rewrite the value under the cursor and move it forward one byte, which is a non expected side effect of the END key, since it is supposed to be a navigation key not an editing key.

But if you plug a generic megarom cartridge and write to its memory blocks, it will change the segment address since, on generic 8kb ROM, every memory position is a switching address. So pressing the END key on the hex editor while the large window of the hex editor has focus will cause it to change segment (to the value under the cursor % number of memory banks) which may crash the MSX. To fix this, the END key should change from an editing key to a proper navigation key. And while we are at it, map the HOME and END keys to jump to the beginning and ending of the hex editor memory.

[m9710797]

That's unexpected. But I can make a guess about what is happening:

In the current implementation of the hex-editor (based on this code: https://github.com/ocornut/imgui_club) the cell under the cursor is replaced with a ImGui::InputText() field. A typical behavior for a text input field is to accept the new value after the enter key was pressed. but that's not desired for a hex-editor. The alternative behavior is to accept the new value on every edit action, but that's also not desired here (we want 2 hex digits before writing a new value to memory). So the solution that's currently implemented is: on every input check whether the cursor has reached position = 2. If that's the case then (the assumption is that) 2 hex digits must have been typed, and then we write to memory.

But my guess is that this also triggers when the cursor reaches postion = 2 because the END key was pressed???

(If this guess is correct then) I have no idea yet for how to solve this. Does setting an ImGui::Shortcut() for END override the END key in ImGui::InputText()??
Another possibility could be to not use ImGui::InputText() but implement our own widget. For hex-digit input that might be doable, but I'd prefer to not have to deal with ASCII input myself (I haven't looked yet at the implementation of ImGui::InputText(), maybe it is doable??).

--

Orthogonal to this problem:
Navigating to the top/bottom is more usually done via Ctrl+Home/Ctrl+End. And plain Home/End navigate to the start/end of a line.

Currently the shortcuts for move-up/down/left/right can be customized. That was a good experiment while working on the new shortcut-infrastructure. But now that the infrastructure is in good shape, I think we should remove these customization points again. I can't imagine why anyone would want to have something else than the cursor keys for this, or why someone would want to unbind these shortcuts). Offering these customization points can only cause confusion.
(Note: the internal implementation could still use ImGui::Shortcut(), but I don't think the actual keys should be configurable).

[pvmm]

(Note: the internal implementation could still use ImGui::Shortcut(), but I don't think the actual keys should be configurable).

I agree.