Author Topic: SlickEdit v17 encoding issues  (Read 8994 times)

CodingMonkey

  • Junior Community Member
  • Posts: 2
  • Hero Points: 0
SlickEdit v17 encoding issues
« on: May 01, 2013, 09:59:34 AM »
Following problem:

I have a yml file, this is externally created as utf8 file.

As soon as I edit and save with slickedit, the file is broken and then breaks the web application on next restart. After some debugging I found, that I have some encoding issues, but I'm not able to fix these.

Problem 1)

I found no way to display the current encoding SlickEdit is using. Where I can display this extremely important information?

(I have tried to add a own file extension and played with the various encoding but since there seems to be no way to see what
slickedit is assuming, trial and error is not very effective).

Problem 2)

When creating a new file utf8 encoded in slickedit, there is BOM in the file. I have some tools in my workflow which unfortunate breake when they encounter such files - how do I create a utf8 file without BOM signature within slickedit?


Additional information:

I can see the problem on the shell:

bash-3.2$ file de.yml  # step1
de.yml: UTF-8 Unicode text
bash-3.2$ file de.yml  # step2
de.yml: UTF-8 Unicode text
bash-3.2$ file de.yml  # step3
de.yml: ISO-8859 text

1) file unmodified by slickedit
2) file opened with slicked changed (just delete something), saved
3) file opened with slicked changed (added german umlauts: öäü, set test_uft8), saved

On step 3 the file is broken.

I have uploaded the broken file, the web app breaks after step3 with:
I18n::InvalidLocaleData - can not load translations from /Project/develop/rails/app1/config/locales/de.yml: #<Psych::SyntaxError: (/Project/develop/rails/app1/config/locales/de.yml): invalid trailing UTF-8 octet at line 1 column 1>:

step1 and step2 do not break the app.

attachments:

I have attached 3 files:
de.yml.bad: file created by step3 (saved with slicked)
de.yml.good: file working with app (step1+step2)
de.yml.vi: file working with app but step3 done with vi

these files produce the following output with file tool:
bash-3.2$ file -i *
de.yml.bad:     text/plain; charset=iso-8859-1
de.yml.good:    text/plain; charset=us-ascii
de.yml.vi:      text/plain; charset=utf-8

(note: these files just shrinked so that they reproduce the problem, which seems to show up as soon as I edit file away from plain us ascii when doing it with slickedit).

how to fix?

Basically I want to do the edit with slickedit without breaking the file. The file should be saved as UTF8 without BOM signature (just like vi) - is this possible?

SlickEdit 2012 (v17.0.3.0)

Licensed number of users: Single user
License file: /Library/Application Support/SlickEdit/17/slickedit.lic

Build Date: November 27, 2012
Emulation: Mac OS X

OS: Mac OS X Lion
OS Version: 10.7.5
Processor Architecture: Intel(R) Core(TM) i5 CPU 760 @ 2.80GHz 64 bit (4 cores)

Memory: 73% Load, 5989MB/8192MB Virtual
Shell Info: /Applications/SlickEdit2012.app/Contents/MacOS/secsh -i
Screen Size: 2560 x 1440

Project Type: No project open
Language: .yml (Ruby)

Installation Directory: /Applications/SlickEdit2012.app/Contents/

Edit:
Your verification dialog to get something posted is extremely annoying :-(

vse_decline

  • Junior Community Member
  • Posts: 4
  • Hero Points: 0
Re: SlickEdit v17 encoding issues
« Reply #1 on: December 03, 2013, 04:46:12 AM »
hey, I just found your post when I was searching for info on encodings. I see nobody has responded, which is disappointing.

I don't know if it'll work for you, but I have a suggestion. This seems to work for me on V16. I had to do a bit of experimentation since the info on encodings in the help file are outdated and incorrect.

My use case is editing php and html files that are utf8 but should not have a BOM. This should work for your yml files too I believe.

The help mentions Auto XML, Auto EBCDIC, etc but makes no mention of Auto HTML, so I don't know what that should do exactly, but Auto HTML is default for html extension, whereas Automatic is default for htm, php and php3 extensions. I tried setting them all to Auto HTML but that did not work. Since I don't expect to edit any non-UTF8 files, I tried changing the encoding for the php extension to UTF-8. Still, it does not work. Dropping the file on SlickEdit, it opens in wrong mode (but as you know, which mode is anyone's guess).

There is a hint in the help file. It states that the mode will be remembered for each file. If you go through the File | Open dialog and explicitly select UTF-8 from the encodings, the file does open in UTF-8 mode. Close the file, then open again via drag'n'drop instead of the Open dialog. Now, finally, the file is open in UTF-8 mode and saving it does not trash the contents. I tested this on files that contain three languages that would use three different code pages (West Europe 8859-1, East Europe 8859-2, and Russian 8859-??) if it weren't for Unicode.

I hope this helps you and anyone else facing the same problem. It would be nice if SlickEdit help section on encoding was updated to document soe of the addition Auto* encodings. It would be nicer if settings the encoding in the file association manager actually worked. It seems to do jack sh!t when I change the settings there. It would also be nice if there was some option to not write the BOM when saving UTF-8 files. I added more files to this web project and had to go remove the BOM with a hex editor. For bonus surprise fun, when I do that, the file goes back to opening as ascii until I manually File | Open with UTF-8 encoding explicitly set, then SlickEdit re-remembers the encoding.


[Me: Visual SlickEdit user since v2 on OS/2, disappointed when OS/2 was dropped, unsure what market there is for HPUX version now if there was no perceived OS/2 market. Loyal SlickEdit user despite having to use it on Windows for years. Disappointed by the lack of innovation ever since the version number acceleration set in around V6 or so. I can skip a few major versions between upgrades and then see no real feature difference when I make the jump, but the basic problems I've put up with for ages are still there (2GB file limit even on 64bit builds? WTF) yet still using it because everything else is worse.]