line-start?

line-start?

[Bastien]

Hi,

I am trying to get the position of the first visible character
on the current line, when the window is scrolled horizontally.

Something similar to (window-start) but for the current line.

What would be the idiomatic way to get this information?

Thanks,

-- 
 Bastien

Re: line-start?

[Bastien]

Bastien <bzg@gnu.org> writes:

> Something similar to (window-start) but for the current line.

FWIW, I've found (window-hscroll) which gives me what I want.

-- 
 Bastien

Re: line-start?

[Eli Zaretskii]

> From: Bastien <bzg@gnu.org>
> Date: Thu, 06 Feb 2020 14:00:26 +0100
> 
> > Something similar to (window-start) but for the current line.
> 
> FWIW, I've found (window-hscroll) which gives me what I want.

If you need a buffer position, then window-hscroll is not what you
want, because it returns the number of columns the window is
hscrolled.  Also, when auto-hscroll-mode is 'current-line', the value
returned by window-hscroll is only correct for the current line,
i.e. the line which includes point.

If you need a buffer position of the first (leftmost) visible
character, then I think you want this instead:

  (nth 1 (posn-at-x-y 0 (cdr (posn-x-y (posn-at-point)))))

Re: line-start?

[Bastien]

Hi Eli,

Eli Zaretskii <eliz@gnu.org> writes:

> If you need a buffer position of the first (leftmost) visible
> character, then I think you want this instead:
>
>   (nth 1 (posn-at-x-y 0 (cdr (posn-x-y (posn-at-point)))))

Thanks a lot -- this is indeed more precise.  (window-hscroll)
does not handle rescaled text very well, whereas this solution
does.

However, when the cursor is right under the header-line, the
expression above returns 'header-line, so I could not use it
for my purpose.

Also, the same expression returns 'header-line when the cursor
is on the _second_ line below the 'header-line -- I haven't
looked for why it does so, but if it is reproducible, maybe
there is something inconsistent here.

Thanks again anyway!

-- 
 Bastien

Re: line-start?

[Eli Zaretskii]

> From: Bastien <bzg@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 07 Feb 2020 07:42:28 +0100
> 
> >   (nth 1 (posn-at-x-y 0 (cdr (posn-x-y (posn-at-point)))))
> 
> Thanks a lot -- this is indeed more precise.  (window-hscroll)
> does not handle rescaled text very well, whereas this solution
> does.

Once again, window-hscroll just returns the number of columns by which
the window is hscrolled, it doesn't return the buffer position.  For
example, window-hscroll will return the same value for each line in
the window, although the buffer position of the beginning of each line
is different.  Are you looking for columns or for buffer positions?

> However, when the cursor is right under the header-line, the
> expression above returns 'header-line, so I could not use it
> for my purpose.
> 
> Also, the same expression returns 'header-line when the cursor
> is on the _second_ line below the 'header-line -- I haven't
> looked for why it does so, but if it is reproducible, maybe
> there is something inconsistent here.

Yes, you need to correct the Y coordinate returned by posn-at-point
when the window has a header line.  The correction can be calculated
like this:

  (- (nth 1 (window-edges nil t nil t))
     (nth 1 (window-edges nil nil nil t)))

Re: line-start?

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

> Once again, window-hscroll just returns the number of columns by which
> the window is hscrolled, it doesn't return the buffer position.  For
> example, window-hscroll will return the same value for each line in
> the window, although the buffer position of the beginning of each line
> is different.  Are you looking for columns or for buffer positions?

I was looking for columns.

The use case was this one: given a line, display the content of this
line in the header line.  When horizontally scrolled, the header has
to display a substring of the line under the cursor, something like
(substring (current-line-string) offset-in-columns).

When the text is not scaled, (window-hscroll) does the job of giving
me the columns for the offset.

When the text is scaled, your function does a better job at finding
the position of the first visible char in the current line, from which
I get the offset: (- first-visible-char-in-current-line (point-at-bol))

> Yes, you need to correct the Y coordinate returned by posn-at-point
> when the window has a header line.  The correction can be calculated
> like this:
>
>   (- (nth 1 (window-edges nil t nil t))
>      (nth 1 (window-edges nil nil nil t)))

Nice!  My initial use-case is gone, but I like this function:

(defun window-line-start (&optional pos window)
  "Return the position of the visual start of the line.
POS defaults to point in WINDOW; WINDOW defaults to the current window."
  (nth 1 (posn-at-x-y
	  0 (+ (cdr (posn-x-y (posn-at-point pos window)))
	       (- (nth 1 (window-edges nil t nil t))
		  (nth 1 (window-edges nil nil nil t)))))))

My use-case is gone, I went with overlays instead of the header line.

