Excel.vim
21–30 of 65 posts
Re: Excel.vim
#22Earlier quoted context omitted.
Calling the work of someone who releases free software that they may have well hacked together in their free time downright shameful seems quite offensive and disregards the work they put into the project. Perhaps the OP had no need to use this code for non-English alphabets or is simply in the early stages and hasn't had the opportunity to fully test and implement this. Regardless, I think people should be applauded…
Hmm, I do not agree with you that the sole act of opensourcing a software should bring it above criticism. Any developer that takes a bit of pride in his work should at least keep himself to some minimal standards and I think supporting UTF-8 isn't an unreasonable baseline for software released right now.
Re: Excel.vim
#23Earlier quoted context omitted.
Calling the work of someone who releases free software that they may have well hacked together in their free time downright shameful seems quite offensive and disregards the work they put into the project. Perhaps the OP had no need to use this code for non-English alphabets or is simply in the early stages and hasn't had the opportunity to fully test and implement this. Regardless, I think people should be applauded…
Hmm, I do not agree with you that the sole act of opensourcing a software should bring it above criticism. Any developer that takes a bit of pride in his work should at least keep himself to some minimal standards and I think supporting UTF-8 isn't an unreasonable baseline for software released right now.
> A Show HN needn't be complicated or look slick. HN users are comfortable with work that's at an early stage.
> Be respectful. Anyone sharing work is making a contribution, however modest.
> When something isn't good, you needn't pretend that it is. But don't be gratuitously negative.
I'm not saying it people shouldn't be open to criticism, but I think terms such as downright shameful fall under the category of gratuitously negative.
Re: Excel.vim
#24Re: Excel.vim
#25Earlier quoted context omitted.
the thing is if you build for unicode support from the start these conversations don't need to be had. The problem is not enough people treat text as a black box from the start (I can understand unwillingness to support bigger things like RTL)
There just isn't a lot of pervasive experience in the development community for multi-language unicode devlopment. Also xlrd is fairly old, although I don't know if that tool is part of what limits this to english. In ten years it might be better.
Unicode isn't even hard: Use UTF-8. Don't try to measure the length of a string unless you're rendering that string and measuring the length in screen units like pixels. If you do those two things, that's 90% of the effort of making Unicode-safe software.
I think both views are valid. Those who don't know how to write Unicode-safe software shouldn't feel shamed into learning Unicode before releasing open source work. Those who already know Unicode should feel happy that they're making other people's lives easier.
Re: Excel.vim
#26Earlier 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?
Re: Excel.vim
#27I could actually really use a nice display of CSV and TSV files (with editing).
http://vim.wikia.com/wiki/Working_with_CSV_files
I'm not sure if it's what you're looking for, but I've found it very useful.
Re: Excel.vim
#28»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.
Re: Excel.vim
#29Why make a Vim plugin instead of a standalone program since it’s read-only?
Re: Excel.vim
#30Earlier 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's one thing to internationalize software. That's hard. But not being able to handle UTF-8 in 21st century is downright shameful. The notion of non-ASCII characters in user Excel documents IS NOT something rare even for English speaking nations. There are tons of people with foreign names, addresses and other personal information which is commonly stored in Excel documents. And the funny thing is: it's usually not…