Live data from Hacker News

Excel.vim

github.com

31–40 of 65 posts

Re: Excel.vim

#31
post #2

»Works best on excel files that contain English characters only.« That's a quite sad statement to make nowadays. I guess the old binary format might be worse regarding character sets, but at least the newer ones should use Unicode exclusively which makes this a very odd restriction.

[deleted]

Re: Excel.vim

#32
post #17

Earlier quoted context omitted.

> I have neither the experience, nor the inclination for internationalization of software. Taking a piece of software and making all of the UI language localized is one thing. Making sure that your program doesn't blow up if it encounters UTF-8 is another thing. Nowadays if your program chokes on UTF-8, I think it's safe to just consider it broken. In any case, looks like this is really where the issue may lie: # for…

Are UTF-8 encoded Excel documents actually common? Do they even exist? I thought Excel used CP 1252 on English Windows and the corresponding code pages on other language versions?

[deleted]

Re: Excel.vim

#33
post #2

»Works best on excel files that contain English characters only.« That's a quite sad statement to make nowadays. I guess the old binary format might be worse regarding character sets, but at least the newer ones should use Unicode exclusively which makes this a very odd restriction.

I hate this sentiment. I speak English and French and have limited amount of time to hack on software I'm giving away for free. My day job consists entirely in English. I have neither the experience, nor the inclination for internationalization of software. Don't like, don't use it. Or fork it, and add it yourself, because obviously you have more free time than I have.

Good for you for saying so! I'm always "impressed" by folks who immediately dump on FREE software that doesn't meet their exact needs.

Re: Excel.vim

#34
post #2

»Works best on excel files that contain English characters only.« That's a quite sad statement to make nowadays. I guess the old binary format might be worse regarding character sets, but at least the newer ones should use Unicode exclusively which makes this a very odd restriction.

I hate this sentiment. I speak English and French and have limited amount of time to hack on software I'm giving away for free. My day job consists entirely in English. I have neither the experience, nor the inclination for internationalization of software. Don't like, don't use it. Or fork it, and add it yourself, because obviously you have more free time than I have.

Good for you for saying so! I'm always "impressed" by folks who immediately dump on FREE software that doesn't meet their exact needs.

Re: Excel.vim

#35
post #2

»Works best on excel files that contain English characters only.« That's a quite sad statement to make nowadays. I guess the old binary format might be worse regarding character sets, but at least the newer ones should use Unicode exclusively which makes this a very odd restriction.

I hate this sentiment. I speak English and French and have limited amount of time to hack on software I'm giving away for free. My day job consists entirely in English. I have neither the experience, nor the inclination for internationalization of software. Don't like, don't use it. Or fork it, and add it yourself, because obviously you have more free time than I have.

It goes both ways. I hate developers that write some code, dump it on GitHub and say "It's open source, you can always fork it." Whatever happened to taking pride in your work and making it work the best it can?

Like other people have pointed out, handling unicode properly does not mean internationalization. Handling utf-8 isn't even difficult if you just keep it in mind.

Re: Excel.vim

#36
post #17

Earlier quoted context omitted.

> I have neither the experience, nor the inclination for internationalization of software. Taking a piece of software and making all of the UI language localized is one thing. Making sure that your program doesn't blow up if it encounters UTF-8 is another thing. Nowadays if your program chokes on UTF-8, I think it's safe to just consider it broken. In any case, looks like this is really where the issue may lie: # for…

Are UTF-8 encoded Excel documents actually common? Do they even exist? I thought Excel used CP 1252 on English Windows and the corresponding code pages on other language versions?

How would it save a document containing multiple languages, then?

Re: Excel.vim

#37

Earlier quoted context omitted.

Are UTF-8 encoded Excel documents actually common? Do they even exist? I thought Excel used CP 1252 on English Windows and the corresponding code pages on other language versions?

How would it save a document containing multiple languages, then?

Excel 97-2003 (XLS) actually uses UTF16LE in that case, not UTF8. Excel 2007+ XLSB exclusively uses UTF16LE -- there is no way to force it to use a codepage

Re: Excel.vim

#38
post #17

Earlier quoted context omitted.

> I have neither the experience, nor the inclination for internationalization of software. Taking a piece of software and making all of the UI language localized is one thing. Making sure that your program doesn't blow up if it encounters UTF-8 is another thing. Nowadays if your program chokes on UTF-8, I think it's safe to just consider it broken. In any case, looks like this is really where the issue may lie: # for…

Are UTF-8 encoded Excel documents actually common? Do they even exist? I thought Excel used CP 1252 on English Windows and the corresponding code pages on other language versions?

There are two types of formats generally recognized as XLS: Excel 5.0/95 "BIFF5" and Excel 97-2003 "BIFF8". The former uses a language-specific codepage like 1252 and the latter can use a language-specific codepage or the more general 1200 (UTF16LE).

Here is the master list of codepages used by Excel: https://github.com/SheetJS/js-codepage/blob/master/excel.csv (disclaimer: I built this as part of the in-browser XLS parser https://github.com/SheetJS/js-xls)

Re: Excel.vim

#39
If the author is reading this:

> For vim 7.3 and less, it works well for almost all kinds of file formats,

> ie. .xls,.xlam,.xla,.xlsb,.xlsx,.xlsm,.xltx,.xltm,.xlt etc

Someone already pointed it out (https://github.com/yakiang/excel.vim/issues/5) on github: xlrd does not support the XLSB format (and the xlrd authors expressed no interest in building it)

Re: Excel.vim

#40
post #35

Earlier quoted context omitted.

I hate this sentiment. I speak English and French and have limited amount of time to hack on software I'm giving away for free. My day job consists entirely in English. I have neither the experience, nor the inclination for internationalization of software. Don't like, don't use it. Or fork it, and add it yourself, because obviously you have more free time than I have.

It goes both ways. I hate developers that write some code, dump it on GitHub and say "It's open source, you can always fork it." Whatever happened to taking pride in your work and making it work the best it can? Like other people have pointed out, handling unicode properly does not mean internationalization. Handling utf-8 isn't even difficult if you just keep it in mind.

I do take pride in my work, and every piece of software I write handles every use case I need it for explicitly. I take offense that you would imply otherwise knowing absolutely nothing of me and my craft. This isn't about UTF-8, it's about an illogical premise where some very shortsighted individuals would rather have only fully fleshed, fully baked products in open source. This is highly illogical, and would bury ideas potentially unexposed for others to coach and assist with. You aren't the judge of what others find difficult, but that doesn't mean that those that struggle with a concept cannot add tremendous value in other areas.

By the way, it's not utf-8, it's UTF-8. Whatever happened to taking pride in your writing and making it the best it can be?

Everyone has their own criteria for quality, and you can't hope to satisfy everyone. Everyone with even a mildly successful project in open source knows this. Scratch your own itch, make it work, accept any request that meets with your vision, and keep a permissive licence so those that don't can fork. Otherwise, the arrogance being asserted, that you can somehow determine if my contribution is worth of existing, is baffling.

Post reply on HN