litex icon indicating copy to clipboard operation
litex copied to clipboard

No keyboard control for built-in PDF viewer.

Open tgvaughan opened this issue 10 years ago • 5 comments

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

tgvaughan avatar Sep 20 '15 23:09 tgvaughan

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.

rschroll avatar Sep 21 '15 18:09 rschroll

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!

tgvaughan avatar Sep 21 '15 22:09 tgvaughan

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.

rschroll avatar Sep 22 '15 01:09 rschroll

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.

tgvaughan avatar Sep 22 '15 01:09 tgvaughan

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.

rschroll avatar Sep 22 '15 02:09 rschroll