bug#73854: 29.4; tex-mode: unexpected and inconsistent behaviour of `tex-compile`, `tex-file`, and `tex-view`

bug#73854: 29.4; tex-mode: unexpected and inconsistent behaviour of `tex-compile`, `tex-file`, and `tex-view`

[Thalis Charakas via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Basically, `tex-view` works, opening Evince, on a compiled .pdf only
after a .dvi is created.

Running 'emacs -Q' I evaluate the following in the scratch buffer, to
make it so that latex is compiled to pdf:
```
(setq tex-print-file-extension ".pdf"
      tex-dvi-view-command "evince"
      tex-dvi-print-command "lpr")
```
the last two lines are following the instructions on the description of
`tex-print-file-extension`.

I navigate to a simple .tex in an empty directory and press `C-c C-c`
which is bound by default to `tex-compile`, I press enter, as the
default is `pdflatex`, and the file compiles, creating a .pdf in the
directory. After that I press `C-c C-v`, which is bound to `tex-view`
but Evince does not open, instead I get the message "tex-print: No
appropriate ‘.dvi’ file could be found. If I press `C-c C-f`
(`tex-file`) after that, a .dvi file is created, and now `tex-view`
works, meaning it opens the .pdf with Evince.

The fact that `tex-view` works on the .pdf only when a .dvi is first
created seems like a bug.




In GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
 cairo version 1.16.0) of 2024-07-22, modified by Debian built on
 x86-ubc-01
Windowing system distributor 'The X.Org Foundation', version 11.0.12201009
System Description: Debian GNU/Linux 12 (bookworm)

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/libexec
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/29.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.4/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils
 --with-native-compilation --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/libexec
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/29.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.4/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils
 --with-native-compilation --with-cairo --with-x=yes
 --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
 -ffile-prefix-map=/build/reproducible-path/emacs-29.4+1=. -fstack-protector-strong
 -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2
XPM GTK3 ZLIB

Important settings:
  value of $LC_MONETARY: el_GR.UTF-8
  value of $LC_NUMERIC: el_GR.UTF-8
  value of $LC_TIME: el_GR.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: LaTeX

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils sh-script smie treesit executable files-x
format-spec tex-mode compile text-property-search shell pcomplete comint
ansi-osc ansi-color ring latexenc time-date cl-loaddefs comp comp-cstr
warnings icons subr-x rx cl-seq cl-macs gv cl-extra help-mode bytecomp
byte-compile cl-lib rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 104929 9925)
 (symbols 48 8831 0)
 (strings 32 26957 1346)
 (string-bytes 1 823130)
 (vectors 16 18588)
 (vector-slots 8 380866 9613)
 (floats 8 55 42)
 (intervals 56 359 0)
 (buffers 984 14))

bug#73854: 29.4; tex-mode: unexpected and inconsistent behaviour of `tex-compile`, `tex-file`, and `tex-view`

[Eli Zaretskii]

> Date: Thu, 17 Oct 2024 18:36:19 +0000
> From:  Thalis Charakas via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Basically, `tex-view` works, opening Evince, on a compiled .pdf only
> after a .dvi is created.
> 
> Running 'emacs -Q' I evaluate the following in the scratch buffer, to
> make it so that latex is compiled to pdf:
> ```
> (setq tex-print-file-extension ".pdf"
>       tex-dvi-view-command "evince"
>       tex-dvi-print-command "lpr")
> ```
> the last two lines are following the instructions on the description of
> `tex-print-file-extension`.
> 
> I navigate to a simple .tex in an empty directory and press `C-c C-c`
> which is bound by default to `tex-compile`, I press enter, as the
> default is `pdflatex`, and the file compiles, creating a .pdf in the
> directory. After that I press `C-c C-v`, which is bound to `tex-view`
> but Evince does not open, instead I get the message "tex-print: No
> appropriate ‘.dvi’ file could be found. If I press `C-c C-f`
> (`tex-file`) after that, a .dvi file is created, and now `tex-view`
> works, meaning it opens the .pdf with Evince.
> 
> The fact that `tex-view` works on the .pdf only when a .dvi is first
> created seems like a bug.

