[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ikumi Keita
Subject: bug#26694: preview-at-point fails on very long lines with "End of buffer"
Date: Mon, 29 May 2017 23:33:11 +0900


>>>>> Mosè Giordano <address@hidden> 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

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.

Ikumi Keita

reply via email to

[Prev in Thread] Current Thread [Next in Thread]