Usandoesta respuesta He podido hacer que emacs, syntex y evince funcionen juntos casi perfectamente para admitir la búsqueda directa (archivo tex -> pdf) y la búsqueda inversa (pdf -> archivo tex). Lo único que me falta es la compatibilidad con la búsqueda en varias copias abiertas del pdf.
Más detalladamente, cuando escribo artículos técnicos tengo la costumbre de tener abiertas varias copias del pdf (usando ctrl+n dentro de evince para abrir una copia), pero cuando hago esto, la copia abierta ya no se vincula a emacs. Es decir, Ctrl+clic funciona en el pdf original abierto desde emacs, mientras que Ctrl+clic dentro de la copia abierta (creada haciendo Ctrl+n dentro de evince) no tiene ningún efecto.
Supongo que esto podría ser más un problema de evidencia que de emacs, pero mi pregunta es ¿cómo puedo hacer que funcione la búsqueda inversa desde el segundo pdf?
Respuesta1
Esto está inspirado en ttbla propia solución. El código que registra emacs en la señal dbus está en la función TeX-source-correlate-modey tiene este aspecto:
(dolist (de-app '(("gnome" "evince") ("mate" "atril") ("x" "reader")))
(when (TeX-evince-dbus-p (car de-app) (cadr de-app))
(dbus-register-signal
:session nil (format "/org/%s/%s/Window/0" (car de-app) (cadr de-app))
(format "org.%s.%s.Window" (car de-app) (cadr de-app))
"SyncSource"
'TeX-source-correlate-sync-source)))
Entonces (como solución hacky) puedes simplemente ejecutar el mismo código 0reemplazado ipor tantas iventanas como creas que tendrás abiertas al mismo tiempo.
Entonces, en total, puse lo siguiente en mi .emacsarchivo:
(defun my/add-ten-more-synctex-windows ()
(dotimes (i 10)
(dolist (de-app '(("gnome" "evince") ("mate" "atril") ("x" "reader")))
(when (TeX-evince-dbus-p (car de-app) (cadr de-app))
(dbus-register-signal
:session nil (format "/org/%s/%s/Window/%d" (car de-app) (cadr de-app) (1+ i))
(format "org.%s.%s.Window" (car de-app) (cadr de-app))
"SyncSource"
'TeX-source-correlate-sync-source)))))
(add-hook 'LaTeX-mode-hook 'TeX-source-correlate-mode)
(add-hook 'LaTeX-mode-hook 'my/add-ten-more-synctex-windows)
Respuesta2
Resolví esto editando el código de atril. Tenga en cuenta que también puede existir una solución basada en emacs aún por encontrar.
Un poco de información sobre cómo funciona la interacción emacs <--> atril con respecto a las búsquedas de pdf -> tex. En emacs, escuchamos mensajes en la ruta dbus "/org/mate/atril/Window/0", y atril envía mensajes en la ruta dbus "/org/mate/atril/Window/N" donde N es el window_id de el documento (el window_id se incrementa cada vez que hacemos Ctrl+N para abrir una copia).
Por lo tanto, el problema es que las copias envían mensajes en una ruta dbus que emacs no escucha. Una forma pirateada de hacer que esto funcione es simplemente hacer que atril siempre envíe los comandos synctex en la ruta "/org/mate/atril/Window/0", independientemente del window_id.
Para hacer esto: ubique ev_window_sync_sourceen ev-window.c y modifique los argumentos de la g_dbus_connection_emit_signalllamada a la función que aparece en esa función. En concreto, basta con sustituirlo window->priv->dbus_object_pathpor g_strdup_printf (EV_WINDOW_DBUS_OBJECT_PATH, 0). (Esto se aplica al código atril 1.18.5 disponible en github)
Respuesta3
La solución anterior de Joj es muy buena. Pero va en una dirección, es decir, múltiples ventanas de evince apuntan a múltiples buffers de emacs. ¿Es posible ampliar la solución para que también vaya en sentido inverso, es decir, si hago clic en un búfer de emacs específico, se accede a una ventana de evince específica? En este momento, cuando hago clic en cualquiera de los buffers de emacs, solo va a la ventana de evince original y no a la copia de la ventana de evince. [Lo siento: esto es una pregunta/comentario, no una respuesta]