bug#17303: On tty or -nw, (window-body-width) is one column too big.

bug#17303: On tty or -nw, (window-body-width) is one column too big.

[Alan Mackenzie]

Hi, Emacs.

I'm doing something at the moment involving scrolling of windows, and I
need to know at what "visual" column point is in.  So, naturally, I do

    (% (current-column) (window-body-width))

.  At the start of the first continuation line, this formula (correctly)
returns 0 on a GUI, but (e.g.) 79 on a tty or in emacs -nw.

This is caused by emacs counting the "\" character in the right margin as
part of the body-width.  This seems like a bad idea.  I think it's also a
bug.

So, is there a better method of determining the "visual" column point is
in?

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#17303: On tty or -nw, (window-body-width) is one column too big.

[Eli Zaretskii]

> Date: Sun, 20 Apr 2014 17:03:43 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> I'm doing something at the moment involving scrolling of windows, and I
> need to know at what "visual" column point is in.  So, naturally, I do
> 
>     (% (current-column) (window-body-width))
> 
> .  At the start of the first continuation line, this formula (correctly)
> returns 0 on a GUI, but (e.g.) 79 on a tty or in emacs -nw.

You mean, it says 80 in a GUI session, not 0, right?

> This is caused by emacs counting the "\" character in the right margin as
> part of the body-width.

No, it's because the last character in the continued like is in column
78 on a TTY, but in column 79 in a GUI session.  Emacs counts columns
in continuation lines starting from the last column in the previous
line, as you'd expect.  IOW, the continued line is treated as one long
line, and all its columns counted contiguously.

It is true that the "\" character on a TTY takes up one column, and
thus leaves only 79 columns for text, but what else can Emacs do?

> This seems like a bad idea.  I think it's also a bug.

What would you like Emacs to do instead, given what I just explained?

> So, is there a better method of determining the "visual" column point is
> in?

current-column is it.  Please tell why it doesn't fit your needs.

bug#17303: On tty or -nw, (window-body-width) is one column too big.

[Eli Zaretskii]

> Date: Sun, 20 Apr 2014 22:35:24 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 17303@debbugs.gnu.org
> 
> > Date: Sun, 20 Apr 2014 17:03:43 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > 
> > I'm doing something at the moment involving scrolling of windows, and I
> > need to know at what "visual" column point is in.  So, naturally, I do
> > 
> >     (% (current-column) (window-body-width))
> > 
> > .  At the start of the first continuation line, this formula (correctly)
> > returns 0 on a GUI, but (e.g.) 79 on a tty or in emacs -nw.
> 
> You mean, it says 80 in a GUI session, not 0, right?

Wait, perhaps I misunderstood your complain.

Is the problem with window-body-width, rather than with
current-column?  (You seemed to ask about current-column, not
window-body-width.)

If so, then you should know that the continuation character does not
have to take one column, it can be customized via the buffer display
table.  So the effective window width on a TTY is not always 1 column
less than on GUI frames.  Also, if there's a truncation glyph at the
left, you'd probably want us to subtract its length as well, right?

Moreover, when there are no fringes on a GUI frame, we also use "\"
there to indicate a continued line, but we still return from
window-body-width a value that counts the continuation character.

So this is not an easy thing to change.  And the question is of
course: why do it?  What is the use case where you bumped into this
issue, and why window-body-width was important to you?

bug#17303: On tty or -nw, (window-body-width) is one column too big.

[Alan Mackenzie]

Hi, Eli.

On Sun, Apr 20, 2014 at 10:35:24PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 20 Apr 2014 17:03:43 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > I'm doing something at the moment involving scrolling of windows, and I
> > need to know at what "visual" column point is in.  So, naturally, I do

> >     (% (current-column) (window-body-width))

> > .  At the start of the first continuation line, this formula (correctly)
> > returns 0 on a GUI, but (e.g.) 79 on a tty or in emacs -nw.

> You mean, it says 80 in a GUI session, not 0, right?

Er, no.  It says 0 in a GUI session.  In the GUI, (window-body-width) is
the number of characters which fit on the line.  In a tty,
(window-body-width) is ONE MORE than that number.

> > This is caused by emacs counting the "\" character in the right margin as
> > part of the body-width.

> No, it's because the last character in the continued like is in column
> 78 on a TTY, but in column 79 in a GUI session.  Emacs counts columns
> in continuation lines starting from the last column in the previous
> line, as you'd expect.  IOW, the continued line is treated as one long
> line, and all its columns counted contiguously.