Thanks.  Can you step with Edebug through tex-print in your case and
try to figure out what happens there that causes the error message?
There's some logic there which is supposed to verify that the current
buffer's print file is up-to-date:

    (if (and (not (equal (current-buffer) tex-last-buffer-texed))
	     (buffer-file-name)
	     ;; Check that this buffer's printed file is up to date.
	     (file-newer-than-file-p
	      (setq test-name (tex-append (buffer-file-name)
                                          tex-print-file-extension))
	      (buffer-file-name)))
	(setq print-file-name-dvi test-name))

Maybe something goes wrong there in your case?

(I don't have the requisite tools installed to try this myself,
sorry.)

bug#73854: 29.4; tex-mode: unexpected and inconsistent behaviour of `tex-compile`, `tex-file`, and `tex-view`

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 2439 bytes --]

On Sat, 19 Oct 2024 12:54:51 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> Date: Thu, 17 Oct 2024 18:36:19 +0000
>> From:  Thalis Charakas via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> Basically, `tex-view` works, opening Evince, on a compiled .pdf only
>> after a .dvi is created.
>> 
>> Running 'emacs -Q' I evaluate the following in the scratch buffer, to
>> make it so that latex is compiled to pdf:
>> ```
>> (setq tex-print-file-extension ".pdf"
>>       tex-dvi-view-command "evince"
>>       tex-dvi-print-command "lpr")
>> ```
>> the last two lines are following the instructions on the description of
>> `tex-print-file-extension`.
>> 
>> I navigate to a simple .tex in an empty directory and press `C-c C-c`
>> which is bound by default to `tex-compile`, I press enter, as the
>> default is `pdflatex`, and the file compiles, creating a .pdf in the
>> directory. After that I press `C-c C-v`, which is bound to `tex-view`
>> but Evince does not open, instead I get the message "tex-print: No
>> appropriate ‘.dvi’ file could be found. If I press `C-c C-f`
>> (`tex-file`) after that, a .dvi file is created, and now `tex-view`
>> works, meaning it opens the .pdf with Evince.
>> 
>> The fact that `tex-view` works on the .pdf only when a .dvi is first
>> created seems like a bug.
>
> Thanks.  Can you step with Edebug through tex-print in your case and
> try to figure out what happens there that causes the error message?
> There's some logic there which is supposed to verify that the current
> buffer's print file is up-to-date:
>
>     (if (and (not (equal (current-buffer) tex-last-buffer-texed))
> 	     (buffer-file-name)
> 	     ;; Check that this buffer's printed file is up to date.
> 	     (file-newer-than-file-p
> 	      (setq test-name (tex-append (buffer-file-name)
>                                           tex-print-file-extension))
> 	      (buffer-file-name)))
> 	(setq print-file-name-dvi test-name))
>
> Maybe something goes wrong there in your case?

I debugged this and the problem is that tex-print expects the variable
tex-print-file to be set, but (as its doc string says) it is set by
tex-region, tex-buffer and tex-file, which are all not commands run by
tex-compile, which is meant to run external programs (listed by
tex-compile-commands).  A simple fix is the following patch:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: tex-compile patch --]
[-- Type: text/x-patch, Size: 461 bytes --]

diff --git a/lisp/textmodes/tex-mode.el b/lisp/textmodes/tex-mode.el
index 6fc49800018..acb5bb4b860 100644
--- a/lisp/textmodes/tex-mode.el
+++ b/lisp/textmodes/tex-mode.el
@@ -2530,6 +2530,7 @@ tex-compile
       (if (tex-shell-running)
           (tex-kill-job)
         (tex-start-shell))
+      (setq tex-print-file (expand-file-name (tex-main-file)))
       (tex-send-tex-command cmd dir))))

 (defun tex-start-tex (command file &optional dir)

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]


But I'm not familiar with the tex-mode.el code and don't know if this
change might have unwanted consequences (though it seems prima facie
safe).

Steve Berman

