[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 |
Hi!
>>>>> 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
`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