GNU bug report logs - #26694
preview-at-point fails on very long lines with "End of buffer"

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26694 in the body.
You can then email your comments to 26694 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Frank Fischer <frank-fischer <at> shadow-soft.de>
To: bug-auctex <at> gnu.org
Subject: preview-at-point fails on very long lines with "End of buffer"
Date: Fri, 28 Apr 2017 15:26:51 +0200

Hi,

consider the following example file https://pastebin.com/73W7EbCa

This file has a single very long line with one math item at the end. Do
the following:

1. generate the preview with C-c C-p C-p
2. move point to the "x" in the math block, change it to "y" and leave
point within the math block
3. execute C-c C-p C-p again

One should get the message "End of buffer" without the preview being
regenerated.

AFAICT the reason is that in this case only the snippet $x$ without the
text preceding the snippet in the line is copied to the temporary file
for generating the preview. However line 2103 in tex-buf.el (that is the
line with "(forward-char (cdr line-col))") tries to move point to the
*original* column of the snippet. This number is so large that
"(forward-char ...)" will actually reach the end of the buffer and the
error occurs.

However, I would say the the column offset is just wrong. Either
subtract the length of the preceding text (in the original buffer) from
the column number or copy the preceding text to the temp buffer as well.

I hope my description is clear, if not, please ask ;)

Best regards,
Frank

Message #8 received at 26694 <at> debbugs.gnu.org (full text, mbox):

From: Mosè Giordano <mose <at> gnu.org>
To: Frank Fischer <frank-fischer <at> shadow-soft.de>
Cc: 26694 <at> debbugs.gnu.org
Subject: Re: bug#26694: preview-at-point fails on very long lines with "End of
 buffer"
Date: Fri, 28 Apr 2017 17:42:38 +0200

Hi Frank,

2017-04-28 15:26 GMT+02:00 Frank Fischer <frank-fischer <at> shadow-soft.de>:
> Hi,
>
> consider the following example file https://pastebin.com/73W7EbCa
>
> This file has a single very long line with one math item at the end. Do
> the following:
>
> 1. generate the preview with C-c C-p C-p
> 2. move point to the "x" in the math block, change it to "y" and leave
> point within the math block
> 3. execute C-c C-p C-p again
>
> One should get the message "End of buffer" without the preview being
> regenerated.
>
> AFAICT the reason is that in this case only the snippet $x$ without the
> text preceding the snippet in the line is copied to the temporary file
> for generating the preview. However line 2103 in tex-buf.el (that is the
> line with "(forward-char (cdr line-col))") tries to move point to the
> *original* column of the snippet. This number is so large that
> "(forward-char ...)" will actually reach the end of the buffer and the
> error occurs.
>
> However, I would say the the column offset is just wrong. Either
> subtract the length of the preceding text (in the original buffer) from
> the column number or copy the preceding text to the temp buffer as well.
>
> I hope my description is clear, if not, please ask ;)