bug#73854: 29.4; tex-mode: unexpected and inconsistent behaviour of `tex-compile`, `tex-file`, and `tex-view`

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Thalis Charakas <thales1@protonmail.com>,  73854@debbugs.gnu.org
> Date: Sat, 19 Oct 2024 13:31:05 +0200
> 
> diff --git a/lisp/textmodes/tex-mode.el b/lisp/textmodes/tex-mode.el
> index 6fc49800018..acb5bb4b860 100644
> --- a/lisp/textmodes/tex-mode.el
> +++ b/lisp/textmodes/tex-mode.el
> @@ -2530,6 +2530,7 @@ tex-compile
>        (if (tex-shell-running)
>            (tex-kill-job)
>          (tex-start-shell))
> +      (setq tex-print-file (expand-file-name (tex-main-file)))
>        (tex-send-tex-command cmd dir))))
> 
>  (defun tex-start-tex (command file &optional dir)
> 
> But I'm not familiar with the tex-mode.el code and don't know if this
> change might have unwanted consequences (though it seems prima facie
> safe).

Thanks.

Stefan, do you agree with this fix?

bug#73854: 29.4; tex-mode: unexpected and inconsistent behaviour of `tex-compile`, `tex-file`, and `tex-view`

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> diff --git a/lisp/textmodes/tex-mode.el b/lisp/textmodes/tex-mode.el
>> index 6fc49800018..acb5bb4b860 100644
>> --- a/lisp/textmodes/tex-mode.el
>> +++ b/lisp/textmodes/tex-mode.el
>> @@ -2530,6 +2530,7 @@ tex-compile
>>        (if (tex-shell-running)
>>            (tex-kill-job)
>>          (tex-start-shell))
>> +      (setq tex-print-file (expand-file-name (tex-main-file)))
>>        (tex-send-tex-command cmd dir))))
>> 
>>  (defun tex-start-tex (command file &optional dir)
>> 
>> But I'm not familiar with the tex-mode.el code and don't know if this
>> change might have unwanted consequences (though it seems prima facie
>> safe).
>
> Stefan, do you agree with this fix?

No objections here.
Personally, I use `C-c C-c` to view the PDF (i.e. `C-c C-c` first to
compile the TeX file, then a second time to view the result).

So, maybe the patch below would also help.


        Stefan


diff --git a/lisp/textmodes/tex-mode.el b/lisp/textmodes/tex-mode.el
index 6fc49800018..f27bd1620e1 100644
--- a/lisp/textmodes/tex-mode.el
+++ b/lisp/textmodes/tex-mode.el
@@ -2212,6 +2212,7 @@ tex-compile-commands
      t "%r.dvi")
     ("xdvi %r &" "%r.dvi")
     ("\\doc-view \"%r.pdf\"" "%r.pdf")
+    ("evince %r.pdf &" "%r.pdf")
     ("xpdf %r.pdf &" "%r.pdf")
     ("gv %r.ps &" "%r.ps")
     ("yap %r &" "%r.dvi")

bug#73854: 29.4; tex-mode: unexpected and inconsistent behaviour of `tex-compile`, `tex-file`, and `tex-view`

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Sat, 19 Oct 2024 10:28:52 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>>> diff --git a/lisp/textmodes/tex-mode.el b/lisp/textmodes/tex-mode.el
>>> index 6fc49800018..acb5bb4b860 100644
>>> --- a/lisp/textmodes/tex-mode.el
>>> +++ b/lisp/textmodes/tex-mode.el
>>> @@ -2530,6 +2530,7 @@ tex-compile
>>>        (if (tex-shell-running)
>>>            (tex-kill-job)
>>>          (tex-start-shell))
>>> +      (setq tex-print-file (expand-file-name (tex-main-file)))
>>>        (tex-send-tex-command cmd dir))))
>>> 
>>>  (defun tex-start-tex (command file &optional dir)
>>> 
>>> But I'm not familiar with the tex-mode.el code and don't know if this
>>> change might have unwanted consequences (though it seems prima facie
>>> safe).
>>
>> Stefan, do you agree with this fix?
>
> No objections here.
> Personally, I use `C-c C-c` to view the PDF (i.e. `C-c C-c` first to
> compile the TeX file, then a second time to view the result).
>
> So, maybe the patch below would also help.
>
>
>         Stefan
>
> diff --git a/lisp/textmodes/tex-mode.el b/lisp/textmodes/tex-mode.el
> index 6fc49800018..f27bd1620e1 100644
> --- a/lisp/textmodes/tex-mode.el
> +++ b/lisp/textmodes/tex-mode.el
> @@ -2212,6 +2212,7 @@ tex-compile-commands
>       t "%r.dvi")
>      ("xdvi %r &" "%r.dvi")
>      ("\\doc-view \"%r.pdf\"" "%r.pdf")
> +    ("evince %r.pdf &" "%r.pdf")
>      ("xpdf %r.pdf &" "%r.pdf")
>      ("gv %r.ps &" "%r.ps")
>      ("yap %r &" "%r.dvi")

