Tk 文本小部件索引表达式和 Unicode [英] Tk text widget index expressions and Unicode

问题描述

(这个问题基于那个)

让我们考虑以下代码:

package require Tk 8.6

pack [text .t]
.t insert end "abcdefgh\nабвгґдеє\n一伊依医咿噫欹泆"

puts "[.t index 1.4+1l] [.t index 1.4+2l]"
puts "[.t index 3.4-1l] [.t index 3.4-2l]"

exit 0

输出:

2.2 3.2
2.6 1.8

如果行足够长，我宁愿希望 +1l 和 -1l 保留该列，即打印 2.4 3.4 和 2.4 1.4.看起来结果取决于编码每个字符所需的字节数.

I would rather expect +1l and -1l to preserve the column if the line is long enough, that is, to print 2.4 3.4 and 2.4 1.4. It looks like the result depends on the number of bytes needed to encode each character.

应该这样吗?它在某处有记录吗?

Should it be this way? Is it documented somewhere?

推荐答案

你使用什么字体?您使用的 Tk 的确切补丁版本是什么?(应该通过做puts [package require Tk]来报告.)

What font are you using? What exact patch-version of Tk are you using? (It should be reported by doing puts [package require Tk].)

我认为在按行进行索引移动时，在计算实际动作时，文本小部件当前使用字符宽度.这在过去的版本之间发生了变化.问题在于不同的代码位需要不同的东西:有时您想要可见的运动(例如，在处理用户的光标运动时，特别是 设置了制表符)，有时您想要字符空间运动(这是你似乎在期待什么).

I think the text widget currently uses character widths when working out the actual motions when doing index movement by lines. This has changed between past versions. The problem is that different bits of code want different things: sometimes you want visible motions (e.g., when handling users' cursor motion, especially with tabs set) and sometimes you want character-space motions (which is what you appear to be expecting).

Tk 不应该对 unicode 字符的字节宽度做任何事情(你可以看到).它真的应该透明地处理这个问题(至少对于基本多语言平面中的任何角色；你可能会发现除此之外的错误).

Tk shouldn't ever be doing anything (you can see) with the byte widths of unicode characters. It's really supposed to handle that transparently (at least for any character in the Basic Multilingual Plane; you might find bugs outside that).

这篇关于Tk 文本小部件索引表达式和 Unicode的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！