研判一下針對 QQNT 的組字區問題的對策

[ShikiSuen]

用 Electron 寫的東西就是容易出這種故障，很令人頭痛。
在將 QQNT 塞入預設的客體管理名單之前，看看還能針對 QQ 做些什麼。

更新：騰訊 QQNT 團隊已於「6.9.9-editorTest (9497)」測試版當中修正該故障。
至於該修正何時會被推送到 Mac App Store 正式發行版，則屬於他們公司的未決內務，就先不關心了。

[ShikiSuen]

故障一：在就地標記加詞/刪詞/控頻的時候，標記選區內的內容會有被錯誤遞交出去的情況。

這裡應該是還沒觸發 commitComposition()，不然 inputHandler 必然會被清空。

Shift+Enter 這個絕對組合鍵訊號在 inputHandler.handle() 當中的處理流程並沒有問題。

同時測試發現雅虎奇摩注音與小麥注音輸入法也受此影響。

正式報告見樓下。

故障二：田所選字窗偶爾會不顯示。

正在調查中。得搞清楚是選字窗沒顯示、還是被 QQNT 遮住了。
IMK 選字窗似乎不受影響。

[ShikiSuen]

以下是给腾讯的工程师看的故障报告文（有订正）：

受影响的 QQNT 版本：6.9.6 (36220)

macQQ NT 的消息输入框对内文组字区的文字内容的（客观上的）插入行为的自动触发时机似乎不对劲。

该问题至少引起了几乎业界所有「依赖 Shift+前后方向键 来就地加词」的输入法在 macQQ NT 目前的版本当中的异常行为。包括但不限于下述输入法：

• 威注音输入法 https://vchewing.github.io/
• 雅虎奇摩输入法 https://github.com/zonble/ykk_installer

比如下面这个讯息：

https://www.baidu.com/
张三丰没有签过这种协议。

整个复制粘贴到 QQNT 的讯息框内，然后删掉第二行再重新敲。
敲一些内容之后，你就开始用「Shift+前后方向键」选范围。
此时输入法会有工具提示的变化：

就是在这个变化的过程当中，输入法会用 client().setMarkedText() 更新内文组字区内的游标位置（乃至对每个字词节点做下划线）。但这就会触发「组字区内有游标前后端的文字被提前重复递交出去」这个故障：

目前已知只有 QQNT 有这个故障。由于问题出在 client() 上面，所以输入法开发者对这个故障是无能为力的，只能由 QQNT 开发团队解决。

P.S.: 上文的范例讯息，如果是自己亲自一个字符一个字符敲进去的话（且没动过 CMD+C/V/X 剪贴簿热键），则不会引起该故障。

在该问题解决之前，我这边先给威注音输入法推 3.3.2 更新，将 QQ 列入客体应用黑名单，直至该故障被 QQNT 团队解除。
针对列入黑名单的客体应用，威注音输入法会以浮动组字窗取代内文组字区，且组字区内可以暂存的字音配对数量有上限。

---

二月十五日（2003）调查进度更新（见下面的回帖）

[ShikiSuen]

二月十五日（2003）调查进度更新

问题触发契机是 client().setMarkedText() 被喂食了相同的文字内容、且前后喂食过的内容的 NSAttributeString 彼此的下划线设定出现了「粗细下划线不等」的差异。

vChewing-macOS/Source/Modules/IMEStateData.swift

Lines 115 to 166 in 75a1540

	public var attributedStringNormal: NSAttributedString {
	/// 考慮到因為滑鼠點擊等其它行為導致的組字區內容遞交情況，
	/// 這裡對組字區內容也加上康熙字轉換或者 JIS 漢字轉換處理。
	let attributedString = NSMutableAttributedString(string: displayedTextConverted)
	var newBegin = 0
	for (i, neta) in displayTextSegments.enumerated() {
	attributedString.setAttributes(
	[
	/// 不能用 .thick，否則會看不到游標。
	.underlineStyle: NSUnderlineStyle.single.rawValue,
	.markedClauseSegment: i,
	], range: NSRange(location: newBegin, length: neta.utf16.count)
	)
	newBegin += neta.utf16.count
	}
	return attributedString
	}
	public var attributedStringMarking: NSAttributedString {
	/// 考慮到因為滑鼠點擊等其它行為導致的組字區內容遞交情況，
	/// 這裡對組字區內容也加上康熙字轉換或者 JIS 漢字轉換處理。
	let attributedString = NSMutableAttributedString(string: displayedTextConverted)
	let end = u16MarkedRange.upperBound
	attributedString.setAttributes(
	[
	.underlineStyle: NSUnderlineStyle.single.rawValue,
	.markedClauseSegment: 0,
	], range: NSRange(location: 0, length: u16MarkedRange.lowerBound)
	)
	attributedString.setAttributes(
	[
	.underlineStyle: NSUnderlineStyle.thick.rawValue,
	.markedClauseSegment: 1,
	],
	range: NSRange(
	location: u16MarkedRange.lowerBound,
	length: u16MarkedRange.upperBound - u16MarkedRange.lowerBound
	)
	)
	attributedString.setAttributes(
	[
	.underlineStyle: NSUnderlineStyle.single.rawValue,
	.markedClauseSegment: 2,
	],
	range: NSRange(
	location: end,
	length: displayedTextConverted.utf16.count - end
	)
	)
	return attributedString
	}

一般的客体软件作为 client() 而言的 .setMarkedText() 不会有这种故障，但 QQ 有。我尝试让输入法的 marking 状态弃用了下划线的粗细差异（特别是 .thick 特性），结果故障消失。

于是得等他们工程师继续检查下去了。如果他们实在解决不了的话，那么威注音这边就得在这里针对 QQ 做特殊处理、使用特制的 Marking State AttributedString，牺牲一下这里的「能更容易看清当前的高亮加词标记范围」的体验。

[ShikiSuen]

更新：騰訊 QQNT 團隊已於「6.9.9-editorTest (9497)」測試版當中修正該故障。
至於該修正何時會被推送到 Mac App Store 正式發行版，則屬於他們公司的未決內務，就先不關心了。

[kuuroro]

正式版本预计3月份版本解决该问题

[ShikiSuen]

@kuuroro 感謝您的知會。