Indeed, with a suitable entry for viewing a PDF, typing `C-c C-c' twice
does the job.  In my case, however, a suitable entry is not evince,
since I don't have that program installed here, but I do have mupdf and
with an entry for it, `C-c C-c' calls it and the PDF is displayed.  So
this raises the question of whether tex-compile-commands should be
enhanced with all known free software PDF viewers, or, more
maintainer-friendly, turned into a defcustom, so users can just added
their preferred entries.  But that's a complementary issue to the
present bug report, since without my patch for tex-compile even with a
suitable entry in tex-compile-commands, `C-c C-v' (tex-view) still
complains "No appropriate ‘.dvi’ file could be found" and does not call
the program specified by tex-dvi-view-command to display the PDF.  So
should I just go ahead and install my patch?  And if so, to master or to
emacs-30 (which has the same issue)?

Steve Berman

bug#73854: 29.4; tex-mode: unexpected and inconsistent behaviour of `tex-compile`, `tex-file`, and `tex-view`

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  thales1@protonmail.com,
>   73854@debbugs.gnu.org
> Date: Mon, 21 Oct 2024 11:22:02 +0200
> 
> > diff --git a/lisp/textmodes/tex-mode.el b/lisp/textmodes/tex-mode.el
> > index 6fc49800018..f27bd1620e1 100644
> > --- a/lisp/textmodes/tex-mode.el
> > +++ b/lisp/textmodes/tex-mode.el
> > @@ -2212,6 +2212,7 @@ tex-compile-commands
> >       t "%r.dvi")
> >      ("xdvi %r &" "%r.dvi")
> >      ("\\doc-view \"%r.pdf\"" "%r.pdf")
> > +    ("evince %r.pdf &" "%r.pdf")
> >      ("xpdf %r.pdf &" "%r.pdf")
> >      ("gv %r.ps &" "%r.ps")
> >      ("yap %r &" "%r.dvi")
> 
> Indeed, with a suitable entry for viewing a PDF, typing `C-c C-c' twice
> does the job.  In my case, however, a suitable entry is not evince,
> since I don't have that program installed here, but I do have mupdf and
> with an entry for it, `C-c C-c' calls it and the PDF is displayed.  So
> this raises the question of whether tex-compile-commands should be
> enhanced with all known free software PDF viewers, or, more
> maintainer-friendly, turned into a defcustom, so users can just added
> their preferred entries.  But that's a complementary issue to the
> present bug report, since without my patch for tex-compile even with a
> suitable entry in tex-compile-commands, `C-c C-v' (tex-view) still
> complains "No appropriate ‘.dvi’ file could be found" and does not call
> the program specified by tex-dvi-view-command to display the PDF.  So
> should I just go ahead and install my patch?  And if so, to master or to
> emacs-30 (which has the same issue)?

Please install on master, and thanks.

As for the patch to tex-compile-commands, I think both evince and
mupdf entries should be added to it.  Whether to make it a defcustom
is a separate issue, with much wider consequences, and I wouldn't do
that at this time.

