creating annotated tag broke

[extrawurst]

this is how creating annotated tags used to work (before 0.25):

now its broken. i suspect this broke during the transition to textarea in b9a2e13 by @pm100

[pm100]

to be clear

• 't' should be a single line terminated by 'return/enter'?
• 'T' should be multi line (like commit). With Enter creating a new line and ctrl-enter being confirm and close?

[extrawurst]

@MichaelAug is on this one

[MichaelAug]

The issue is with TextInputComponent handling the ctrl-a keypress to move the cursor to the beginning of line.
https://github.com/extrawurst/gitui/blob/0ab1ff862592d5a16785306d64c035db24e87380/src/components/textinput.rs#L421-L435

So there's multiple ways to handle this. We could make TextInputComponent not handle ctrl-a keybind since there are multiple shortcuts for moving the cursor to head. Or we could change the annotation keybind to something else. Which option would you prefer @extrawurst ?

[pm100]

I would do what I did with all other 'known' keystrokes that map to things that are not hugely important to tuit xtarea. Filter them out at the start, you will see a set of skipped keystrokes at the start of the key handling (on the road so I can't point to the specific line)

[MichaelAug]

Thanks @pm100, I think your filtering out code was removed in #2053 though...

[extrawurst]

@MichaelAug I had a look at #2053 again and remember what happened: the cleaner way to do it is to first react to our local gitui key events and only push down whats not handled into textarea. so I prototyped the same solution for this one: #2139

please pick it up from there:

• needs further testing
• needs to swap out the TextInput when going to annotation mode to a multiline one

[pm100]

@extrawurst I just saw that you removed the code that filtered out the keystrokes that have special meaning to gitui, but that are safe to not hand to tta

				// here all 'known' special keys for any textinput call are filtered out

				if key_match(e, self.key_config.keys.toggle_verify)
					|| key_match(e, self.key_config.keys.commit_amend)
					|| key_match(
						e,
						self.key_config.keys.open_commit_editor,
					) || key_match(
					e,
					self.key_config.keys.commit_history_next,
				) {
					return Ok(EventState::NotConsumed);
				}

This code in fact made sure that ctrl-a worked OK

[extrawurst]

@pm100 I am not sure what you mean, ctrl+a works:

[pm100]

But ctrla should NOT work. It's has a special meaning to ggitui so I filtered it out and returned as unhandled. That deleted block of code picked out all the special keystrokes that have meaning to gityi text input callers. I lacked the knowledge of who the caller was so could not conditionally filter them out. However all the filtered out strokes were for relatively obscure tta features.

I had all this explained way back in the origin nal PR ( a long time ago).

I was determined to have minimal impact, so I had no idea who the caller was. I could have filtered out in the caller, or had th caller pass a list of keys that tta should not eat. But that would have been an API change

[extrawurst]

@pm100 see the above mentioned commit: the caller filters out what the caller cares about. It is working as expected. If you want to discuss this further feel free to join the discord. This derails this conversation here