Thanks for the detailed bug report, I can reproduce it.  However,
right now I don't have the time to dig into it, but I found that the
issue should be in `TeX-region-create' and can be reproduced with
point on the "y" with

--8<---------------cut here---------------start------------->8---
(preview-region (preview-next-border t)
        (preview-next-border nil))
--8<---------------cut here---------------end--------------->8---

If someone else wants to look into it, please go ahead.

Bye,
Mosè

Message #13 received at 26694-done <at> debbugs.gnu.org (full text, mbox):

From: Mosè Giordano <mose <at> gnu.org>
To: Frank Fischer <frank-fischer <at> shadow-soft.de>
Cc: 26694-done <at> debbugs.gnu.org
Subject: Re: bug#26694: preview-at-point fails on very long lines with "End of
 buffer"
Date: Sat, 6 May 2017 20:31:44 +0200

Hi Frank,

2017-04-28 15:26 GMT+02:00 Frank Fischer <frank-fischer <at> shadow-soft.de>:
> However, I would say the the column offset is just wrong. Either
> subtract the length of the preceding text (in the original buffer) from
> the column number or copy the preceding text to the temp buffer as well.

I think you're right, a good solution would be to add one more
argument to `TeX-region-create' with the adjusted line-col
information.  However, in order to avoid changing the signature of the
function I decided to apply a work around: the point is moved only
when `TeX-source-correlate-mode' is non nil (because point is moved
only to make forward/inverse search work) and this variable is
let-bound to nil when running the preview (forward/inverse search is
not needed here).

I dropped a few comments about this work-around in the code, in case
someone want to improve the fix, maybe as suggested above.  In any
case, I'm closing this ticket as the issue should be fixed.

Thanks for the good bug report Frank!

Bye,
Mosè

Message #16 received at 26694 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: 26694 <at> debbugs.gnu.org, mose <at> gnu.org
Subject: Re: bug#26694: preview-at-point fails on very long lines with "End of
 buffer"
Date: Sun, 28 May 2017 22:12:02 +0900

[Message part 1 (text/plain, inline)]

[ Dropped Frank from the recipients. ]

Hi Mosè and all,

> I think you're right, a good solution would be to add one more
> argument to `TeX-region-create' with the adjusted line-col
> information.  However, in order to avoid changing the signature of the
> function I decided to apply a work around: the point is moved only
> when `TeX-source-correlate-mode' is non nil (because point is moved
> only to make forward/inverse search work) and this variable is
> let-bound to nil when running the preview (forward/inverse search is
> not needed here).

> I dropped a few comments about this work-around in the code, in case
> someone want to improve the fix, maybe as suggested above.  In any
> case, I'm closing this ticket as the issue should be fixed.

I looked into this problem and would like to share my thoughts about
this.

(1) Some problems of the essentially same origin still remain.
   (a) Open Frank's sample file and enable TeX-source-correlate-mode.
   (b) Put the region over "$x$".
   (c) Type C-c C-p C-r.  "End of buffer" error again.  C-c C-r gives
       the same error, too.

    Here is the relavant codes Mosè modified in tex-buf.el:
	(when TeX-source-correlate-mode
	    (let ((line-col (with-current-buffer orig-buffer
			   (cons (TeX-line-number-at-pos)
				 (current-column)))))
	   (goto-char (point-min))
	   (forward-line (1- (abs (- header-offset (car line-col)))))
	   (forward-char (cdr line-col))))
    It is this `forward-char' that raises the error.  The number
    returned by `(current-column)' is not correct when, in original
    buffer, the region starts in the middle of a line and the point is
    on the first line of the region.  If a relatively small region has
    no newline in it and is put on the rightward enough of a very long
    line, the returned value is too large for `forward-char'.

(2) We can find a function `TeX-region-update-point', which does a
    similar job but without adjustment of the column.  I suppose we can
    unify them.

Considering that, in addition to (1) and (2), update of the position of
the point in _region_.tex is only necessary when we invoke viewer, call
to `TeX-region-update-point' can be summarized in `TeX-command' with
test of `(string= name "View")'.

I made a tentative patch along these idea and attached it to this
message.  I stopped using `current-column' and use difference betewwn
point and max{beginning of line, beginning of region}.

