Fix autocomplete suggestions not being announced

[yukie-nobuharu]

Fix autocomplete suggestions not being announced

Problem

Notepad++'s autocomplete suggestions were not being spoken by NVDA when arrowing through the list — NVDA announced nothing (or "blank"), even though AutocompleteList.event_selection was firing correctly on every selection change. This is a long-standing issue (referenced as far back as nvaccess/nvda#1701).

Root cause

Confirmed via diagnostic logging against a live NVDA 2026.1.1 + Notepad++ 8.9.7 session:

• chooseNVDAObjectOverlayClasses correctly matches the ListBoxX autocomplete popup and applies AutocompleteList, and event_selection fires correctly on every arrow press.
• However, the popup's list items expose no text at all through MSAA — name, value, and description are all empty.
• NVDA's display-model screen scraping (for owner-drawn controls) also comes back empty, likely because this control renders with a themed/DirectWrite path that classic GDI-hook-based scraping can't see.
• The native Win32 listbox (LB_GETTEXT/LB_GETCURSEL) also returns nothing — the control doesn't appear to track selection via standard listbox state either.

None of the three failed with an exception — they just cleanly returned no data, which matches this being a genuinely inaccessible custom-drawn control rather than a bug in how the addon reads it.

Fix

Query Scintilla itself for its currently-highlighted autocomplete text, via the documented SCI_AUTOCGETCURRENTTEXT message, using the same cross-process shared-memory technique NVDA core already uses to read this editor's document text (VirtualAllocEx/WriteProcessMemory/ReadProcessMemory via winKernel, dispatched with watchdog.cancellableSendMessage). This bypasses the popup UI entirely and asks the editor's own internal state for the answer, so it doesn't depend on how the popup happens to be rendered or exposed.

Decoding respects the document's actual codepage (SCI_GETCODEPAGE), matching the pattern already used in NVDA core's ScintillaTextInfo._get_encoding, rather than assuming UTF-8.

A plain MSAA read (name/value/description) is kept as a cheap fallback, tried if the Scintilla query returns nothing. The native-listbox (LB_GETTEXT) and display-model screen-read approaches were also tested during investigation and confirmed to return nothing on this control, so they weren't included in the final fix - SCI_AUTOCGETCURRENTTEXT has been present in Scintilla long before any Notepad++ version anyone is likely running today, so the extra complexity didn't seem justified for a benefit with no observed case.

Other changes bundled in

• AutocompleteList no longer subclasses IAccessible directly — it's now a plain mixin, which is unnecessary coupling to one specific accessibility API since NVDA's overlay-class mechanism already combines mixins with whichever underlying API class the real object uses.
• The ListBoxX ancestor match in chooseNVDAObjectOverlayClasses assumed a fixed 3-level parent chain; the real chain on current builds is 5 levels deep (ListBox -> ListBox -> ListBoxX -> ListBoxX -> #32769). Widened to walk up to 6 levels.

Testing

Manually tested against Notepad++ 8.9.7 (64-bit) with NVDA 2026.1.1 on Windows, editing a .java file, confirming autocomplete suggestions are now announced correctly when arrowing through the list. Not tested against older Notepad++/Scintilla versions or 32-bit builds — feedback welcome from anyone who can test those configurations.