SciTE vs. Textadept 12 keyboard event handling about textadept HOT 4 CLOSED

from textadept.

Thanks for the very quick response :) . In SciTE I am using also a double/triple keypress of Ctrl key and need the release event in order to refrain from coping with timing and side-effects which are unavoidable in case of not being able to track key releases. I suppose that it should be relatively easy to modify the Textadept code to be aware of key releases like SciTE is. It probably needs only one or two lines somewhere to register for key release events with GTK ... is it that simple I suppose it to be? I am ready to cope with C-code if necessary ... Or are any good reasons why key releases are not exposed I am not aware of? By the way: what do you mean with "you'd connect with an index of 1"? And why do is see two calls of the handler function for each single keypress in case of control keys or control+anotherKey presses?

from textadept.

local scc = _SCINTILLA.constants
local sccShift, sccCtrl, sccAlt, sccMeta = scc.MOD_SHIFT, scc.MOD_CTRL, scc.MOD_ALT, scc.MOD_META
local LCtrl=65507 local RCtrl=65508 local otherKeyBefore=1
events.connect(events.KEY, 
	function(keycode, mods) local shift, ctrl, alt, meta = mods&sccShift>0, mods&sccCtrl>0, mods&sccAlt>0,mods&sccMeta>0
	       print(keycode, otherKeyBefore,"|",shift,ctrl,alt,meta)
		if otherKeyBefore and ctrl and (keycode==LCtrl or keycode==RCtrl) then 
				otherKeyBefore=nil  print("Double CTRL detected!") 
								-- nil because  0  is  true  in Lua
		else 	otherKeyBefore=1 end end)

does the job, but ... Cursor keys are not detected ... AND ... because of the double call of the callback function in case of a single keypress of Ctrl it is necessary to suppress the second detection of double CTRL on the second function call.

from textadept.

After some further considerations it seems that for my use-case lifting the restriction: "Textadept does not emit key release events." at cost of responsiveness of the interface is not worth the effort ... What is annoying and should probably be fixed is the double call of the event handler in case of pressing control keys, but to address exactly this issue opening another issue is sure a better way to go, so I am closing this issue here. The not documented events.KEY was the missing piece I needed to achieve the desired functionality.

from textadept.