display.texi: (<line>,<col>) isn't documented.

display.texi: (<line>,<col>) isn't documented.

[Alan Mackenzie]

Hi, Emacs!

When one of line-number-mode and column-number-mode is enabled, you see
either "L561" or "C2" in the mode line.  When both are enabled, you see
instead "(561,2)".  This isn't documented in the Emacs manual page
"Optional Mode Line".

I'm not sure what's so good about this, since "(561,2)" needs just as
much space as "L561 C2" and seems less consistent.  However, I'm
assuming this was knocked about on emacs-devel all these years ago, and
there was a good reason for "(561,2)".

So here's a patch (intended for Emacs 22.2 as well as the trunk) to fix
this:


2007-06-06  Alan Mackenzie  <acm@muc.de>

	* display.texi (Optional Mode Line): Document the new form of
	line+column numbers, "(561,2)".


Index: display.texi
===================================================================
RCS file: /cvsroot/emacs/emacs/man/display.texi,v
retrieving revision 1.130
diff -c -r1.130 display.texi
*** display.texi	23 Apr 2007 14:39:40 -0000	1.130
--- display.texi	5 Jun 2007 21:52:22 -0000
***************
*** 922,929 ****
  Number mode is enabled.  Use the command @kbd{M-x line-number-mode} to
  turn this mode on and off; normally it is on.  The line number appears
  after the buffer percentage @var{pos}, with the letter @samp{L} to
! indicate what it is.  @xref{Minor Modes}, for more information about
! minor modes and about how to use this command.
  
  @cindex narrowing, and line number display
    If you have narrowed the buffer (@pxref{Narrowing}), the displayed
--- 922,939 ----
  Number mode is enabled.  Use the command @kbd{M-x line-number-mode} to
  turn this mode on and off; normally it is on.  The line number appears
  after the buffer percentage @var{pos}, with the letter @samp{L} to
! indicate what it is.
! 
! @cindex Column Number mode
! @cindex mode, Column Number
! @findex column-number-mode
!   Similarly, you can display the current column number by turning on
! Column number mode with @kbd{M-x column-number-mode}.  The column
! number is indicated by the letter @samp{C}.  However, when both of
! these modes are enabled, the line and column numbers are displayed in
! parentheses, the line number first, rather than with @samp{L} and
! @samp{C}.  For example: @samp{(561,2)}.  @xref{Minor Modes}, for more
! information about minor modes and about how to use these commands.
  
  @cindex narrowing, and line number display
    If you have narrowed the buffer (@pxref{Narrowing}), the displayed
***************
*** 946,958 ****
  @code{line-number-display-limit-width}.  The default value is 200
  characters.
  
- @cindex Column Number mode
- @cindex mode, Column Number
- @findex column-number-mode
-   You can also display the current column number by turning on Column
- Number mode.  It displays the current column number preceded by the
- letter @samp{C}.  Type @kbd{M-x column-number-mode} to toggle this mode.
- 
  @findex display-time
  @cindex time (on mode line)
    Emacs can optionally display the time and system load in all mode
--- 956,961 ----


-- 
Alan Mackenzie (Ittersbach, Germany).

Re: display.texi: (<line>,<col>) isn't documented.

[Richard Stallman]

    I'm not sure what's so good about this, since "(561,2)" needs just as
    much space as "L561 C2" and seems less consistent.

I think I thought it would be more natural as a way to state
two-dimensional coordinates.

Would people please install the patch in the trunk and in Emacs 22?

mode line: 1) indicate region size, if active; 2) highlight column # if > limit

[Drew Adams]

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

>     I'm not sure what's so good about this, since "(561,2)" needs just as
>     much space as "L561 C2" and seems less consistent.
>
> I think I thought it would be more natural as a way to state
> two-dimensional coordinates.
>
> Would people please install the patch in the trunk and in Emacs 22?


