About column numbers

About column numbers

[Angelo Graziosi]

When the option about column numbers is enabled, the column numbers 
start from "0" (zero). In other words, when the cursor in in the 
top-left corner of the buffer, the mode line displays

   (1,0)

line number   : 1
column number : 0

Why columns start from 0 (zero) and not 1 as for lines? Would it be 
better (1,1)?

Is there some settings to change this behavior? If not, I would suggest 
to change this in Emacs.. or to add some settings to change this..

  Angelo

Re: About column numbers

[psachin]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

Digging goes back to file src/indent.c. Function: current-column

On Wed, Mar 30, 2016 at 4:03 AM, Angelo Graziosi <angelo.graziosi@alice.it>
wrote:

> When the option about column numbers is enabled, the column numbers start
> from "0" (zero). In other words, when the cursor in in the top-left corner
> of the buffer, the mode line displays
>
>   (1,0)
>
> line number   : 1
> column number : 0
>
> Why columns start from 0 (zero) and not 1 as for lines? Would it be better
> (1,1)?
>
> Is there some settings to change this behavior? If not, I would suggest to
> change this in Emacs.. or to add some settings to change this..
>
>  Angelo
>
>


-- 
Sachin
psachin.github.io

[-- Attachment #2: Type: text/html, Size: 1327 bytes --]

Re: About column numbers

[Eli Zaretskii]

> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Date: Wed, 30 Mar 2016 00:33:31 +0200
> 
> When the option about column numbers is enabled, the column numbers 
> start from "0" (zero). In other words, when the cursor in in the 
> top-left corner of the buffer, the mode line displays
> 
>    (1,0)
> 
> line number   : 1
> column number : 0
> 
> Why columns start from 0 (zero) and not 1 as for lines? Would it be 
> better (1,1)?

Why is it a problem for column number to start at zero?  Emacs always
worked like that.

> Is there some settings to change this behavior?

No.  You could, of course, come up with a mode-line format that would
display column-number + 1, but that would only change this on display,
not internally.

> If not, I would suggest to change this in Emacs.. or to add some
> settings to change this..

Then you'd need to change every interface that accepts or returns
column numbers, like move-to-column, posn-at-point, etc.  Is it really
worth it?

Re: About column numbers

[Angelo Graziosi]

Il 30/03/2016 17:21, Eli Zaretskii ha scritto:
>> From: Angelo Graziosi <angelo.graziosi@alice.it>
>> Date: Wed, 30 Mar 2016 00:33:31 +0200
>>
>> When the option about column numbers is enabled, the column numbers
>> start from "0" (zero). In other words, when the cursor in in the
>> top-left corner of the buffer, the mode line displays
>>
>>     (1,0)
>>
>> line number   : 1
>> column number : 0
>>
>> Why columns start from 0 (zero) and not 1 as for lines? Would it be
>> better (1,1)?
>
> Why is it a problem for column number to start at zero?  Emacs always
> worked like that.

Yes, I know.. this is not a fundamental, but why that "unnatural" 
convention? I don't know other editor/IDE which uses columns from zero..


>> If not, I would suggest to change this in Emacs.. or to add some
>> settings to change this..
>
> Then you'd need to change every interface that accepts or returns
> column numbers, like move-to-column, posn-at-point, etc.  Is it really
> worth it?
>

what a pity! It would be an opportunity to modernize a bit Emacs...

Anyway it was just a suggestion...

   Angelo

RE: About column numbers

[Drew Adams]

> > Why is it a problem for column number to start at zero?  Emacs always
> > worked like that.
> 
> Yes, I know.. this is not a fundamental, but why that "unnatural"
> convention? I don't know other editor/IDE which uses columns from zero..

We should start with column 42. ;-)

> >> If not, I would suggest to change this in Emacs.. or to add some
> >> settings to change this..
> >
> > Then you'd need to change every interface that accepts or returns
> > column numbers, like move-to-column, posn-at-point, etc.  Is it really
> > worth it?
> >
> 
> what a pity! It would be an opportunity to modernize a bit Emacs...

Modernize schmodernize. ;-)  Every new idea is not
necessarily a great idea.  And every recently expressed
idea is not necessarily new.

Re: About column numbers

[Yuri Khan]

On Wed, Mar 30, 2016 at 11:28 PM, Angelo Graziosi
<angelo.graziosi@alice.it> wrote:

> Yes, I know.. this is not a fundamental, but why that "unnatural"
> convention? I don't know other editor/IDE which uses columns from zero..

Vim counts columns from 1.
Midnight Commander counts from 0.
Mousepad counts from 0.
Nano counts from 1.
Joe counts from 1.
Gedit counts from 1.
Kate counts from 1.
Geany counts from 0.
Anjuta counts from 0.
Firefox’s Scratchpad counts from 1.

Counting columns from 0 is very convenient. You look at the column
number and immediately know how many characters you have before the
point, and whether you are on a tab stop.

Lines are a different beast — you have to be compatible with the
convention compilers use to report errors, and pretty much all of them
count lines from 1.

Re: About column numbers

