Debounce jump-to-end against append-induced focus perturbation
The tostring() comparison fix wasn't sufficient - jump-to-end was still firing on nearly every incoming line while jump-to-end-on-focus was on. AppendToNotepad's own SetSel/ReplaceSel appears to momentarily perturb GetFocus() around each append, which poll_output_focus was reading as a genuine "just switched to the window" edge. Now skips the jump if a SmartAppendToNotepad call happened within the last 0.5s.
This commit is contained in:
@@ -407,7 +407,11 @@ end
|
||||
-- Note: text should use "\r\n" line endings, not bare "\n" - the plain
|
||||
-- Win32 Edit control that backs the notepad doesn't recognise bare "\n"
|
||||
-- as a line break for scrolling/line-count purposes.
|
||||
last_append_clock = 0
|
||||
|
||||
function SmartAppendToNotepad(title, text)
|
||||
last_append_clock = os.clock()
|
||||
|
||||
local edit = find_notepad_edit(title)
|
||||
local was_at_end = true
|
||||
local sel_start, sel_end, first_visible
|
||||
@@ -474,7 +478,14 @@ function poll_output_focus()
|
||||
-- fell back to identity comparison), causing spurious "just gained
|
||||
-- focus" edges and repeated jump-to-end even while focus never moved.
|
||||
local is_focused = (tostring(focused) == tostring(edit))
|
||||
if is_focused and not was_output_focused then
|
||||
-- Skip the jump if a SmartAppendToNotepad call happened very recently:
|
||||
-- AppendToNotepad's own SetSel/ReplaceSel appears to momentarily
|
||||
-- perturb GetFocus() around each append, which was making this poll
|
||||
-- see a spurious "just gained focus" edge - and jump to the end - on
|
||||
-- practically every incoming line, even though the user never left
|
||||
-- the window.
|
||||
local recent_append = (os.clock() - last_append_clock) < 0.5
|
||||
if is_focused and not was_output_focused and not recent_append then
|
||||
jump_notepad_to_end(edit)
|
||||
end
|
||||
was_output_focused = is_focused
|
||||
|
||||
Reference in New Issue
Block a user