I made this suggestion last September (subject: `size-indication-mode'
tweak), to which Richard replied "It might be a good idea, but let's not
think about it now."

How about now? See attached image.

1. The size indicated is the region size when the region is active.

2. This size indicator gets the region face, to show this (green, in image).

3. The line and column indicator is highlighted (red, in image) when the
cursor passes a user-defined limit. (This version still uses the
(line#,column#) format.)


> Sent: Thursday, September 14
> After the release:
> How about considering this minor tweak to `size-indication-mode'?
> The doc string would also need to be updated accordingly.
>
> The idea is this: Whenever the region is active in transient-mark
> mode, the size indication shows the size of the region, not the
> size of the buffer.
>
> The implementation change is trivial - just use this for the
> `size-indication-mode' part of `mode-line-position':
>
> (size-indication-mode
>  (8 ,(propertize
>       (if (and transient-mark-mode mark-active)
>           (format " %d chars" (abs (- (mark t) (point))))
>         " of %I")
>       'face (and transient-mark-mode mark-active 'region)
>       'help-echo help-echo)))
>
> where help-echo is bound as usual.
>
> FYI - This library does that, as well as highlighting the column
> number when
> the current column is greater than a given limit (option):
> (http://www.emacswiki.org/cgi-bin/wiki/modeline-posn.el)


[-- Attachment #2: modeline-posn.png --]
[-- Type: image/png, Size: 3750 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: mode line: 1) indicate region size, if active; 2) highlight column # if > limit

[David House]

On 06/06/07, Drew Adams <drew.adams@oracle.com> wrote:
> 3. The line and column indicator is highlighted (red, in image) when the
> cursor passes a user-defined limit. (This version still uses the
> (line#,column#) format.)

I like this idea -- make it nice and clear when you pop over the
70th/80th column. Could you be a bit more precise with the semantics?
i) Will it highlight just the col number if you pass the col limit,
and just the row number if you pass the row limit, and both if both,
or does it just highlight both co-ordinates when either exceeds the
limit? I think I'd prefer the former here.
ii) What does it do in the case of line-number-mode and/or
column-number-mode being off?

-- 
-David House, dmhouse@gmail.com

RE: mode line: 1) indicate region size, if active; 2) highlight column # if > limit

[Drew Adams]

> > 3. The line and column indicator is highlighted (red, in image) when the
> > cursor passes a user-defined limit. (This version still uses the
> > (line#,column#) format.)
>
> I like this idea -- make it nice and clear when you pop over the
> 70th/80th column. Could you be a bit more precise with the semantics?
> i) Will it highlight just the col number if you pass the col limit,
> and just the row number if you pass the row limit, and both if both,
> or does it just highlight both co-ordinates when either exceeds the
> limit? I think I'd prefer the former here.
> ii) What does it do in the case of line-number-mode and/or
> column-number-mode being off?

See the code; it's pretty simple:
http://www.emacswiki.org/cgi-bin/wiki/modeline-posn.el.

The only intention is to highlight the column number. I see no reason for a
line (i.e. row) limit, do you?

Highlighting occurs when the cursor column passes a user-defined limit (a
user option, with default value 70, not necessarily `fill-column').

The code I use highlights the column number indicator, if only column-number
mode is on. It highlights the whole pair (line, col), if both line-number
mode and column-number mode are on. It does not highlight the line number,
if only line-number mode is on.

Perhaps the code could be tweaked to highlight only the column number when
both line number mode and column number mode are on, but I'm not bothered by
the extra line-number highlighting, personally.

Re: mode line: 1) indicate region size, if active; 2) highlight column # if > limit

[David House]

On 06/06/07, Drew Adams <drew.adams@oracle.com> wrote:
> See the code; it's pretty simple:
> http://www.emacswiki.org/cgi-bin/wiki/modeline-posn.el.

Thanks, I'll read through.

> The only intention is to highlight the column number. I see no reason for a
> line (i.e. row) limit, do you?

Just thinking along the lines of style guides for programming
languages that dictate that files > 1000 lines should be split.

> The code I use highlights the column number indicator, if only column-number
> mode is on. It highlights the whole pair (line, col), if both line-number
> mode and column-number mode are on. It does not highlight the line number,
> if only line-number mode is on.
>
> Perhaps the code could be tweaked to highlight only the column number when
> both line number mode and column number mode are on, but I'm not bothered by
> the extra line-number highlighting, personally.

Seems acceptable, it's not that big of a deal at the end of the day.

-- 
-David House, dmhouse@gmail.com

Re: mode line: 1) indicate region size, if active; 2) highlight column # if > limit

[chad brown]

> The only intention is to highlight the column number. I see no  
> reason for a
> line (i.e. row) limit, do you?

It might be a good place to put some feedback about having point at  
the end of the buffer.  I know that there are a few other ways to do  
this already, but this seems easy.  *shrug*

*chad

Re: mode line: 1) indicate region size, if active; 2) highlight column # if > limit

[Richard Stallman]

    The code I use highlights the column number indicator, if only column-number
    mode is on. It highlights the whole pair (line, col), if both line-number
    mode and column-number mode are on. It does not highlight the line number,
    if only line-number mode is on.

It might be clearer to highlight only the column number, because that would
say "the problem is the column".

RE: mode line: 1) indicate region size, if active; 2) highlight column # if > limit

[Drew Adams]

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

I don't recall a decision on this. Was there one? The thread seems to have
petered out with no conclusion, unless I missed something.

Reminder: there are two suggested changes: (1) highlight the column number,
(2) indicate the region size. The two are unrelated, but both are here:
http://www.emacswiki.org/cgi-bin/wiki/modeline-posn.el.

I think too that I neglected to point out that the region size indication
(e.g. "30 chars") takes the place in the mode-line of the absolute buffer
size indication (e.g. "of 5.9 k") when the region is active. It does not
replace the relative buffer size indication (e.g. "22%"). It is generally
the same size as the text it replaces.



> From: Drew Adams Sent: Wednesday, June 06, 2007 10:36 AM
> I made this suggestion last September (subject:
> `size-indication-mode' tweak), to which Richard replied "It might
> be a good idea, but let's not think about it now."
>
> How about now? See attached image.
>
> 1. The size indicated is the region size when the region is active.
>
> 2. This size indicator gets the region face, to show this (green,
> in image).
>
> 3. The line and column indicator is highlighted (red, in image)
> when the cursor passes a user-defined limit. (This version still
> uses the (line#,column#) format.)
>
>
> > Sent: Thursday, September 14
> > After the release:
> > How about considering this minor tweak to `size-indication-mode'?
> > The doc string would also need to be updated accordingly.
> >
> > The idea is this: Whenever the region is active in transient-mark
> > mode, the size indication shows the size of the region, not the
> > size of the buffer.
> >
> > The implementation change is trivial - just use this for the
> > `size-indication-mode' part of `mode-line-position':
> >
> > (size-indication-mode
> >  (8 ,(propertize
> >       (if (and transient-mark-mode mark-active)
> >           (format " %d chars" (abs (- (mark t) (point))))
> >         " of %I")
> >       'face (and transient-mark-mode mark-active 'region)
> >       'help-echo help-echo)))
> >
> > where help-echo is bound as usual.
> >
> > FYI - This library does that, as well as highlighting the column
> > number when
> > the current column is greater than a given limit (option):
> > (http://www.emacswiki.org/cgi-bin/wiki/modeline-posn.el)

[-- Attachment #2: modeline-posn.png --]
[-- Type: image/png, Size: 3750 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: mode line: 1) indicate region size, if active; 2) highlight column # if > limit

[Richard Stallman]

I liked the column highlight feature, but the region size
feature didn't seem very useful to me.

Would someone please install the column highlight feature?

If several people try the region size feature, and say they find it
useful, then I will reconsider it.

Re: mode line: 1) indicate region size, if active; 2) highlight column # if > limit

[Juri Linkov]

> I liked the column highlight feature, but the region size
> feature didn't seem very useful to me.
>
> Would someone please install the column highlight feature?
>
> If several people try the region size feature, and say they find it
> useful, then I will reconsider it.

I suggest to install both features, but disable them by default.

There could be new modes to enable each of them.  Unfortunately,
currently there are no convention of adding a common prefix to
the name of the mode affecting the mode line, so from the name
of mode it's impossible to see that it changes the display of the
mode line.  Such modes could have a prefix like `modeline-', e.g.:

modeline-line-number-mode (current line-number-mode)
modeline-column-number-mode (current column-number-mode)
modeline-buffer-size-mode (current size-indication-mode)
modeline-region-size-mode (new mode)
modeline-column-limit (new mode)

Also I suggest to fix the column highlight feature to highlight only
the column number in the combined format "(%l,%c)", not the line number.
And also to change its face definition `modelinepos-column-warning' to
inherit from `font-lock-warning-face'.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: mode line: 1) indicate region size, if active; 2) highlight column # if > limit

[Richard Stallman]

    > If several people try the region size feature, and say they find it
    > useful, then I will reconsider it.

    I suggest to install both features, but disable them by default.

I don't want to do this, because I don't see that the size
feature is sufficiently useful to make that worth while.
We can't afford to install every feature that someone offers.

    Also I suggest to fix the column highlight feature to highlight only
    the column number in the combined format "(%l,%c)", not the line number.

Yes.

    And also to change its face definition `modelinepos-column-warning' to
    inherit from `font-lock-warning-face'.

I am not sure it is worth defining a face just for this.

Re: display.texi: (<line>,<col>) isn't documented.

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     I'm not sure what's so good about this, since "(561,2)" needs just as
>     much space as "L561 C2" and seems less consistent.
>
> I think I thought it would be more natural as a way to state
> two-dimensional coordinates.

I think it is much more legible.  One tends to parse L and C as part
of the number.  But it is hard to say what to do when either may be
absent.

Maybe something like 561: and :2 and 561:2 ?  That's visually
formatted, pretty understandable (also has some relation to error
message formatting), and even more compact.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: display.texi: (<line>,<col>) isn't documented.

[Stefan Monnier]

> Maybe something like 561: and :2 and 561:2 ?

I'm not sure I like the 561: or the :2, but I definitely like the 561:2
better than either of the other two alternatives presented so far.


        Stefan

Re: display.texi: (<line>,<col>) isn't documented.

[Juanma Barranquero]

On 6/6/07, David Kastrup <dak@gnu.org> wrote:

> Maybe something like 561: and :2 and 561:2 ?  That's visually
> formatted, pretty understandable (also has some relation to error
> message formatting), and even more compact.

Yes! m:n (or m/n) is *much* more readable IMHO than "Lm Cn".

I even force them to fixed width:

  (setq mode-line-position '(:propertize ("%5l/" (3 "%c"))
                             face my-position-face))

It's not often that I edit files with more than 99999 lines or more
than 999 columns.

             Juanma

Re: display.texi: (<line>,<col>) isn't documented.

[Juri Linkov]

>> Maybe something like 561: and :2 and 561:2 ?  That's visually
>> formatted, pretty understandable (also has some relation to error
>> message formatting), and even more compact.
>
> Yes! m:n (or m/n) is *much* more readable IMHO than "Lm Cn".

Often I can't instantly recall what number belong to what in the
format (LL,CC), so I need to type C-f a few times and see what number changes.

Maybe this confusion arises from the fact that currently numbers are
displayed in the order reverse to usual, where the first number in
a pair of coordinates corresponds to the x-axis (Columns), and second -
to the y-axis (Lines).

> I even force them to fixed width:
>
>  (setq mode-line-position '(:propertize ("%5l/" (3 "%c"))
>                             face my-position-face))
>
> It's not often that I edit files with more than 99999 lines or more
> than 999 columns.

I think it would be good to save more precious space in the modeline:
to use 8 instead of 12 for the minimum length of the buffer name,
to use 5 instead of 10 for the minimum length of line-number and column-number,
to remove extra space between mode-line-position and mode-line-modes.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: display.texi: (<line>,<col>) isn't documented.

[Drew Adams]

How about:

 column only   -   67x
 line only     -   234y
 line & column -   67x234y

Advantages:

. Few characters (no wasted space).

. It's clear which is horizontal and which is vertical.

. x and y are much more universal than L for "line"
  and C for "column". No need to translate.

. Lowercase makes the units stand out from the digits.
  The descender on the `y' makes it easy to spot and
  disambiguate. (compared with L,C - and l,c suffers
  from confusing l with 1)


Disadvantages of other proposals:

. (34,67) and 34:67 are not clear about which is
  horizontal and which is vertical.

. :67 and 234: take longer to parse, to figure out
  which is horizontal (vs 67x and 234y).

. Using (234,67) for both horizontal and vertical, but 234L
  and 67C for one only is more complex, less consistent.

Re: display.texi: (<line>,<col>) isn't documented.

[David House]

On 07/06/07, Drew Adams <drew.adams@oracle.com> wrote:
>  column only   -   67x
>  line only     -   234y
>  line & column -   67x234y

It's abnormal to put the column first (for example compiler error
messages), so this would be confusing.

-- 
-David House, dmhouse@gmail.com

RE: display.texi: (<line>,<col>) isn't documented.

[Drew Adams]

> >  column only   -   67x
> >  line only     -   234y
> >  line & column -   67x234y
>
> It's abnormal to put the column first (for example compiler error
> messages), so this would be confusing.

We could certainly decide on either order, but I cannot imagine that 234y67x
is more universal or less "abnormal" than 67x234y.

The main point is that either order would be clear (i.e. would not "be
confusing"), because of the explicit dimension indicators `x' and `y'. The
same is not true of the other suggestions (except for `C' and `L').

What's the connection with compiler error messages? This is interactive
feedback about cursor position in a buffer. In compiler output, you are
primarily (as in first) interested in the line number. That's not the case
here - you might be interested in either or both. Yes, it would be
"abnormal" for compiler messages to list the column number first. I don't
see why that's pertinent here.

Re: display.texi: (<line>,<col>) isn't documented.

[Lennart Borgman (gmail)]

Drew Adams wrote:
>>>  column only   -   67x
>>>  line only     -   234y
>>>  line & column -   67x234y
>> It's abnormal to put the column first (for example compiler error
>> messages), so this would be confusing.
> 
> We could certainly decide on either order, but I cannot imagine that 234y67x
> is more universal or less "abnormal" than 67x234y.


Putting the most significant part first is more common AFAICS. That is 
the way we write numbers, for example.

Re: display.texi: (<line>,<col>) isn't documented.

[David House]

On 07/06/07, Drew Adams <drew.adams@oracle.com> wrote:
> The main point is that either order would be clear (i.e. would not "be
> confusing"), because of the explicit dimension indicators `x' and `y'. The
> same is not true of the other suggestions (except for `C' and `L').

Disagreed - I'd probably just glance at the first number and expect it
to be a column number.

Additionally, the numbers in 184x25y aren't as visually distinct as in
(184,25) or 184L 25C (although the latter is still confusing as the L
and C tend to visually merge into the numerals).

> What's the connection with compiler error messages? This is interactive
> feedback about cursor position in a buffer. In compiler output, you are
> primarily (as in first) interested in the line number. That's not the case
> here - you might be interested in either or both. Yes, it would be
> "abnormal" for compiler messages to list the column number first. I don't
> see why that's pertinent here.

They still have in common that they display a line number and a column
number. There aren't many other places where this happens, so compiler
messages are pretty much the standard, I guess.

-- 
-David House, dmhouse@gmail.com

Re: display.texi: (<line>,<col>) isn't documented.

[Juanma Barranquero]

On 6/7/07, Drew Adams <drew.adams@oracle.com> wrote:

> How about:
>
>  column only   -   67x
>  line only     -   234y
>  line & column -   67x234y

Please, don't.

> Advantages:
>
> . Few characters (no wasted space).

More than 234:67

> . It's clear which is horizontal and which is vertical.

Only if you know the (x,y) terminology (i.e.,
technically/scientifically oriented people).

> . x and y are much more universal than L for "line"
>   and C for "column". No need to translate.

I'm not going to defend L and C, but Emacs buffers have rows (lines)
and columns, not x and y coordinates.

> . Lowercase makes the units stand out from the digits.
>   The descender on the `y' makes it easy to spot and
>   disambiguate. (compared with L,C - and l,c suffers
>   from confusing l with 1)

My brain has no trouble parsing 234,67 or 234/67 or 234:67, but
67x234y is just a clump.

> Disadvantages of other proposals:
>
> . (34,67) and 34:67 are not clear about which is
>   horizontal and which is vertical.

No, but many files have much more lines than columns, and it's really
just a convention. Once you've used it for a while, it's automatic.

> . :67 and 234: take longer to parse, to figure out
>   which is horizontal (vs 67x and 234y).

In some universe tangent to mine, surely :)

(BTW, very funny: with a Unicode font you could use U+2192 and U+2193
or some other suitable pointing-looking characters :)

> . Using (234,67) for both horizontal and vertical, but 234L
>   and 67C for one only is more complex, less consistent.

Yes.

             Juanma

Re: display.texi: (<line>,<col>) isn't documented.

[David House]

On 07/06/07, Juanma Barranquero <lekktu@gmail.com> wrote:
> I'm not going to defend L and C, but Emacs buffers have rows (lines)
> and columns, not x and y coordinates.

This is also an important point when you consider that the 'origin' is
at the top-left in Emacs buffers, but at the bottom-left in the first
quadrant of the plane.

-- 
-David House, dmhouse@gmail.com

Re: display.texi: (<line>,<col>) isn't documented.

[Thomas Hühn]

"Juanma Barranquero" <lekktu@gmail.com> writes:

>> . (34,67) and 34:67 are not clear about which is
>>   horizontal and which is vertical.
>
> No, but many files have much more lines than columns, and it's really
> just a convention. Once you've used it for a while, it's automatic.

Also, "a line forward" is usually considered a bigger change than "a
character forward". In "usual" writing systems at least.

If you are looking for a specific position you first locate the correct
line and then the character in this line.

In analogy to writing down numbers (higher-value components come first),
lines should be first.

Unless Emacs goes the step to some totally writing-system-agnostic
editor where writing from top to bottom (or the other way around) is
just as easy as from left to right.

Thomas

Re: display.texi: (<line>,<col>) isn't documented.

[Andreas Schwab]

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

>  line & column -   67x234y

That looks much like width x height with a spurious y tacked to it.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: display.texi: (<line>,<col>) isn't documented.

[Dieter Wilhelm]

Andreas Schwab <schwab@suse.de> writes:
>>  line & column -   67x234y
>
> That looks much like width x height with a spurious y tacked to it.

I agree it looks like a window's size *and* as others pointed out is
in the wrong order of importance, 234y67x look even stranger.

So far David's suggestion is the nicest 11:55 but it might be confused
with the (display-time) in the 24h mode!  Generally I think people who
choose column-number-mode should know what is what.  But let's see
when we disambiguate it a bit with a 'c' or a dash:

300c40  300:40  300-40
12c12   12:12   12-12
13c71   13:71   13-71
1c0     1:0     1-0
12345c0 12345:0 12345-0
12345c12345     12345:12345     12345-12345

With c the meaning is clearer, I think, with the dash it's more
readable.  I'd choose the single c.

-- 
    Best wishes

    H. Dieter Wilhelm
    Darmstadt, Germany

RE: display.texi: (<line>,<col>) isn't documented.

[Drew Adams]

> But let's see when we disambiguate it a bit with a 'c' or a dash:
>
> 300c40  300:40  300-40
> 12c12   12:12   12-12
> 13c71   13:71   13-71
> 1c0     1:0     1-0
> 12345c0 12345:0 12345-0
> 12345c12345     12345:12345     12345-12345
>
> With c the meaning is clearer, I think, with the dash it's more
> readable.  I'd choose the single c.

In 30c40, what makes one necessarily associate the c with 40 and not 30? In
France, one writes 11h25 for 11:25 a.m. (time). That is, the `h' is
associated with the first number. Units are most often written after
quantities, not before: 12m, 15'34", 15min 34sec. (The US dollar is one
exception ($12); there are others.)

Some people have said that it is obvious that line comes before column. I
don't see why that's obvious, but if most people think it is, then there is
nothing wrong with (12,25).

12:25 can be confused with a time. 12-25 can be confused with a range of
some kind (12 through 25). 12.25 can be confused with a decimal number.
Parens are needed for grouping in 12,25 and 12;25 - otherwise, they can be
confused with separate mode-line entries (meaning whatever). 12'25" can be
confused with several things (but it does have the advantage of suggesting
major/primary (line) and minor/secondary (column) units - assuming that it
is clear to all that line is primary).

I think explicit units help, and are consistent and clear also when only one
unit is used (25c). I think they should be placed after the numbers, not
before: 12<line-unit>25<column-unit>. So, 12L25C or 12l25c or 12y25x or some
such. If we can spare a space, then it is even more readable: 12L 25C.

Uppercase letters such as L and C are hard to separate visually from the
digits. Using l and c risks confusion between l and 1.

It's true that x and y suggest geometric position, not lines and columns. x
and y also suggest horizontal and vertical directions, but they do not
suggest lines and columns. In a buffer, horizontal and vertical positions
can only mean lines and columns, however (unless one is thinking pixels).
It's true that y suggests increasing values toward the top, but practice
would soon put the lie to that association.

I prefer 25x 12y (or 12y 25x), personally, but I can live with any of the
proposals, including what we have now. Let the Grand Gnu choose.

Re: display.texi: (<line>,<col>) isn't documented.

[Thomas Hühn]

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

> Some people have said that it is obvious that line comes before column. I
> don't see why that's obvious, but if most people think it is, then there is
> nothing wrong with (12,25).

Because larger quantities are usually written first. hour before minute
before second and so on.

> 12:25 can be confused with a time. 12-25 can be confused with a range of

That's true. And in the english-speaking world it is also used for
specifying chapter and verse in the Bible. Although you wouldn't really
expect Emacs to suggest useful Bible parts in the status line, so
there's no real danger of confusion. :-)

Thomas

Re: display.texi: (<line>,<col>) isn't documented.

[Juanma Barranquero]

On 6/7/07, Drew Adams <drew.adams@oracle.com> wrote:

> Some people have said that it is obvious that line comes before column. I
> don't see why that's obvious

As Lennart and others have explained, because it is customary to refer
first to more important things, and lines are more fundamental when
dealing with an Emacs buffer than columns. It is a bigger movement to
advance a line than a column. line-number-mode is enabled by default,
column-number-mode is not.

> 12:25 can be confused with a time. 12-25 can be confused with a range of
> some kind (12 through 25). 12.25 can be confused with a decimal number.

12/25 can be confused with? A rational number? :)

> Uppercase letters such as L and C are hard to separate visually from the
> digits. Using l and c risks confusion between l and 1.

Use "r" (for rows) and "c". 25r32c is still horrible, though.

> In a buffer, horizontal and vertical positions
> can only mean lines and columns, however (unless one is thinking pixels).

That is true, but it doesn't mean that going from x,y to row,column
(or column,row :) is intuitive at all.

> It's true that y suggests increasing values toward the top, but practice
> would soon put the lie to that association.

That's true for every format described in this tread, even the "Ln vs.
Cn vs. (l,c)" style that we have now.

> but I can live with any of the
> proposals, including what we have now.

Same here. I won't be using it anyway.

             Juanma

Re: display.texi: (<line>,<col>) isn't documented.

[Jay Belanger]

"Juanma Barranquero" <lekktu@gmail.com> writes:
...
>> 12:25 can be confused with a time. 12-25 can be confused with a range of
>> some kind (12 through 25). 12.25 can be confused with a decimal number.
>
> 12/25 can be confused with? A rational number? :)

m/n is often used to indicate "m out of a total of n".

Jay

Re: display.texi: (<line>,<col>) isn't documented.

[Juri Linkov]

> "Juanma Barranquero" <lekktu@gmail.com> writes:
> ...
>>> 12:25 can be confused with a time. 12-25 can be confused with a range of
>>> some kind (12 through 25). 12.25 can be confused with a decimal number.
>>
>> 12/25 can be confused with? A rational number? :)

Dates in the American style.  This is especially confusing in the modeline
if display-time-day-and-date is non-nil.

> m/n is often used to indicate "m out of a total of n".

This format makes some sense for displaying total buffer lines:
"m lines out of a total of n lines of the current buffer"

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: display.texi: (<line>,<col>) isn't documented.

[Dieter Wilhelm]

"Drew Adams" <drew.adams@oracle.com> writes:
>> 12345c0 12345:0 12345-0
>> 12345c12345     12345:12345     12345-12345
>>
>> With c the meaning is clearer, I think, with the dash it's more
>> readable.  I'd choose the single c.
>
> In 30c40, what makes one necessarily associate the c with 40 and not 30? In

Right, but without (column-number-mode t) it's L30 so the association
is with the number behind the letter by customary (Emacs) right ;-).

> don't see why that's obvious, but if most people think it is, then there is
> nothing wrong with (12,25).

It needs two letter more.

> 12:25 can be confused with a time. 12-25 can be confused with a range of
> some kind (12 through 25). 12.25 can be confused with a decimal number.

Yes and '.' is already taken up:

. -- Emacs load specification, good mathematical association for
     floating point load values.

: -- Emacs time specification, good cultural association (in Germany
     at least).

c -- column specification, understandable for English speaking users,
     one could also internationalise it a bit, e.g. 's' (Spalte) for
     us Germans: 12s25 and so on.

> I prefer 25x 12y (or 12y 25x), personally, but I can live with any of the
> proposals, including what we have now. Let the Grand Gnu choose.

Is this an allusion to St IGNUcius
(http://www.stallman.org/saint.html)?

When such extremely important things are to be decided it's always a
good thing to ask for higher authorities 8-).

-- 
    Best wishes

    H. Dieter Wilhelm
    Darmstadt, Germany

Re: display.texi: (<line>,<col>) isn't documented.

[Alan Mackenzie]

Hi, Drew!

I'd absolutely no idea I was starting a discussion like this.  ;-)

There's something about your post which I think is epistemologically
inexact.  [I've been wanting to get that word into a post for years, now.
:-]

On Thu, Jun 07, 2007 at 10:18:42AM -0700, Drew Adams wrote:

[ .... ]

> I think explicit units help, and are consistent and clear also when only one
> unit is used (25c). I think they should be placed after the numbers, not
> before: 12<line-unit>25<column-unit>. So, 12L25C or 12l25c or 12y25x or some
> such. If we can spare a space, then it is even more readable: 12L 25C.

"Lines" and "Columns" here aren't units - they're identifying
information.  If the cursor is on L168, that's in no way 4 times its
being on L42.  As an analogy, you might live at "flat 15" in a block of
flats.  That's not "15 flats", it's not a unit of measurement; it's
merely a label, and if building work happened, you might suddenly find
yourself living at "flat 30", for which you wouldn't want to pay twice
the rent.  You might tell a visitor to come in through the front door, up
the stairs, then you live at the third flat on the left.  Here, "flat" IS
being used as a unit.

Note the difference in order:  "flat 15" vs. "the third flat".

> Uppercase letters such as L and C are hard to separate visually from the
> digits. Using l and c risks confusion between l and 1.

Think how much worse it would have been for the ancient Romans.  ;-)

[ .... ]

> I prefer 25x 12y (or 12y 25x), personally, but I can live with any of
> the proposals, including what we have now. Let the Grand Gnu choose.

It's also worth stating that sophisticated Emacs users can set these
things up however they like, so it's not that big a deal.  I can also
live with (most of) what's been discussed.

-- 
Alan Mackenzie.

RE: display.texi: (<line>,<col>) isn't documented.

[Drew Adams]

> > I think explicit units help, and are consistent and clear also
> > when only one unit is used (25c). I think they should be placed
> > after the numbers, not before: 12<line-unit>25<column-unit>.
> > So, 12L25C or 12l25c or 12y25x or some
> > such. If we can spare a space, then it is even more readable: 12L 25C.
>
> "Lines" and "Columns" here aren't units - they're identifying
> information.  If the cursor is on L168, that's in no way 4 times its
> being on L42.

Perhaps it depends on how you interpret "L" or "lines".

168 lines from buffer top edge is exactly 4 times as far from buffer that
edge as is 42 lines (modulo existence of header lines etc.). 50 columns from
buffer left edge is 5 times as many columns as is 10 columns from that edge.

"Line" as a unit here means line height (including, perhaps, inter-line
spacing). You could even define this unit in terms of points or pixels (you
agree that they are units, right?). It a relative unit, of course, defined
in terms of `frame-char-height' (again, perhaps + inter-line spacing), so
that 1 line in buffer foo might be 14 pixels and 1 line in buffer bar might
be 10 pixels. And of course pixel is itself a relative unit, depending on
monitor ppi... Likewise, for column and `frame-char-width'.

A better argument might be to say that 25x 50y does not refer to 25 x units
and 50 y units (which is why I spoke of x and y directions in that case, and
of x and y as standing for horizontal and vertical).

I really don't care which word you want to use: "unit", "label", "bizdink".
If my write-the-units-after-the-quantities argument doesn't make sense to
you in this context, that's OK.

> As an analogy, you might live at "flat 15" in a block of
> flats.  That's not "15 flats", it's not a unit of measurement; it's
> merely a label, and if building work happened, you might suddenly find
> yourself living at "flat 30", for which you wouldn't want to pay twice
> the rent.

30 flats from block edge (zero) - what's the problem?

Now, if the street addresses of two successive flats are not consecutive,
then there is perhaps a non-linear or even a bizarre relation between flat
units and address units, but that doesn't invalidate either as a unit.

I don't see the contradiction you see - or the relation between flat units
and duobled rent. Perhaps your whole post was meant as humor and I'm just
not getting it? I'm just hoping I understand "flat" correctly ;-).

> You might tell a visitor to come in through the front door, up
> the stairs, then you live at the third flat on the left.  Here, "flat" IS
> being used as a unit.
>
> Note the difference in order:  "flat 15" vs. "the third flat".

My monitor is 3 inches from the table edge (third inch from the edge) and 15
inches from the wall (inch 15 from the wall). So what?

Re: display.texi: (<line>,<col>) isn't documented.

[Davis Herring]

> "Lines" and "Columns" here aren't units - they're identifying
> information.  If the cursor is on L168, that's in no way 4 times its
> being on L42.

Of course it is!  If you type M-x recompile (pause) C-x `, and you go to
line 42, and then (after a bit more typing) type it again and go to line
168*, now 4 times as much of your file compiles without errors.  Seems
straightforward enough to me.

Kidding!

Davis

* Actually it should be 165.  First, 41 lines compiled successfully; then
it was 164.

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: display.texi: (<line>,<col>) isn't documented.

[Richard Stallman]

Of all these alternatives, I don't see that any of them
is better than what we use now.

RE: display.texi: (<line>,<col>) isn't documented.

[Drew Adams]

> Of all these alternatives, I don't see that any of them
> is better than what we use now.

If you are speaking only of the line & column indicator format, then I
agree.


What about my original proposal (and code):

1. Show the region size (highlighted with region face) when active.

2. Highlight the column indicator when the cursor passes a user-defined
column limit.

Re: display.texi: (<line>,<col>) isn't documented.

[Richard Stallman]

    What about my original proposal (and code):

    1. Show the region size (highlighted with region face) when active.

I don't see that that is very useful.  The region is highlighted
itself.

    2. Highlight the column indicator when the cursor passes a user-defined
    column limit.

That sounds like a useful feature.

RE: display.texi: (<line>,<col>) isn't documented.

[Drew Adams]

>     What about my original proposal (and code):
>     1. Show the region size (highlighted with region face) when active.
>
> I don't see that that is very useful.  The region is highlighted
> itself.

Yes, but its size is not obvious, especially if part of it is off-screen.

The size indication can be helpful when coding, to see how long a given
string of characters is. It can also be useful as a sanity check when you
use C-w.

Anyway, I take advantage of it fairly often, mainly for the first reason -
beats counting characters.

Re: display.texi: (<line>,<col>) isn't documented.

[Juri Linkov]

>>     What about my original proposal (and code):
>>     1. Show the region size (highlighted with region face) when active.
>>
>> I don't see that that is very useful.  The region is highlighted
>> itself.
>
> Yes, but its size is not obvious, especially if part of it is off-screen.

`M-=' (count-lines-region) is easy to type.

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: display.texi: (<line>,<col>) isn't documented.

[Drew Adams]

> >>     What about my original proposal (and code):
> >>     1. Show the region size (highlighted with region face) when active.
> >>
> >> I don't see that that is very useful.  The region is highlighted
> >> itself.
> >
> > Yes, but its size is not obvious, especially if part of it is
> off-screen.
>
> `M-=' (count-lines-region) is easy to type.

Sure.

1. If you use the mouse to select text, then having the region size always
visisble (when active) means not having to use `M-=': double-click + click,
or drag a region - you see how big it is as you drag.

2. In transient mark mode, when you use `C-SPC' the region becomes active,
even though it is empty. This mode-line indicator shows you that the region
is active even when you can't see it. When a command (e.g. query-replace)
limits itself to the region, this helps you avoid the exercise of figuring
out that you are acting on an empty region.

This indicator is helpful mainly for someone who uses transient mark mode
(it appears only when the region is active). If you don't use transient mark
mode, you likely won't see the point.

Re: display.texi: (<line>,<col>) isn't documented.

[Johan Bockgård]

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

> If you don't use transient mark mode, you likely won't see the
> point.

Actually, it's the mark that can't be seen, not the point! ;)

-- 
Johan Bockgård

Re: display.texi: (<line>,<col>) isn't documented.

[Richard Stallman]

    1. If you use the mouse to select text, then having the region size always
    visisble (when active) means not having to use `M-=': double-click + click,
    or drag a region - you see how big it is as you drag.

In a case like this, if you have seen the region all the time
you were dragging it, why is it useful to see the size?

    2. In transient mark mode, when you use `C-SPC' the region becomes active,
    even though it is empty. This mode-line indicator shows you that the region
    is active even when you can't see it. When a command (e.g. query-replace)
    limits itself to the region, this helps you avoid the exercise of figuring
    out that you are acting on an empty region.

That is logical, but how often does such a problem occur?  The first
thing an Emac suser will do when something seems broken is type C-g,
and that will deactivate the mark.

RE: display.texi: (<line>,<col>) isn't documented.

[Drew Adams]

>     1. If you use the mouse to select text, then having the
>        region size always visisble (when active) means not
>        having to use `M-=': double-click + click, or drag a
>        region - you see how big it is as you drag.
>
> In a case like this, if you have seen the region all the time
> you were dragging it, why is it useful to see the size?

Quick, select 50 characters starting...there. You might use the keyboard to
place the cursor and then use `C-u 50', but you might instead just grab the
mouse, drag, and stop when the size is 50.

Honestly, I don't want to belabor this. I said that it is only a minor
convenience. I'm glad to have it, but if others don't see the point, so be
it.

>     2. In transient mark mode, when you use `C-SPC' the region
>        becomes active, even though it is empty. This mode-line
>        indicator shows you that the region is active even when
>        you can't see it. When a command (e.g. query-replace)
>        limits itself to the region, this helps you avoid the
>        exercise of figuring out that you are acting on an
>        empty region.
>
> That is logical, but how often does such a problem occur?  The first
> thing an Emac suser will do when something seems broken is type C-g,
> and that will deactivate the mark.

Granted. All I can say is that I find the highlighted `0 chars' indicator in
the mode-line useful. I've used transient mark mode (and delete-selection
mode) for years, so I'm used to doing what you describe, but I find this
indicator quite useful. I miss it, for instance, when I'm using Emacs 20
(which can't use this library).

Recently, David make a remark against turning on transient-mark-mode by
default, saying that "unintended active regions" lead to "constant
interference...with both buffer display and operation". I'm not sure what he
had in mind, but perhaps an unexpected empty region is part of it.

Better to not have to reflect and determine that "something seems broken".

Re: display.texi: (<line>,<col>) isn't documented.

[Richard Stallman]

    Quick, select 50 characters starting...there. You might use the keyboard to
    place the cursor and then use `C-u 50', but you might instead just grab the
    mouse, drag, and stop when the size is 50.

If you want to "select 50 characters" you should use keyboard chars.
The mouse is the wrong tool for the job.

Re: display.texi: (<line>,<col>) isn't documented.

[Richard Stallman]

    Recently, David make a remark against turning on transient-mark-mode by
    default, saying that "unintended active regions" lead to "constant
    interference...with both buffer display and operation". I'm not sure what he
    had in mind, but perhaps an unexpected empty region is part of it.

    Better to not have to reflect and determine that "something seems broken".

Let's investigate this problem and look for the best solution.
First task is figure out what scenarios these problems happen in.

Re: display.texi: (<line>,<col>) isn't documented.

[Richard Stallman]

    Yes, but its size is not obvious, especially if part of it is off-screen.

    The size indication can be helpful when coding, to see how long a given
    string of characters is. It can also be useful as a sanity check when you
    use C-w.

When the region is that large, would you really know the right length
well enough to recognize a wrong length?

Can you tell me how, in practice, you recognize from the displayed
length that the region is wrong?

RE: display.texi: (<line>,<col>) isn't documented.

[Drew Adams]

>     Yes, but its size is not obvious, especially if part of it is
>     off-screen.
>
>     The size indication can be helpful when coding, to see how
>     long a given string of characters is. It can also be useful
>     as a sanity check when you use C-w.
>
> When the region is that large, would you really know the right length
> well enough to recognize a wrong length?
>
> Can you tell me how, in practice, you recognize from the displayed
> length that the region is wrong?

1. Small region of expected length: Equivalent of M-=. Check the length of a
string of chars. Maybe select with the mouse - no need to hit the keyboard
for M-=.

2. Empty region: Be aware when the region is active but empty (transient
mark mode), when operations limited to the region, such as query-replace, do
nothing.

3. Large region: Be aware when the region is humongous (e.g. before you kill
it), without the intrusion of a warning message when a threshold is passed.

#3 is a qualitative comparison. The idea is not to "recognize from the
displayed length that the region is wrong" - in terms of exact length, but
just to tell that the region is enormous - a sanity check.

It's only a minor feature. It's really not a big deal either way: no great
loss if it is not made available, no great convenience if it is. If added,
it should be optional, of course, and perhaps limited to use with transient
mark mode. I find it handy; you might not. Do you use transient mark mode?
Did you try it?

Re: display.texi: (<line>,<col>) isn't documented.

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> It's only a minor feature. It's really not a big deal either way: no great
> loss if it is not made available, no great convenience if it is. If added,
> it should be optional, of course, and perhaps limited to use with transient
> mark mode. I find it handy; you might not.

When transient-mark-mode is enabled, it gets used a _lot_, and having it
constantly produce chatty messages informing me (and in the process
obscuring other information) about stuff which is only occasionally
useful... well it just sounds kind of annoying.

> Did you try it?

Where is "it", anyway?  This is a big thread, and I don't see any
obvious patches from you...

-Miles
-- 
`There are more things in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.'

RE: display.texi: (<line>,<col>) isn't documented.

[Drew Adams]

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

> > It's only a minor feature. It's really not a big deal either
> > way: no great loss if it is not made available, no great
> > convenience if it is. If added, it should be optional, of
> > course, and perhaps limited to use with transient
> > mark mode. I find it handy; you might not.
>
> When transient-mark-mode is enabled, it gets used a _lot_, and having it
> constantly produce chatty messages informing me (and in the process
> obscuring other information) about stuff which is only occasionally
> useful... well it just sounds kind of annoying.

There are no messages. There is only an indicator in the mode line. I'm
attaching the image I sent earlier.

I apparently mixed up two different threads - sorry about that. The proposal
I made was in thread "mode line: 1) indicate region size, if active; 2)
highlight column # if > limit", sent 2007-06-06.

> > Did you try it?
>
> Where is "it", anyway?  This is a big thread, and I don't see any
> obvious patches from you...

My bad for mixing the threads. "It", in what I wrote above, is the region
indicator. The description is in the 6/6/2007 email. The code is here:
http://www.emacswiki.org/cgi-bin/wiki/modeline-posn.el.


[-- Attachment #2: modeline-posn.png --]
[-- Type: image/png, Size: 3750 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: display.texi: (<line>,<col>) isn't documented.

[Richard Stallman]

    > Can you tell me how, in practice, you recognize from the displayed
    > length that the region is wrong?

    1. Small region of expected length: Equivalent of M-=. Check the length of a
    string of chars. Maybe select with the mouse - no need to hit the keyboard
    for M-=.

This does not explain how you can tell whether the length displayed
is right or wrong, or when that is useful.

    3. Large region: Be aware when the region is humongous (e.g. before you kill

That might be useful.

Perhaps it would be useful to display the size of the region
when the region is not entirely visible.

Re: display.texi: (<line>,<col>) isn't documented.

[David House]

On 11/06/07, Richard Stallman <rms@gnu.org> wrote:
> Perhaps it would be useful to display the size of the region
> when the region is not entirely visible.

Currently when you M-w on a large region, it tells you the first few
characters of the region you just saved. Perhaps this behaviour could
be duplicated for C-w and we could also have a command that performs
this, so that you could do it at any time.

-- 
-David House, dmhouse@gmail.com

RE: display.texi: (<line>,<col>) isn't documented.

[Drew Adams]

>     > Can you tell me how, in practice, you recognize from the displayed
>     > length that the region is wrong?
>
>     1. Small region of expected length: Equivalent of M-=. Check
>        the length of a string of chars. Maybe select with the
>        mouse - no need to hit the keyboard for M-=.
>
> This does not explain how you can tell whether the length displayed
> is right or wrong, or when that is useful.

You can tell it is right or wrong if you expect the length to be N and you
see it is not N. That is useful whenever you might use M-= instead, as I
said. It is useful when you might use M-= but you are selecting with the
mouse, not the keyboard.

>     3. Large region: Be aware when the region is humongous (e.g.
>        before you kill
>
> That might be useful.
>
> Perhaps it would be useful to display the size of the region
> when the region is not entirely visible.

Yes. And when it is entirely visible and you are interested in the size and
know what size to expect - which means reading minds in a `cond' or `if'
;-).

