I just noticed you removed the -s option. That raises a few design

First of all, when removing -s, the "zathura->synctex.enabled"
configuration variable becomes obsolete.
The question now becomes, how do you enable synctex? I see two options
(not counting the original solution with the -s flag):

1) synctex is implicitly enabled when -x is passed, disabled when -x is
not passed
That's what the documentation commend for
zathura_set_synctex_editor_command implies, but not what this function
actually does, since it doesn't set the enabled flag ;)
Using that solution, all "zathura->synctex.enabled" tests can be
replaced by null checks on "zathura->synctex.editor" (or alternatively
the enabled variable must be set in zathura_set_synctex_editor_command).
But that way prevents running synctex without the -x flag (that is, in
stdout mode). The question is, does it even make sense to run synctex
from within zathura without -x?

2) synctex is always enabled
That means all "zathura->synctex.enabled" tests would just go away.
The original intent of the -s flag was to not modify zathura behavior at
all when synctex is disabled. The question here is, does it harm anyone
when synctex can not be disabled completely? As I see it, the worst that
would happen is that at every ctrl-click, synctex fails to run, possibly
producing something on stderr.

The next question is: How should that interact with forward synchronization?
With option 2) its simple, just enable it at all times. With option 1),
we need some way to enable forward synchronization without using
backward synchronization. Or it could just be enabled at all times
regardless of the backward synchronization options. From a UI point of
view, forward synchronization is a lot less invasive, it would just add
a new : command.

Before I go on writing the patches for forward synchronization and
documentation, I'd like to hear some opinions about that.
zathura mailing list

Reply via email to