Comment width not properly calculated if it contains non-ASCII chars and clickable addresses

[bb33bb]

Version and Platform (required):

• Binary Ninja Version: 4.2.6152-dev Personal (3ee2364e)
• OS: manjaro
• OS Version: Linux version 6.9.12-3-MANJARO (builduser@fv-az772-99) (gcc (GCC) 14.2.1 20240805, GNU ld (GNU Binutils) 2.43.0) use Caches folder on OS X for download cache to prevent backups #1 SMP PREEMPT_DYNAMIC Wed Aug 7 16:19:28 UTC 2024
• CPU Architecture: x64

Bug Description:

Steps To Reproduce:

https://1drv.ms/u/s!Am5q_FKmGOABgUXzcnl8S8jWVL3t?e=xYeQvo

[xusheng6]

This is a new form of #1234. I checked and it seems we only fixed the specific issue with the width of a tab, and the general issue remains unsolved.

[BlasterXiao]

what time will this problem be resolved? @xusheng6 i need this function!

[xusheng6]

I looked a bit further into this, so it seems the fix #1234 works in the general case, but this is only happening when a clickable address shows up in the comment. If it is just a number, like 100003ee4, it works fine. The bug only happens when the text is like 0x100003ee4, where we did some special processing to get the number displayed as a clickable token

I cannot guarantee a timeline for this issue, but I will try to have a look at it in the next milestone. For now maybe consider a workaround like avoiding the "0x" prefix or use English in the comment

[BlasterXiao]

Another point affected by this issue is English and Chinese comments. For example, English comments don't have any problems, but switching to Chinese comments will cause overflow and related issues. @xusheng6