Re: display.texi: (<line>,<col>) isn't documented.

[Richard Stallman]

    Maybe this confusion arises from the fact that currently numbers are
    displayed in the order reverse to usual, where the first number in
    a pair of coordinates corresponds to the x-axis (Columns), and second -
    to the y-axis (Lines).

That is a good point.  Do people think we should swap them?

Re: display.texi: (<line>,<col>) isn't documented.

[Thien-Thi Nguyen]

() Richard Stallman <rms@gnu.org>
() Fri, 08 Jun 2007 03:11:34 -0400

       Maybe this confusion arises from the fact that currently
       numbers are displayed in the order reverse to usual, where
       the first number in a pair of coordinates corresponds to
       the x-axis (Columns), and second - to the y-axis (Lines).

   That is a good point.  Do people think we should swap them?

no.  most error messages (when they indicate column) use
FILENAME:LINE:COLUMN: MESSAGE.

for congruence, i suggest :LINES:COLUMNS (prefix ":").
this would degrade to ::COLUMNS when there are no line numbers
(kind of weird) and :LINES when there are no colum numbers.

thi

Re: display.texi: (<line>,<col>) isn't documented.

[Kim F. Storm]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> for congruence, i suggest :LINES:COLUMNS (prefix ":").
> this would degrade to ::COLUMNS when there are no line numbers
> (kind of weird) and :LINES when there are no colum numbers.