(3) It seems that the feature of forward and inverse search for region
    file is not mature yet.  If I understand correctly, it works only
    with evince, atril and pdf-tools as viewer, right?  The other
    viewers in `TeX-view-program-list-builtin' receive the file name and
    line number with "%b" and "%n" expanders, but these are not expanded
    to suitable value when using region file.
    Maybe we should add other expanders which work even with region
    file.

(4) Using `current-column' might not be suitable even when we use evince
    or atril.  The function `TeX-evince-sync-view-1' passes required
    parameters to the viewers like this:
	   (list :struct :int32 (TeX-line-number-at-pos)
		 :int32 (1+ (current-column)))
    Most of CJK letters count as occuping 2 columns, so the column
    number is not equal to the number of the characters counting from
    the beginning of a line.   (I don't know what is the correct
    "column" parameters for evince and atril (number of letters?
    bytes in UTF8? or other?), so don't know how we should change this
    part.)

Best,
Ikumi Keita

[region-point-update (text/x-diff, attachment)]

Message #19 received at 26694 <at> debbugs.gnu.org (full text, mbox):

From: Mosè Giordano <mose <at> gnu.org>
To: 26694 <at> debbugs.gnu.org, Mosè Giordano <mose <at> gnu.org>
Subject: Re: bug#26694: preview-at-point fails on very long lines with "End of
 buffer"
Date: Sun, 28 May 2017 17:58:10 +0200

Hi Keita,

2017-05-28 15:12 GMT+02:00 Ikumi Keita <ikumi <at> ikumi.que.jp>:
> I looked into this problem and would like to share my thoughts about
> this.

Thanks!  As I said, mine was more a workaround rather than a real fix,
I'm happy someone else is addressing the issue :-)

> (1) Some problems of the essentially same origin still remain.
>    (a) Open Frank's sample file and enable TeX-source-correlate-mode.
>    (b) Put the region over "$x$".
>    (c) Type C-c C-p C-r.  "End of buffer" error again.  C-c C-r gives
>        the same error, too.
>
>     Here is the relavant codes Mosè modified in tex-buf.el:
>         (when TeX-source-correlate-mode
>             (let ((line-col (with-current-buffer orig-buffer
>                            (cons (TeX-line-number-at-pos)
>                                  (current-column)))))
>            (goto-char (point-min))
>            (forward-line (1- (abs (- header-offset (car line-col)))))
>            (forward-char (cdr line-col))))
>     It is this `forward-char' that raises the error.  The number
>     returned by `(current-column)' is not correct when, in original
>     buffer, the region starts in the middle of a line and the point is
>     on the first line of the region.  If a relatively small region has
>     no newline in it and is put on the rightward enough of a very long
>     line, the returned value is too large for `forward-char'.
>
> (2) We can find a function `TeX-region-update-point', which does a
>     similar job but without adjustment of the column.  I suppose we can
>     unify them.
>
> Considering that, in addition to (1) and (2), update of the position of
> the point in _region_.tex is only necessary when we invoke viewer, call
> to `TeX-region-update-point' can be summarized in `TeX-command' with
> test of `(string= name "View")'.
>
> I made a tentative patch along these idea and attached it to this
> message.  I stopped using `current-column' and use difference betewwn
> point and max{beginning of line, beginning of region}.

I like your approach!  In addition, this doesn't need changing the
arguments of `TeX-region-create', that's what I wanted to avoid.

> (3) It seems that the feature of forward and inverse search for region
>     file is not mature yet.  If I understand correctly, it works only
>     with evince, atril and pdf-tools as viewer, right?

Evince and Atril yes (see release notes for AUCTeX 11.89), I don't
know about pdf-tools but it's possible.

>     The other
>     viewers in `TeX-view-program-list-builtin' receive the file name and
>     line number with "%b" and "%n" expanders, but these are not expanded
>     to suitable value when using region file.
>     Maybe we should add other expanders which work even with region
>     file.

Other expanders?  Why not adapting the existing ones?  Anyway, I'm not
sure that inverse search would work with other viewers.

> (4) Using `current-column' might not be suitable even when we use evince
>     or atril.  The function `TeX-evince-sync-view-1' passes required
>     parameters to the viewers like this:
>            (list :struct :int32 (TeX-line-number-at-pos)
>                  :int32 (1+ (current-column)))
>     Most of CJK letters count as occuping 2 columns, so the column
>     number is not equal to the number of the characters counting from
>     the beginning of a line.   (I don't know what is the correct
>     "column" parameters for evince and atril (number of letters?
>     bytes in UTF8? or other?), so don't know how we should change this
>     part.)

I don't know, sorry.

Bye,
Mosè

Message #22 received at 26694 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Mosè Giordano <mose <at> gnu.org>
Cc: 26694 <at> debbugs.gnu.org
Subject: Re: bug#26694: preview-at-point fails on very long lines with "End of
 buffer"
Date: Mon, 29 May 2017 23:33:11 +0900

Hi!

>>>>> Mosè Giordano <mose <at> gnu.org> writes:

>> I made a tentative patch along these idea and attached it to this
>> message.  I stopped using `current-column' and use difference betewwn
>> point and max{beginning of line, beginning of region}.

> I like your approach!  In addition, this doesn't need changing the
> arguments of `TeX-region-create', that's what I wanted to avoid.

Thanks, then my idea seems to be acceptable.