But I guess `window-line-start' could perhaps be useful to others.

-- 
 Bastien

Re: line-start?

[Eli Zaretskii]

> From: Bastien <bzg@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 07 Feb 2020 11:11:15 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Once again, window-hscroll just returns the number of columns by which
> > the window is hscrolled, it doesn't return the buffer position.  For
> > example, window-hscroll will return the same value for each line in
> > the window, although the buffer position of the beginning of each line
> > is different.  Are you looking for columns or for buffer positions?
> 
> I was looking for columns.

Then (nth 1) of what posn-at-x-y returns is not what you want.  You
should use the (car (nth 6)) instead.

> The use case was this one: given a line, display the content of this
> line in the header line.  When horizontally scrolled, the header has
> to display a substring of the line under the cursor, something like
> (substring (current-line-string) offset-in-columns).

But using the buffer position, you could use buffer-substring instead,
right?

> (defun window-line-start (&optional pos window)
>   "Return the position of the visual start of the line.
> POS defaults to point in WINDOW; WINDOW defaults to the current window."
>   (nth 1 (posn-at-x-y
> 	  0 (+ (cdr (posn-x-y (posn-at-point pos window)))
> 	       (- (nth 1 (window-edges nil t nil t))
> 		  (nth 1 (window-edges nil nil nil t)))))))
> 
> My use-case is gone, I went with overlays instead of the header line.
> 
> But I guess `window-line-start' could perhaps be useful to others.

Maybe.

Re: line-start?

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

> Then (nth 1) of what posn-at-x-y returns is not what you want.  You
> should use the (car (nth 6)) instead.

FWIW I just tried this:

(car (nth 6 (posn-at-x-y
	0 (+ (cdr (posn-x-y (posn-at-point pos window)))
	     (- (nth 1 (window-edges nil t nil t))
		(nth 1 (window-edges nil nil nil t)))))))

but it always returns 0.

The version with (nth 1 ...) works fine, though.

>> The use case was this one: given a line, display the content of this
>> line in the header line.  When horizontally scrolled, the header has
>> to display a substring of the line under the cursor, something like
>> (substring (current-line-string) offset-in-columns).
>
> But using the buffer position, you could use buffer-substring instead,
> right?

Yes, sure, but I still need to know the window line start to get the
offset.

-- 
 Bastien

Re: line-start?

[Eli Zaretskii]

> From: Bastien <bzg@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 07 Feb 2020 11:48:02 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Then (nth 1) of what posn-at-x-y returns is not what you want.  You
> > should use the (car (nth 6)) instead.
> 
> FWIW I just tried this:
> 
> (car (nth 6 (posn-at-x-y
> 	0 (+ (cdr (posn-x-y (posn-at-point pos window)))
> 	     (- (nth 1 (window-edges nil t nil t))
> 		(nth 1 (window-edges nil nil nil t)))))))
> 
> but it always returns 0.

Ah, yes: you will have to add (window-hscroll) to that.

> The version with (nth 1 ...) works fine, though.

But that gives a buffer position, not column number.

> >> The use case was this one: given a line, display the content of this
> >> line in the header line.  When horizontally scrolled, the header has
> >> to display a substring of the line under the cursor, something like
> >> (substring (current-line-string) offset-in-columns).
> >
> > But using the buffer position, you could use buffer-substring instead,
> > right?
> 
> Yes, sure, but I still need to know the window line start to get the
> offset.

No, buffer position is absolute.

Re: line-start?

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

> But that gives a buffer position, not column number.

(- (window-line-start) (line-beginning-position))

gives me the column number.

-- 
 Bastien

Re: line-start?

[Eli Zaretskii]

> From: Bastien <bzg@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 07 Feb 2020 15:46:09 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But that gives a buffer position, not column number.
> 
> (- (window-line-start) (line-beginning-position))
> 
> gives me the column number.

That's not the column number, that's the ordinal number of the
character on a line.  It doesn't take into account characters that
take more than one column, it doesn't take into account characters
that are composed to produce a single grapheme cluster (or even a
single glyph), and it doesn't take into account variable-size fonts.

Of course, if all these are unimportant in your use case, you can
disregard them.  But a general-purpose function cannot disregard them.

Re: line-start?

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

> That's not the column number, that's the ordinal number of the
> character on a line.  It doesn't take into account characters that
> take more than one column, it doesn't take into account characters
> that are composed to produce a single grapheme cluster (or even a
> single glyph), and it doesn't take into account variable-size fonts.

Fair enough.

> Of course, if all these are unimportant in your use case, you can
> disregard them.  But a general-purpose function cannot disregard
> them.

Agreed!

-- 
 Bastien