Sorry, but I don't really see what's wrong with the current (L,C) format.

IMO all of the suggestions that have been presented so far are less 
readable than the current format.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: display.texi: (<line>,<col>) isn't documented.

[David House]

On 08/06/07, Kim F. Storm <storm@cua.dk> wrote:
> IMO all of the suggestions that have been presented so far are less
> readable than the current format.

+1. The numerals in (12,6) are very visually distinct.

-- 
-David House, dmhouse@gmail.com

Re: display.texi: (<line>,<col>) isn't documented.

[Richard Stallman]

    for congruence, i suggest :LINES:COLUMNS (prefix ":").
    this would degrade to ::COLUMNS when there are no line numbers
    (kind of weird) and :LINES when there are no colum numbers.

People pointed out that could look like a time of day, when in the
mode line.

Re: display.texi: (<line>,<col>) isn't documented.

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Maybe this confusion arises from the fact that currently numbers are
>     displayed in the order reverse to usual, where the first number in
>     a pair of coordinates corresponds to the x-axis (Columns), and second -
>     to the y-axis (Lines).
>
> That is a good point.  Do people think we should swap them?

Please don't.

When I introduced the new (L,C) format, I looked at a number of other
text editors, and they all have line number followed by column number.
So that is the conventional sequence.

Some examples  (line 123, column 45):