[Andreas Schwab]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> Lines are a different beast — you have to be compatible with the
> convention compilers use to report errors, and pretty much all of them
> count lines from 1.

They also count columns from 1.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: About column numbers

[Yuri Khan]

On Thu, Mar 31, 2016 at 12:18 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:

>> Lines are a different beast — you have to be compatible with the
>> convention compilers use to report errors, and pretty much all of them
>> count lines from 1.
>
> They also count columns from 1.

At least GCC doesn’t. It counts bytes. Perhaps that’s a bug.

$ cat test1.c
/*я*/foo

$ gcc test1.c
test1.c:1:7: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
at end of input
 /*я*/foo
       ^

Re: About column numbers

[Andreas Schwab]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> On Thu, Mar 31, 2016 at 12:18 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>
>>> Lines are a different beast — you have to be compatible with the
>>> convention compilers use to report errors, and pretty much all of them
>>> count lines from 1.
>>
>> They also count columns from 1.
>
> At least GCC doesn’t. It counts bytes.

It does.  Starting from 1.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: About column numbers

[Yuri Khan]

On Thu, Mar 31, 2016 at 12:56 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:

>>> They also count columns from 1.
>>
>> At least GCC doesn’t. It counts bytes.
>
> It does.  Starting from 1.

So it’s mostly useless in a 0-based character-counting editor, and
slightly less useless in a 1-based character-counting editor, and much
more useless in a cell-counting editor if you happen to use tabs. All
in all, there is much more agreement about line numbers than column
numbers, which makes it possible for each editor/IDE to choose, or
even let users choose.

Re: About column numbers

[Stefan Monnier]

> So it’s mostly useless in a 0-based character-counting editor, and

Not exactly.  It just means that we can use the number without some
extra massaging, such as taking into account compilation-first-column or
compilation-error-screen-columns (AFAIK there is currently no
corresponding support for distinguishing bytes/chars, even though it'd
be clearly beneficial).

But in any case this part of compile.el is a big mess, because every
tool out there uses another convention in this regard and
compilation-error-regexp-alist doesn't record which tool uses
which convention.


        Stefan


PS: If you like to bikeshed about counting from 0-vs-1, I have another
one for you: point-min should start at 0 rather than at 1.  And this one
could mostly be done without breaking too much code out there (it would
break some code, but most of it is already fundamentally broken because
it should use `point-min` rather than hardcoding 1, so it's not *that*
terrible).  This aid, if you try to set BEG to 0, you'll soon discover
that Emacs's C code is not prepared for that.  Patches welcome ;-)
BTW: Making such a change would slightly simplify the src/intervals.c code
since text-properties are used both on strings (start at 0) and buffers
(start at 1).

Re: About column numbers

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 693 bytes --]

On 03/31/2016 02:50 PM, Stefan Monnier wrote:
> (it would break some code, but most of it is already fundamentally
> broken because it should use `point-min` rather than hardcoding 1, so
> it's not *that* terrible).

Amusingly, always using (point-min) also leads to interesting bugs. For example, Proof General uses one large overlay to indicate which part of a buffer has been processed. When updated, that overlay is set to cover (point-min) to (end of last processed statement). Of course, when narrowing is in effect, this means that the overlay is made to start at the lowest narrowed point; then when the buffer is widened, you realize that the bounds of the overlay are wrong.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: About column numbers

[Stefan Monnier]

>> (it would break some code, but most of it is already fundamentally
>> broken because it should use `point-min` rather than hardcoding 1, so
>> it's not *that* terrible).
> Amusingly, always using (point-min) also leads to interesting bugs.

Oh yes.  Along with the "hard narrowing" discussion, it would be good to
have a way to get the "external point-min".  Currently the only portable
way (short of hardcoding 1) is via (save-restriction (widen)
(point-min)) which is rather round-about and inefficient.


        Stefan

Re: About column numbers

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

On 1 April 2016 at 05:39, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> >> (it would break some code, but most of it is already fundamentally
> >> broken because it should use `point-min` rather than hardcoding 1, so
> >> it's not *that* terrible).
> > Amusingly, always using (point-min) also leads to interesting bugs.
>
> Oh yes.  Along with the "hard narrowing" discussion, it would be good to
> have a way to get the "external point-min".  Currently the only portable
> way (short of hardcoding 1) is via (save-restriction (widen)
> (point-min)) which is rather round-about and inefficient.


I have done this on occasions. Are there any cases where the save/widen
dance actually gives a result which is not 1?

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 1179 bytes --]

Re: About column numbers

[Stefan Monnier]

> I have done this on occasions. Are there any cases where the save/widen
> dance actually gives a result which is not 1?

On my local Emacs it never returns 1, and on an Emacs with the
hard-narrowing patch it can also return something else, but AFAIK it
will always result in a value of 1 in any actually released version of
Emacs.


        Stefan

Re: About column numbers

[John Wiegley]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

>> what a pity! It would be an opportunity to modernize a bit Emacs...

> Modernize schmodernize. ;-) Every new idea is not necessarily a great idea.
> And every recently expressed idea is not necessarily new.

I see no reason to change the starting column for Emacs at this time.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2