#1283 Reading bar not shown and forward synchro fails under recent 1.4.38 on macOS 10.14.1
I jump from .tex files to the line in the corresponding .pdf within Emacs. This worked well for several years. After a recent update of Skim, this 'forward synchronization' did not work anymore, and after every change of the .pdf, the .pdf reloaded on page 1 (instead of the page where I was). After realizing this behavior, I updated Skim today, to version 1.4.38 and saw in the log that this problem was addressed. However, I realized that forward synchronization still does not work. To this end, I tell emacas to run /Applications/Skim.app/Contents/SharedSupport/displayline -b -g 100 foo.pdf foo.tex ('100' = line number to jump to, 'foo.pdf' the .pdf file and 'foo.tex' the corresponding .tex -- they are all variables but should be expanded like this). If I now (after updating to 1.4.38) run this command in the terminal, it opens up Skim with foo.pdf, but shows it on the first page and no line is highlighted/shows a reading bar. Unless there was a change in 'displayline', I assume this is a (related) bug.
Related
You seem to use displayline in combination with auto reload. That won't
work, it is fragile, because there is no way to control the order in which
the navigation and the reload occur. In fact it will probably be the wrong
way around. You should turn off auto sync and use -r with displayline.
Hi,
thanks for helping. I switched off "Check for file changes" and
"Reload automatically" in the Skim Preferences (under 'Sync')
and used '-r' in my displayline call. Nothing changed. Neither is the
reading bar shown, nor is the pdf opened on the right
page. I also tried with checking "Check for file changes" but
unchecking "Reload automatically", same behavior.
Can you reproduce this bug in the terminal with the command I provided?
Thanks & cheers,
M
On Sun, Nov 25, 2018 at 6:13 AM Christiaan Hofman
hofman@users.sourceforge.net wrote:
Related
Bugs:
#1283I cannot reproduce this. For me displayline works as expected, going to the correct page and showing the reading bar. But it may be a problem with 10.14.1, which I don't have yet, as my 10.14-capable laptop is being repaired.
You say there is no reading bar. Do you mean that you don't see the reading bar, or it is not there at all? E.g. might the reading bar be drawn on the page where it should have navigated to? And does the View menu have an item Show Reading Bar or Hide Reading Bar?
And another thing, if you don't use -b, does it go to the correct page?
Hi,
We are getting closer. Okay, so the View menu has the entry "Show
Reading Bar". When I click it, it displays the yellow bar on the first
page, first line and the entry switches to "Hide Reading Bar".
However, when I call displayline from the terminal, it does not show
the reading bar in the .pdf and the entry in the View menu shows "Show
Reading Bar" again, so the setting to show the reading bar is not
persistent.
If I omit the -b option, nothing changes, in particular, it doesn't
jump to the right page/line.
Cheers,
M
Unfortunately we're not getting any closer. The reading bar is always removed when the document is reloaded, because its parameters depend on the document content, so they become invalid. However it should be added again if you pass the -b option. If it doesn't, and the document does not scroll, this probably means that the document is not (fully) loaded yet when we try to do that. This probably means that 10.14.1 loads the document significantly slower, perhaps with a delay. That is a bad sign, as I have no idea how to work around that. We aready do have some delay in the actual scrolling and showing the reading bar. But there is really no way to figure out whether the document is or will be reloaded, or when it is ready to work with. This is a significant regression in 10.14.1, probably with no solution.
That would indeed be bad. As far as I know, Skim is the only PDF
viewer on macOS which provides forward/backward synchronization from
Emacs. Everyone I know works with Emacs + AUCTeX and Skim under macOS.
I suggest we wait and see until you can check it under 10.14.1.
Perhaps there is a side-effect on my system or perhaps you'll see a
workaround. In that case, I'm more than happy to test.
Thanks for your help.
Cheers,
M
If you just run the displayline script from the command line, with or without any reload, does it work?
No. Neither by changing the file, nor by changing the optional
arguments. If the .pdf is already open and in the background, it comes
to the foreground but remains on the same page. If the .pdf is not yet
open, Skim opens and displays the .pdf on the first page. (I also
rebooted after the update of Skim and once did a 'Reset All'
preferences, but obtain the same behavior).
On Mon, Nov 26, 2018 at 5:57 AM Christiaan Hofman
hofman@users.sourceforge.net wrote:
Related
Bugs:
#1283Hi,
... I did another reboot and cleaned all files. And, to my surprise,
it worked again, exactly the way it always worked: With "Check for
file changes" enabled, "Reload automatically" disabled, and
displayline with options -b -g. That's very odd, but of course good
news.
For Emacs users: I use...
(setq TeX-view-program-list
'(("Skim" "/Applications/Skim.app/Contents/SharedSupport/displayline
-b -g %n %o %b"
"/Applications/Skim.app/Contents/SharedSupport/displayline")))
(setq TeX-view-program-selection '((output-pdf "Skim") (output-dvi "Skim")))
... to get forward synchronization with C-c C-v when setting 'PDF-TeX
Sync support' to 'Preset: Emacs' (see Skim Preferences).
... and better do a complete reboot, delete all temporary files and
recompile all .tex files to .pdf after an update to 10.14.1.
Cheers,
M
Weird. Perhaps your synctex file was corrupted?
Anyway, it triggered me to make some improvements to the reading bar in combinations with reloads, like restoring it.