VIM:      123,45  
Emacs 21: L123  C45
Word:     Ln 123  Col 45
Nedit:    Line 123   Col 45

It is also consistent with grep and compiler output:

file:123:45 ...


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: display.texi: (<line>,<col>) isn't documented.

[Juri Linkov]

>> That is a good point.  Do people think we should swap them?
>
> Please don't.
>
> When I introduced the new (L,C) format, I looked at a number of other
> text editors, and they all have line number followed by column number.
> So that is the conventional sequence.
>
> Some examples  (line 123, column 45):
>
> VIM:      123,45  
> Emacs 21: L123  C45
> Word:     Ln 123  Col 45
> Nedit:    Line 123   Col 45

I agree that there is no need to swap them.  The only problem with the
(L,C) format is that it's not immediately clear where is the line number
and where is the column number.  Note that other editors have a visual cue
like "Ln", "Line" and "Col" to indicate which is which.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: display.texi: (<line>,<col>) isn't documented.

[Dieter Wilhelm]

Juri Linkov <juri@jurta.org> writes:

>>> That is a good point.  Do people think we should swap them?
>>
>> Please don't.
>>
>> When I introduced the new (L,C) format, I looked at a number of other
>> text editors, and they all have line number followed by column number.
>> So that is the conventional sequence.
>>
>> Some examples  (line 123, column 45):
>>
>> VIM:      123,45  
>> Emacs 21: L123  C45
>> Word:     Ln 123  Col 45
>> Nedit:    Line 123   Col 45
>
> I agree that there is no need to swap them.  The only problem with the
> (L,C) format is that it's not immediately clear where is the line number
> and where is the column number.  Note that other editors have a visual cue
> like "Ln", "Line" and "Col" to indicate which is which.