bug#73854: 29.4; tex-mode: unexpected and inconsistent behaviour of `tex-compile`, `tex-file`, and `tex-view`

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Mon, 21 Oct 2024 12:55:01 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  thales1@protonmail.com,
>>   73854@debbugs.gnu.org
>> Date: Mon, 21 Oct 2024 11:22:02 +0200
>> 
>> > diff --git a/lisp/textmodes/tex-mode.el b/lisp/textmodes/tex-mode.el
>> > index 6fc49800018..f27bd1620e1 100644
>> > --- a/lisp/textmodes/tex-mode.el
>> > +++ b/lisp/textmodes/tex-mode.el
>> > @@ -2212,6 +2212,7 @@ tex-compile-commands
>> >       t "%r.dvi")
>> >      ("xdvi %r &" "%r.dvi")
>> >      ("\\doc-view \"%r.pdf\"" "%r.pdf")
>> > +    ("evince %r.pdf &" "%r.pdf")
>> >      ("xpdf %r.pdf &" "%r.pdf")
>> >      ("gv %r.ps &" "%r.ps")
>> >      ("yap %r &" "%r.dvi")
>> 
>> Indeed, with a suitable entry for viewing a PDF, typing `C-c C-c' twice
>> does the job.  In my case, however, a suitable entry is not evince,
>> since I don't have that program installed here, but I do have mupdf and
>> with an entry for it, `C-c C-c' calls it and the PDF is displayed.  So
>> this raises the question of whether tex-compile-commands should be
>> enhanced with all known free software PDF viewers, or, more
>> maintainer-friendly, turned into a defcustom, so users can just added
>> their preferred entries.  But that's a complementary issue to the
>> present bug report, since without my patch for tex-compile even with a
>> suitable entry in tex-compile-commands, `C-c C-v' (tex-view) still
>> complains "No appropriate ‘.dvi’ file could be found" and does not call
>> the program specified by tex-dvi-view-command to display the PDF.  So
>> should I just go ahead and install my patch?  And if so, to master or to
>> emacs-30 (which has the same issue)?
>
> Please install on master, and thanks.

Done in commit 1f8fbae8df7.  I also updated the doc string of
tex-print-file to mention tex-compile.

> As for the patch to tex-compile-commands, I think both evince and
> mupdf entries should be added to it.

I added these in the commit as well.

>                                       Whether to make it a defcustom
> is a separate issue, with much wider consequences, and I wouldn't do
> that at this time.

Ok.  Should the OP confirm the fix before we close the bug?

Steve Berman

bug#73854: 29.4; tex-mode: unexpected and inconsistent behaviour of `tex-compile`, `tex-file`, and `tex-view`

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: monnier@iro.umontreal.ca,  thales1@protonmail.com,  73854@debbugs.gnu.org
> Date: Mon, 21 Oct 2024 12:53:39 +0200
> 
> On Mon, 21 Oct 2024 12:55:01 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Please install on master, and thanks.
> 
> Done in commit 1f8fbae8df7.  I also updated the doc string of
> tex-print-file to mention tex-compile.
> 
> > As for the patch to tex-compile-commands, I think both evince and
> > mupdf entries should be added to it.
> 
> I added these in the commit as well.

Thanks.

> >                                       Whether to make it a defcustom
> > is a separate issue, with much wider consequences, and I wouldn't do
> > that at this time.
> 
> Ok.  Should the OP confirm the fix before we close the bug?

Yeah, let's wait for a while.

bug#73854: 29.4; tex-mode: unexpected and inconsistent behaviour of `tex-compile`, `tex-file`, and `tex-view`

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Indeed, with a suitable entry for viewing a PDF, typing `C-c C-c' twice
> does the job.  In my case, however, a suitable entry is not evince,
> since I don't have that program installed here, but I do have mupdf and
> with an entry for it, `C-c C-c' calls it and the PDF is displayed.  So
> this raises the question of whether tex-compile-commands should be
> enhanced with all known free software PDF viewers, or, more
> maintainer-friendly, turned into a defcustom, so users can just added
> their preferred entries.

That's a problem, indeed, and I'm not sure how best to address it.
Just making it a `defcustom` might be OK, but the UI would be a bit
complex for the users who just want to add their favorite PDF viewer.

> But that's a complementary issue to the present bug report,

Agreed, sorry.

> So should I just go ahead and install my patch?

Yes, please.

> And if so, to master or to emacs-30 (which has the same issue)?

OT1H, it looks safe to me, but OTOH it's a long standing issue so
there's no hurry either.  Eli?


        Stefan

bug#73854: 29.4; tex-mode: unexpected and inconsistent behaviour of `tex-compile`, `tex-file`, and `tex-view`

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> OT1H, it looks safe to me, but OTOH it's a long standing issue so
> there's no hurry either.  Eli?

Scratch that question: I see I was late to the party and it's already
been answered.  Thanks!


        Stefan

bug#73854: 29.4; tex-mode: unexpected and inconsistent behaviour of `tex-compile`, `tex-file`, and `tex-view`

[Stephen Berman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Mon, 21 Oct 2024 09:33:10 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> OT1H, it looks safe to me, but OTOH it's a long standing issue so
>> there's no hurry either.  Eli?
>
> Scratch that question: I see I was late to the party

No problem, drinks are still available at the bar ;-)

>                                                      and it's already
> been answered.  Thanks!
>
>
>         Stefan