bug-auctex
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22610: Auctex doesn't work with Atril (Mate's version of evince)


From: Tassilo Horn
Subject: bug#22610: Auctex doesn't work with Atril (Mate's version of evince)
Date: Thu, 11 Feb 2016 06:33:06 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.6.0.11 (build: 24000020)

TeX-source-correlate-sync-source has no viewer specifics in it, so why shouldn't we be allowed to register it for the SyncSource signals of both Evince and Atril?

Bye,
Tassilo


On February 10, 2016 23:20:06 Mosè Giordano <address@hidden> wrote:

Hi Tassilo,

2016-02-10 17:42 GMT+01:00 Tassilo Horn <address@hidden>:
Mosè Giordano <address@hidden> writes:

Yes, I'll have a look but probably not today anymore.

Well, probably having the patch really attached would be better ;-)

Ah, I've thought that was an incapability of my mobile email client. :-)

Anyway, with respect to the patch: I don't like that the "Evince" viewer
entry might call either Evince or Atril depending on the value of
`TeX-evince-gnome'.  Mate users don't need to know that Atril is a fork
of Evince.  And maybe some users may want to use both Evince and Atril.

So I'd rather have two separate viewer entries for Evince and Atril, and
those would call `TeX-evince-dbus-p' with the right app and desktop
environment name, and then return `TeX-evince-sync-view' or
`TeX-atril-sync-view' where these two are just

  (defun TeX-evince-sync-view ()
    (TeX-evince-sync-view-1 "evince" "gnome"))

  (defun TeX-atril-sync-view ()
    (TeX-evince-sync-view-1 "atril" "mate"))

and `TeX-evince-sync-view-1' is the `TeX-evince-sync-view' from your
patch with 2 additional args providing the information of the now
unneeded `TeX-evince-gnome'.

WDYT?

My main reason to keep a single entry in
`TeX-view-program-list-builtin' was to avoid code duplication, but you
persuaded me to have two entries.  The only problem I'm facing is
`TeX-source-correlate-mode': it's a minor mode, doesn't take
arguments, how can it decide which viewer register the signal for?
Should it try with both and stop at the first one working?  What
happens in the unlucky case one has both viewers but wants to use the
second one tested by `TeX-source-correlate-mode'?  Or, say, use one
for DVI and the other one for PDF?

I was thinking about keeping `TeX-evince-name' as a defvar (instead of
a defcustom) set inside `TeX-view-program-list-builtin', but the
second element of each entries is evaluated at loading time, with the
result `TeX-evince-name' is set to the value of the last viewer in the
list (that was Atril during my test, luckily, so that I was able to
notice this problem).

Anyway, the body of `TeX-source-correlate-mode' is executed when the
mode is enabled, most often at loading time, when the mode is turned
on by default with AUCTeX, so it has to look at some previously set
variable.  `TeX-view-program-selection' is a good candidate for this,
but what should look exactly?  (cadr (assoc 'output-pdf
TeX-view-program-selection))? Or (cadr (assoc 'output-dvi
TeX-view-program-selection))?  Or both?  Else?

Bye,
Mosè








reply via email to

[Prev in Thread] Current Thread [Next in Thread]