Yes, this is true, but it's (window-body-width) which is inconsistent
between GUI and tty.

> It is true that the "\" character on a TTY takes up one column, and
> thus leaves only 79 columns for text, but what else can Emacs do?

Tell me that (window-body-width) is 79, not 80.

> > This seems like a bad idea.  I think it's also a bug.

> What would you like Emacs to do instead, given what I just explained?

See above.

> > So, is there a better method of determining the "visual" column point is
> > in?

> current-column is it.  Please tell why it doesn't fit your needs.

current-column provides the "logical" column (e.g. 79).  I need the
"visual" column (e.g. 0).

I'm working on getting follow-mode's scrolling working properly.  I have
a situation where:
o - point is at Col 79, this being at the start of a continuation line.
o - this position is one line below the bottom of the window
o - (but hasn't been redisplayed yet).
o - set-window-start has NOT been called with a nil NOFORCE parameter.

If I were to allow the redisplay without further action, redisplay would
scroll the window back upwards to ensure point is displayed.  This would
negate the purpose of the scrolling.  I want to move point back into the
window before the redisplay.  So I attempt the following:
o - (setq dest-col (Determine-the-visual-column-point-is-in))
o - (vertical-motion -1)
o - (move-to-column dest-col)

However this last action becomes, on a tty, (move-to-column 79) putting
point back where it started.  :-(

It is (Determine-the-visual-column-..) which gives me trouble.  On a GUI,
I can use

    (% (current-column) (window-body-width))

, but this fails on a tty, as noted above.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#17303: On tty or -nw, (window-body-width) is one column too big.

[Eli Zaretskii]

> Date: Sun, 20 Apr 2014 20:39:04 +0000
> Cc: 17303@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > No, it's because the last character in the continued like is in column
> > 78 on a TTY, but in column 79 in a GUI session.  Emacs counts columns
> > in continuation lines starting from the last column in the previous
> > line, as you'd expect.  IOW, the continued line is treated as one long
> > line, and all its columns counted contiguously.
> 
> Yes, this is true, but it's (window-body-width) which is inconsistent
> between GUI and tty.
> 
> > It is true that the "\" character on a TTY takes up one column, and
> > thus leaves only 79 columns for text, but what else can Emacs do?
> 
> Tell me that (window-body-width) is 79, not 80.

It can't.  It's not designed for what you need.  You should use
different APIs for what you want; see below.

> > current-column is it.  Please tell why it doesn't fit your needs.
> 
> current-column provides the "logical" column (e.g. 79).  I need the
> "visual" column (e.g. 0).

Then what you want is '(car (posn-col-row (posn-at-point)))'.  But see
below.

> I'm working on getting follow-mode's scrolling working properly.  I have
> a situation where:
> o - point is at Col 79, this being at the start of a continuation line.
> o - this position is one line below the bottom of the window
> o - (but hasn't been redisplayed yet).
> o - set-window-start has NOT been called with a nil NOFORCE parameter.
> 
> If I were to allow the redisplay without further action, redisplay would
> scroll the window back upwards to ensure point is displayed.  This would
> negate the purpose of the scrolling.  I want to move point back into the
> window before the redisplay.  So I attempt the following:
> o - (setq dest-col (Determine-the-visual-column-point-is-in))
> o - (vertical-motion -1)
> o - (move-to-column dest-col)
> 
> However this last action becomes, on a tty, (move-to-column 79) putting
> point back where it started.  :-(

I think you just need to use pos-visible-in-window-p instead of all
that complexity: if that function returns an indication that point is
not visible, move it back until it is.  There's also the new
pre-redisplay-function hook that you might find useful.

Don't try to outsmart redisplay; instead, ask redisplay to tell you
what it already knows.  The functions I mentioned are interfaces
exposed by redisplay for this very purpose.

So can we close this bug report?

bug#17303: Acknowledgement (On tty or -nw, (window-body-width) is one column too big.)

[Alan Mackenzie]

Bug closed; not a bug.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#17303: On tty or -nw, (window-body-width) is one column too big.

[Alan Mackenzie]

Hi, Eli.

On Mon, Apr 21, 2014 at 09:56:01AM +0300, Eli Zaretskii wrote:
> > Date: Sun, 20 Apr 2014 20:39:04 +0000
> > Cc: 17303@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > It is true that the "\" character on a TTY takes up one column, and
> > > thus leaves only 79 columns for text, but what else can Emacs do?

> > Tell me that (window-body-width) is 79, not 80.

> It can't.  It's not designed for what you need.  You should use
> different APIs for what you want; see below.

OK.

> > > current-column is it.  Please tell why it doesn't fit your needs.

> > current-column provides the "logical" column (e.g. 79).  I need the
> > "visual" column (e.g. 0).

> Then what you want is '(car (posn-col-row (posn-at-point)))'.  But see
> below.

posn-at-point only works when point is inside a window.  What I ended up
using is

    (- (current-column)
       (progn (vertical-motion 0) (current-column)))

(with a save-excursion at a strategic surrounding point).

> > I'm working on getting follow-mode's scrolling working properly.  I have
> > a situation where:
> > o - point is at Col 79, this being at the start of a continuation line.
> > o - this position is one line below the bottom of the window
> > o - (but hasn't been redisplayed yet).
> > o - set-window-start has NOT been called with a nil NOFORCE parameter.

> > If I were to allow the redisplay without further action, redisplay would
> > scroll the window back upwards to ensure point is displayed.  This would
> > negate the purpose of the scrolling.  I want to move point back into the
> > window before the redisplay.  So I attempt the following:
> > o - (setq dest-col (Determine-the-visual-column-point-is-in))
> > o - (vertical-motion -1)
> > o - (move-to-column dest-col)

> > However this last action becomes, on a tty, (move-to-column 79) putting
> > point back where it started.  :-(

> I think you just need to use pos-visible-in-window-p instead of all
> that complexity: if that function returns an indication that point is
> not visible, move it back until it is.

pos-visible-in-window-p unfortunately doesn't reveal whether pos is above
or below the window, it just returns nil.

> There's also the new pre-redisplay-function hook that you might find
> useful.

OK, I'll look at this sometime.

> Don't try to outsmart redisplay; instead, ask redisplay to tell you
> what it already knows.  The functions I mentioned are interfaces
> exposed by redisplay for this very purpose.

follow-mode is about nothing else but outsmarting redisplay.  ;-)  As its
original author recently discussed with you, it would be nice if there
were more support for it inside redisplay, but that means Somebody (tm)
stepping up to the plate and implementing it.

> So can we close this bug report?

I've just closed it.

Thanks for all the help!

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#17303: On tty or -nw, (window-body-width) is one column too big.

[Eli Zaretskii]

> Date: Mon, 21 Apr 2014 15:43:35 +0000
> Cc: 17303@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Then what you want is '(car (posn-col-row (posn-at-point)))'.  But see
> > below.
> 
> posn-at-point only works when point is inside a window.

Which it sometimes is.  I was drawing your attention to some APIs that
you should know about if you want to mess with redisplay.

> What I ended up using is
> 
>     (- (current-column)
>        (progn (vertical-motion 0) (current-column)))
> 
> (with a save-excursion at a strategic surrounding point).

That should do, but beware of display properties on that line.

> > > I'm working on getting follow-mode's scrolling working properly.  I have
> > > a situation where:
> > > o - point is at Col 79, this being at the start of a continuation line.
> > > o - this position is one line below the bottom of the window
> > > o - (but hasn't been redisplayed yet).
> > > o - set-window-start has NOT been called with a nil NOFORCE parameter.
> 
> > > If I were to allow the redisplay without further action, redisplay would
> > > scroll the window back upwards to ensure point is displayed.  This would
> > > negate the purpose of the scrolling.  I want to move point back into the
> > > window before the redisplay.  So I attempt the following:
> > > o - (setq dest-col (Determine-the-visual-column-point-is-in))
> > > o - (vertical-motion -1)
> > > o - (move-to-column dest-col)
> 
> > > However this last action becomes, on a tty, (move-to-column 79) putting
> > > point back where it started.  :-(
> 
> > I think you just need to use pos-visible-in-window-p instead of all
> > that complexity: if that function returns an indication that point is
> > not visible, move it back until it is.
> 
> pos-visible-in-window-p unfortunately doesn't reveal whether pos is above
> or below the window, it just returns nil.

Your description above indicated that you already know where you are.
If you don't, compare with what window-start returns.

> > Don't try to outsmart redisplay; instead, ask redisplay to tell you
> > what it already knows.  The functions I mentioned are interfaces
> > exposed by redisplay for this very purpose.
> 
> follow-mode is about nothing else but outsmarting redisplay.  ;-)

You can't.

> > So can we close this bug report?
> 
> I've just closed it.

Thanks.