Re: Result Set Cursor Patch

Brian Olson wrote:
> This outsider/new-guy-on-the-list thinks "4 space" tabs are great. I think
> it's very portable because if a file is indented with all tabs then
> someone can set their editor to render that however they like: 2, 4, 8, e,
> Pi, etc. "spaces".

This only works if you only ever indent in strict multiples of a
tabwidth and are consistent about only ever using tabs. In practice,
this doesn't happen -- you'll get spaces appearing pretty fast. Witness
the current driver, where in theory only tabs should be being used, but
in practice there are lots of spaces used to indent. Also consider cases
like this, assuming 2-space tabs on the lefthand side:

   if (condition) { // Comment 1
     code;          // Comment 2
   }                // Comment 3

With 4 space tabs we get:

     if (condition) { // Comment 1
         code;          // Comment 2
     }                // Comment 3

Oops, those comments don't nicely line up any more. You can't fix it
using tabs to align the comments either, since the indenting you need on
a particular line depends on the line length and isn't necessarily a
multiple of the tab width.

> 4 space + 8-space-tabs is the least portable. Everyone has to configure
> their editor exactly alike.

Yes, mixing spaces and tabs makes life difficult (especially if you're
editing python code!). This is essentially the same case as the current
code (both spaces and 4-space-tabs are used, although tabs-only is
mandated).

> all spaces is portable, everyone gets the same thing, but on the down
> side, everyone gets the same thing.

This is what I prefer because it's hard to get wrong. And personally I
think that the *goal* is that everyone sees the same thing for a
particular bit of code.

And it makes 'diff' and 'less' produce more readable output, too :)

There's a pretty good summary of the issues at
http://www.jwz.org/doc/tabs-vs-spaces.html. Some conclusions from that doc:

>  My opinion is that the best way to solve the technical issues is to
> mandate that the ASCII #9 TAB character never appear in disk files:
> program your editor to expand TABs to an appropriate number of spaces
> before writing the lines to disk. That simplifies matters greatly, by
> separating the technical issues of #2 and #3 from the religious issue of
> #1.

> I just care that two people editing the same file use the same
> interpretations, and that it's possible to look at a file and know what
> interpretation of the TAB character was used, because otherwise it's
> just impossible to read.

-O