Yes, it would be clearer with an indicator.  I like the Emacs 21 style
better than the current one.

(But not to be outdone by Vim I remind of the alternative 123c45 8-))

-- 
    Best wishes

    H. Dieter Wilhelm
    Darmstadt, Germany

Re: display.texi: (<line>,<col>) isn't documented.

[Nick Roberts]

 > >     Maybe this confusion arises from the fact that currently numbers are
 > >     displayed in the order reverse to usual, where the first number in
 > >     a pair of coordinates corresponds to the x-axis (Columns), and second -
 > >     to the y-axis (Lines).
 > >
 > > That is a good point.  Do people think we should swap them?
 > 
 > Please don't.
 >
 > When I introduced the new (L,C) format, I looked at a number of other
 > text editors, and they all have line number followed by column number.
 > So that is the conventional sequence.

I agree.  It is confusing, but note that order is not reverse to usual because,
as David Kastrup pointed out, the 'y' axis points downward.  If you think of
the display as a matrix, then the conventional order *is* row-column (Aij).
However, I think the format should change, because (L,C) looks like a
co-ordinate.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: display.texi: (<line>,<col>) isn't documented.

[Stephen Berman]

On Wed, 06 Jun 2007 21:44:26 +0200 David Kastrup <dak@gnu.org> wrote:

