Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Excel.vim

github.com

Post reply on HN
Print view View original

51–60 of 65 posts

Re: Excel.vim

#51

Post by dkersten »

deadweight3 wrote: post #40
ayrx wrote: post #35

Earlier quoted context omitted.

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 i…

I agree with you. Anything else just reeks of over-entitlement. I mean, if someone spends their free time to make something useful, that's great! If it doesn't quite meet your standards, that's your problem and you can either: fork it or send a pull request (ie fix it yourself), or pay someone (original author or someone else) to do it.

I'd rather people who build stuff for themselves release it to the rest of us than keep it to themselves.

Re: Excel.vim

#52

Post by pyre »

deadweight3 wrote: post #41
pyre wrote: 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…

Interesting definition of broken. It seems to work perfectly for me and the creator.

> Interesting definition of broken.

Consider this: A medical device that people's lives depend on. It only fails in 1/1000 cases causing death. Many people could state, "it works for me, can't be broken!" On the other hand, the families of the dead could argue that it is broken. Who is right?

Obviously this isn't such an extreme case. No one has their life depending on a Vim plugin, but it illustrates a point. "Works for me" doesn't necessarily imply "isn't broken."

Re: Excel.vim

#53

Post by Matumio »

deadweight3 wrote: post #40
ayrx wrote: post #35

Earlier quoted context omitted.

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 i…

You are just being baited. I agree with what you say, but did you really want to burn your energy in this discussion?

Re: Excel.vim

#54

Post by burkaman »

pyre wrote: post #52
deadweight3 wrote: post #41

Earlier quoted context omitted.

Interesting definition of broken. It seems to work perfectly for me and the creator.

> Interesting definition of broken. Consider this: A medical device that people's lives depend on. It only fails in 1/1000 cases causing death. Many people could state, "it works for me, can't be broken!" On the other hand, the families of the dead could argue that it is broken. Who is right? Obviously this isn't such an extreme case. No one has their life depending on a Vim plugin, but it illustrates a point. "Works…

I think the point is that for many people building free software for fun, "works for me" is all that matters. Testing use cases that you know you will never encounter is not interesting or challenging (at least in this case), but it takes time, and you're not making a product, nobody is relying on you. Why bother?

The author of this plugin isn't trying to make a spreadsheet competitor, they just released it publicly because other people might find it useful or interesting.

Re: Excel.vim

#56

Post by krick »

ygra wrote: 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.

Totally agree. UTF-8 is all over the world, yet we are living like in ASCII-only 90s. But since it's vim I'm not really surprised, it might be actually tricky to make something work there (however I don't know what really is the problem).

Re: Excel.vim

#57

Post by asavadatti »

pyre wrote: post #52
deadweight3 wrote: post #41

Earlier quoted context omitted.

Interesting definition of broken. It seems to work perfectly for me and the creator.

> Interesting definition of broken. Consider this: A medical device that people's lives depend on. It only fails in 1/1000 cases causing death. Many people could state, "it works for me, can't be broken!" On the other hand, the families of the dead could argue that it is broken. Who is right? Obviously this isn't such an extreme case. No one has their life depending on a Vim plugin, but it illustrates a point. "Works…

This is an imperfect analogy. The medical device is not being given away for free.

Re: Excel.vim

#58

Post by thristian »

tracker1 wrote: post #44
rtpg wrote: post #10

Earlier 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)

Okay... let's go into this... how are the strings in excel encoded anyway? I'd be willing to bet money that at least some of the formats in question aren't UTF-8, they are likely ASCII encoded against a character set or code page. Then you have to read that codepage, and convert the necessary characters to their Unicode equivalents, and from there do you downcode to utf-8? Does the language this library is written in…

> Does the language this library is written in support that translation? Are there modules to do that? Is the license for those module(s) necessary compatible?

It's written in Python, which comes with support for pretty much every major encoding¹ out of the box, so yes.

¹: https://hg.python.org/cpython/file/cb94764bf8be/Lib/encoding...

Re: Excel.vim

#59

Post by Eyas »

asavadatti wrote: post #57
pyre wrote: post #52

Earlier quoted context omitted.

> Interesting definition of broken. Consider this: A medical device that people's lives depend on. It only fails in 1/1000 cases causing death. Many people could state, "it works for me, can't be broken!" On the other hand, the families of the dead could argue that it is broken. Who is right? Obviously this isn't such an extreme case. No one has their life depending on a Vim plugin, but it illustrates a point. "Works…

This is an imperfect analogy. The medical device is not being given away for free.

The analogy very well might be imperfect. It doesn't seem like this particular distinction is all too valid though.

Re: Excel.vim

#60

Post by [deleted] »

thristian wrote: post #58
tracker1 wrote: post #44

Earlier quoted context omitted.

Okay... let's go into this... how are the strings in excel encoded anyway? I'd be willing to bet money that at least some of the formats in question aren't UTF-8, they are likely ASCII encoded against a character set or code page. Then you have to read that codepage, and convert the necessary characters to their Unicode equivalents, and from there do you downcode to utf-8? Does the language this library is written in…

> Does the language this library is written in support that translation? Are there modules to do that? Is the license for those module(s) necessary compatible? It's written in Python, which comes with support for pretty much every major encoding¹ out of the box, so yes. ¹: https://hg.python.org/cpython/file/cb94764bf8be/Lib/encoding...

[deleted]
Post reply on HN