slickedit converting an ascii into unicode and screwing up

[Stu]

In a c file, if I type fi slickedit converts it into unicode character then shows a space after it and suddenly your editing one character to the left of where you really are. very odd. I can type f and its all good, then follow it with an i and bam! does not matter where I am in the C file when I do this.

I initially noticed this in the middle of a function name I had a space, thought the beautifier was going crazy and I tried to delete the space and was deleting character to the left of where the caret was... then I noticed the fi character was a single character. odd.

Anyone else experience this? I'm on linux64/ubuntu.

some more digging, it seems the file is loaded as sbcs/dbcs with the "mensch" font, changing the font to consolas seems to fix it, (typeing fi does not convert it to unicode). does not explain why slickedit it doing some kind of conversion for foreign characters.

more digging.. under 1603 it loads the same file as unicode and uses the unicode font for all my C files, now under 1700 it loads all my files as sbcs/dbcs...

[patrick]

What language is your system set up for?  I haven't reproduced this yet, but I do see in the Qt docs that for some languages, it can automatically compose some characters into ligatures, which we should not be doing for SBCS.

[Stu]

My machines language is us english. In SE, load files its set to UTF8, and language extensions set all to UTF8 as well.

Its odd, it seems to be font specific. ie: If I se the sbcs/dbcs font to consolas, no problem. If I set it to mensch, I get the 'fi' conversion and odd extra space behaviour. I will test tonight some other fonts and see if I get the same results.

[patrick]

Odd, I'll recheck and make sure I was using Mensch for all of the tests I was doing.  I'm currently running under Ubuntu 12.04, KDE plasma.  I'll switch to Unity later to see if that makes a difference, though I'm not expecting it to.

[patrick]

Also, can you reproduce it in a small file, and send the file to me?  Just want to double check what characters are actually being put in the file.  We had a font rendering problem in the past that could do something similar to what you're describing, so my initial ideas may be wrong.

[Stu]

set mensch font as sbcs/dbcs font.
File->New
Document mode = Automatic
path = /tmp
file = test.c
encoding = binary sbcs/dbcs mode

type "file"

appears to have 'fi' as a single character. save to disk, look with hex editor, its plain ascii. close + reopen in slickedit, it shows 'fi' as one character.

close file, open explicitly telling it as 'utf-8', fi looks correct as two characters.
close file, open explicitly as 'text sbcs/dbcs' and fi is now one character.

if you open as dos latin 1 or us, western 8859, it just crashes to desktop.

I went through all the fixed sized fonts it listed and only mensch showed this problem. maybe some kind of autohinting is embedded in the font.
using consolas as my sbcs/dbcs font, opening it as 'text sbcs/dbcs' will show file correctly (other file encodings will still cause a crash to desktop)

[Clark]

Sorry, using the encoding in the unix open dialog will crash depending on what you choose. It's an unrelated problem. This will be fixed in the first point release (~early July).

[patrick]

Thanks for the in depth description, that's just the information I was looking for.

I have not gotten this to reproduce yet on my systems, but I've still got things left to try.  The more I look into to it, the odder it seems: ligatures aren't something I'd expect in a monospace font.

Paranoia check: this is the Mensch font from http://robey.lag.net/2010/06/21/mensch-font.html that has the large angle brackets, correct? 

And one other check - could you send me the output of "ldd /opt/slickedit/bin/vs".  That would close down one set of possibilities for me.

[Stu]

i put my copy of mensh up, it did not match a binary diff on the page you listed;

http://bloodycactus.com/~sgeorge/mensch.ttf

Code: [Select]

[ sgeorge @ cactus ] - [ ~ ] 
[$]> ldd /opt/se1700/bin/vs
linux-vdso.so.1 =>  (0x00007fff6e3d1000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1f2f0c2000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1f2eebe000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f1f2ecba000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f1f2eab2000)
libXt.so.6 => /usr/lib/x86_64-linux-gnu/libXt.so.6 (0x00007f1f2e84c000)
libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007f1f2e643000)
libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007f1f2e428000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f1f2e0ee000)
libQtGui.so.4 => /opt/se1700/bin/libQtGui.so.4 (0x00007f1f2d376000)
libQtCore.so.4 => /opt/se1700/bin/libQtCore.so.4 (0x00007f1f2ce98000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1f2cc13000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1f2c87d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1f2f31c000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f1f2c678000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f1f2c45b000)
libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007f1f2c256000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f1f2bf67000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1f2bd4e000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f1f2bab5000)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f1f2b8aa000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f1f2b673000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f1f2b461000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1f2b15b000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1f2af44000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f1f2ad41000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f1f2ab3a000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f1f2a8fe000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f1f2a6d3000)
[ sgeorge @ cactus ] - [ ~ ] 
[$]>


[patrick]

Definitely seeing it with your copy of the font.  Looking into it.

[Stu]

Glad your seeing it. It seems to be font specifc and very random because I never use that font at all, and I have no idea why SE loaded the file it did as sbcs/dbcs.

I guess a whole host of weird things came together at the same time.

crap. I shoulda bought a lottery ticket!