> Richard Stallman <rms@gnu.org> writes:
>
>>     I'm not sure what's so good about this, since "(561,2)" needs just as
>>     much space as "L561 C2" and seems less consistent.
>>
>> I think I thought it would be more natural as a way to state
>> two-dimensional coordinates.
>
> I think it is much more legible.  One tends to parse L and C as part
> of the number.  But it is hard to say what to do when either may be
> absent.
>
> Maybe something like 561: and :2 and 561:2 ?  That's visually
> formatted, pretty understandable (also has some relation to error
> message formatting), and even more compact.

I often like to be able to quickly see the number of point (e.g.,
while debugging), so my mode lines often contain a string like this:
"L29 C20 P1217".  This contains all the information I need, and I find
it more easily parsable than "29:20:1217" or "(29,20,1217)" (the
latter also isn't a natural extension of the coordinate analogy).

Steve Berman

Re: display.texi: (<line>,<col>) isn't documented.

[Werner LEMBERG]

> Maybe something like 561: and :2 and 561:2 ?

I like the `561:2'.


    Werner

Re: display.texi: (<line>,<col>) isn't documented.

[Daniel Brockman]

David Kastrup <dak@gnu.org> writes:

> Maybe something like 561: and :2 and 561:2 ?  That's visually
> formatted, pretty understandable (also has some relation to error
> message formatting), and even more compact.

I have been using `561/754:2' for a long time (the second
number indicates the total number of lines), and I like it.