>> (3) It seems that the feature of forward and inverse search for region
>> file is not mature yet.  If I understand correctly, it works only
>> with evince, atril and pdf-tools as viewer, right?

> Evince and Atril yes (see release notes for AUCTeX 11.89), I don't
> know about pdf-tools but it's possible.

I see.  Thanks for confirmation.

>> The other viewers in `TeX-view-program-list-builtin' receive the file
>> name and line number with "%b" and "%n" expanders, but these are not
>> expanded to suitable value when using region file.
>> Maybe we should add other expanders which work even with region
>> file.
> Anyway, I'm not sure that inverse search would work with other
> viewers.

Gosh, these viewers use emacslient on reverse search, which ends up with
opening _region_.tex buffer instead of the original document's buffer
when using region file.  Then it's not so useful to arrange the
expanders to work with region file in forward search...

> Other expanders?  Why not adapting the existing ones?

What was in my mind was the user customization.  If someone has set up
one's `TeX-command-list' to use "%b" or "%n" and that relies on the
current behavior, i.e., to give the original file's name or line number
instead of _region_.tex's, then arranging them will break that
customization.  (Of course I estimate such probability to be very low.)

>> (4) Using `current-column' might not be suitable even when we use evince
>> or atril.  The function `TeX-evince-sync-view-1' passes required
>> parameters to the viewers like this:
>> (list :struct :int32 (TeX-line-number-at-pos)
>> :int32 (1+ (current-column)))
>> Most of CJK letters count as occuping 2 columns, so the column
>> number is not equal to the number of the characters counting from
>> the beginning of a line.   (I don't know what is the correct
>> "column" parameters for evince and atril (number of letters?
>> bytes in UTF8? or other?), so don't know how we should change this
>> part.)

> I don't know, sorry.

No problem, thank you.  Then I will add some comments above the
`current-column'.

And I noticed that `(TeX-line-number-at-pos)' should be replaced with
`(1+ (TeX-current-offset))' like `TeX-current-line' does, because the
former does not return the required value for the viewer when narrowing
is in effect.

Regards,
Ikumi Keita

Message #25 received at 26694 <at> debbugs.gnu.org (full text, mbox):

From: Mosè Giordano <mose <at> gnu.org>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 26694 <at> debbugs.gnu.org
Subject: Re: bug#26694: preview-at-point fails on very long lines with "End of
 buffer"
Date: Mon, 29 May 2017 17:36:02 +0200

2017-05-29 16:33 GMT+02:00 Ikumi Keita <ikumi <at> ikumi.que.jp>:
> Gosh, these viewers use emacslient on reverse search, which ends up with
> opening _region_.tex buffer instead of the original document's buffer
> when using region file.  Then it's not so useful to arrange the
> expanders to work with region file in forward search...

Exactly.  In the case of Evince (and Atril) and pdf-tools, AUCTeX can
talk with the viewer and tell it that to go back to the original
document.  This isn't possible in other cases, where the viewers only
read the SyncTeX file, which points to _region_.tex.

Bye,
Mosè

Message #28 received at 26694 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: Mosè Giordano <mose <at> gnu.org>
Cc: 26694 <at> debbugs.gnu.org
Subject: Re: bug#26694: preview-at-point fails on very long lines with "End of
 buffer"
Date: Tue, 30 May 2017 22:50:02 +0900

[Message part 1 (text/plain, inline)]

Hi all,

Now I propose to apply the attached fix.  This doesn't change the action
of "%b" and "%n".  If no objection, I'll commit it soon.

Bye,
Ikumi Keita

[improve-fix-end-of-buffer.diff (text/x-diff, attachment)]

Message #31 received at 26694 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 26694 <at> debbugs.gnu.org, Mosè Giordano <mose <at> gnu.org>
Subject: Re: bug#26694: preview-at-point fails on very long lines with "End of
 buffer"
Date: Tue, 30 May 2017 23:09:27 +0900

[Message part 1 (text/plain, inline)]

Sorry, the previous patch contains a spurious ")" in it.  Please dismiss
it and use the attached one instead.

Bye,
Ikumi Keita

[improve-fix-end-of-buffer-revised.diff (text/x-diff, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.