Excel.vim

by johannh • 12 years ago

143 57 12 years ago

ygra• 12 years ago

»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.

deadweight34• 12 years ago

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.

rtpg• 12 years ago

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)

izacus2• 12 years ago

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 alot of additional work to support UTF-8 if you START correctly.

pyre4• 12 years ago

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 non-English characters
  def getRealLengh(str):
      length = len(str)
      for s in str:
          if ord(s) > 256:
              length += 1
      return length

and:

          for val in shn.row_values(n):
              try: val = val.replace('\n',' ')
              except: pass
              val = isinstance(val,  basestring) and val.strip() or str(val).strip()
              line += val + ' ' * (30 - getRealLengh(val))
          vim.current.buffer.append(line)

In accounting for the fix-width layout of non-ASCII characters.

boomlinde• 12 years ago

The grandparent probably wrote the comment in his spare time, too. Does that limit your entitlement to voice criticism or suggestions? Don't like it, don't read it.

hrktb• 12 years ago

Perhaps you could take into account that emoji and other fancy characters are heavy utf8 characters. UTF support doesn't usually mean "prepare for Swahili", but more "don't choke on the characters"

jzawodn• 12 years ago

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.

ayrx• 12 years ago

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.

yzzxy• 12 years ago

Yes, this destroys all of my use cases.

krick• 12 years ago

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

hk__2• 12 years ago

Why make a Vim plugin instead of a standalone program since it’s read-only?

cowsandmilk• 12 years ago

As a Vim plugin, you get a lot of features of Vim for free (e.g. search, familiar bindings). And the code is only 56 lines. A stand-alone program would likely have less features and be much longer.

daGrevis• 12 years ago

Not everything has to be useful or even sane. Especially on _Hacker_ News.

Edit: To clarify, I think this shows what hacking is all about. Playful cleverness and curiosity.

DougBTX• 12 years ago

Most of the functionality is in the xlrd library, think of this as just a frontend.

mattxxx• 12 years ago

because.... vim!

bcj• 12 years ago

It's possible they eventually plan adding write support using xlwt.

fiatjaf• 12 years ago

I think this could be greatly useful, as also sc could have been.

deadweight34• 12 years ago

Working in a corporate world where an excel can often be how you receive bug reports, this will actually fit very well into my workflow.

bibonix• 12 years ago

I'll definitely try it... good idea

dous• 12 years ago

Thanks for sharing this. To the author, if you're reading this, thanks for putting your work up on Github.

kasbah• 12 years ago

I could actually really use a nice display of CSV and TSV files (with editing).

eggoa• 12 years ago

There's code for a decent plugin here:

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.

sheetjs5• 12 years ago

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)

zzleeper• 12 years ago

I just found out about XLSB.. if really saves me so much time / space, I might just start using it for all large spreadsheets..

sheetjs5• 12 years ago

XLSB is significantly faster to process because it does not require an XML parser to blast through the data. Numbers are stored directly as IEEE754 doubles. Text may end up larger because XLSB uses UTF16LE for everything, including pure-ASCII strings (since Excel uses that format internally, there is no conversion involved and XLSB still will be faster).

The problem you will encounter is that most programs (Numbers, Google Docs) do not support XLSB.

Shameless plug: https://github.com/SheetJS/js-xlsx supports both XLSX and XLSB (AFAICT the only liberally licensed project that handles the format)

gdiocarez• 12 years ago

Wow. How far will vim go if it can now replicate like excel?

Excel.vim

Related Stories