-- 
Daniel Brockman <daniel@brockman.se>

Re: display.texi: (<line>,<col>) isn't documented.

[Juri Linkov]

>> Maybe something like 561: and :2 and 561:2 ?  That's visually
>> formatted, pretty understandable (also has some relation to error
>> message formatting), and even more compact.
>
> I have been using `561/754:2' for a long time (the second
> number indicates the total number of lines), and I like it.

This calls for more user options?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: display.texi: (<line>,<col>) isn't documented.

[Jay Belanger]

Richard Stallman <rms@gnu.org> writes:

>     I'm not sure what's so good about this, since "(561,2)" needs just as
>     much space as "L561 C2" and seems less consistent.
>
> I think I thought it would be more natural as a way to state
> two-dimensional coordinates.

Although the coordinates are backwards from the usual (x,y)
coordinates.

Jay

Re: display.texi: (<line>,<col>) isn't documented.

[David Kastrup]

Jay Belanger <jay.p.belanger@gmail.com> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     I'm not sure what's so good about this, since "(561,2)" needs just as
>>     much space as "L561 C2" and seems less consistent.
>>
>> I think I thought it would be more natural as a way to state
>> two-dimensional coordinates.
>
> Although the coordinates are backwards from the usual (x,y)
> coordinates.

No, just turned by 90 degrees: (x,y) progresses to (right,up), while
(row,column) progresses (down,right).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: display.texi: (<line>,<col>) isn't documented.

[Nick Roberts]

 > >     I'm not sure what's so good about this, since "(561,2)" needs just as
 > >     much space as "L561 C2" and seems less consistent.
 > >
 > > I think I thought it would be more natural as a way to state
 > > two-dimensional coordinates.
 > 
 > Although the coordinates are backwards from the usual (x,y)
 > coordinates.

It follows the Aij (row, column)  convention of matrices though.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: display.texi: (<line>,<col>) isn't documented.

[Alan Mackenzie]

Morning, Richard!

On Wed, Jun 06, 2007 at 12:59:23PM -0400, Richard Stallman wrote:
>     I'm not sure what's so good about this, since "(561,2)" needs just as
>     much space as "L561 C2" and seems less consistent.
> 
> I think I thought it would be more natural as a way to state
> two-dimensional coordinates.
> 
> Would people please install the patch in the trunk and in Emacs 22?

DONE.

-- 
Alan.

Re: display.texi: (<line>,<col>) isn't documented.

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jun 06, 2007 at 12:19:47AM +0100, Alan Mackenzie wrote:
> Hi, Emacs!
> 
> When one of line-number-mode and column-number-mode is enabled, you see
> either "L561" or "C2" in the mode line.  When both are enabled, you see
> instead "(561,2)".  This isn't documented in the Emacs manual page
> "Optional Mode Line".

One definitive disadvantage of the "Lnnn Cnnn" format (and of the
separate "Lnnn" or "Cnnn" formats in use now) is that they are not very
internatinalization-friendly: they'll work only in English and some
Latin-based languages.

Of course, Emacs isn't i18n-ready, by a far stretch, but if we want to
have that some day, maybe now is the time to consider such things when
designing new features -- wdyt? 

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFGZ8CHBcgs9XrR2kYRAiOUAJ9dGAAOvPqEVYkihuBItMdQESVjOwCeORxh
r+ZvymMbs0Um5sfHJBSeleo=
=Ah+l
-----END PGP SIGNATURE-----

Re: display.texi: (<line>,<col>) isn't documented.

[Alan Mackenzie]

'n Tag, Tomas!

On Thu, Jun 07, 2007 at 08:23:35AM +0000, tomas@tuxteam.de wrote:
> On Wed, Jun 06, 2007 at 12:19:47AM +0100, Alan Mackenzie wrote:
> > Hi, Emacs!

> > When one of line-number-mode and column-number-mode is enabled, you
> > see either "L561" or "C2" in the mode line.  When both are enabled,
> > you see instead "(561,2)".  This isn't documented in the Emacs manual
> > page "Optional Mode Line".

> One definitive disadvantage of the "Lnnn Cnnn" format (and of the
> separate "Lnnn" or "Cnnn" formats in use now) is that they are not very
> internatinalization-friendly: they'll work only in English and some
> Latin-based languages.
 
I don't agree.  I think that the "L" and the "C" aren't really understood
as letters: they're kind of uninterpreted symbols.  Were the the position
to be indicated as just "561 2", who would know what they meant?  I'd
dislike that immensely.  But I wouldn't be bothered if some other random
letters, say "Z" und "S" were used instead.
 
> Of course, Emacs isn't i18n-ready, by a far stretch, but if we want to
> have that some day, maybe now is the time to consider such things when
> designing new features -- wdyt? 

That I want Emacs optimised for left-to-right European languages and
culture.  ;-)  For example, the Line number is written to the left of the
Column number, and it is "obviously" the Right Thing in our culture.
Surely part of the internationalisation will be displaying these things
appropriately for other cultures: for example, with the mode column on
the left, and the line number under the column number.  We shouldn't try
to find a compromise solution which would satisfy nobody.

> Regards -- tomás

-- 
Alan.

Re: display.texi: (<line>,<col>) isn't documented.

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Jun 07, 2007 at 06:25:01PM +0100, Alan Mackenzie wrote:
> 'n Tag, Tomas!

Tagchen!

> On Thu, Jun 07, 2007 at 08:23:35AM +0000, tomas@tuxteam.de wrote:
> > On Wed, Jun 06, 2007 at 12:19:47AM +0100, Alan Mackenzie wrote:

> > One definitive disadvantage of the "Lnnn Cnnn" format [...]
> > is that they are not very internatinalization-friendly

> I don't agree.  I think that the "L" and the "C" aren't really understood
> as letters: they're kind of uninterpreted symbols.

Makes sense. My argument was "all other things being equal, prefer
language-agnostic constructs". But other things ain't equal. The
alternatives proposed so far all have their own disadvantages.

[...]

> That I want Emacs optimised for left-to-right European languages and
> culture.  ;-) [...]
>                      We shouldn't try
> to find a compromise solution which would satisfy nobody.

Fair enough

Thanks
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFGaRKuBcgs9XrR2kYRApqtAJ0T5g1JbPjjHWt8csT3kT0uQZ6/+QCfTG+a
BuhQkX2OPC0FILMJl5tU2BI=
=b/gs
-----END PGP SIGNATURE-----