No keyboard control for built-in PDF viewer.

[tgvaughan]

LiTeX is a nice and useful plugin (thanks!), but I can't seem to navigate preview of the document being edited with the keyboard.

[rschroll]

That's correct. The only command that navigates the preview is the
forward sync command. It's not bound to any keystroke, but you could
change that in your user keymaps file.

Other than that, what sort of navigation would you want? LiTeX will
never provide a full-featured PDF viewer, but we can a few navigation
commands if that would help people.

[tgvaughan]

I understand not wanting to provide a full PDF viewer, although the one you have is already fairly impressive. The only thing I think it really needs is the ability to page up/down and line up/down via the keyboard. Not being able to do this is pretty debilitating for users accustomed interacting with text editors solely via the keyboard!

[rschroll]

I'm assuming that you don't want to have to put keyboard focus in the
previewer for this to work. I think the best approach would be to make
some new commands (page up, page down, line up, line down) and let the
user choose their own shortcut keys through their user keymap. Does
that sound reasonable to you?

I can't swear I'll get to this on any sort of timetable. If anyone is
interested in attacking this, I'm happy to provide guidance.

[tgvaughan]

Hi @rschroll , absolutely - although requiring focus is fine. It's already possible to switch focus between tabsets via the keyboard (with the appropriate bindings in place).

Of course ideally I'd be sending you a pull request rather than raising an issue! Sorry about that.

[rschroll]

No worries. I can barely read the clojurescript that I've written. I
don't expect anyone else to be able to make heads or tails of it.

I originally thought the command approach would be easiest, since we
wouldn't have to muck about with any event handling ourselves. But
I've realized that we could have multiple viewers open, so we'd have to
decide which one should get the commands. The way to solve this would
be to have the command go through the litex.cljs file, much like the
forward sync command does. This would trigger a behavior in the viewer
itself that would actually reposition the view.

In light of this, it may actually be easier to trap keystrokes in the
viewer's HTML and handle them right there. This might also let us
handle the arrow keys and page up/down. (Though that depends on
details of HTML key events that I don't remember.) The model here
would be the ::mouse-wheel! behavior in litex-viewer.cljs, but with
onmousewheel replaced with onkeypress or onkeydown. If you haven't
dealt with Light Table's code before, this would probably be a lot
easier to attack. My only worry is that you might end up fighting
Light Table for control of keystrokes.

Either approach would be fine with me. If anyone starts working on it,
please let me know so we can avoid duplicated effort.