rlharris, on 2019-04-20 : > On 2019.04.19 20:24, David Wright wrote: > > But it's interesting to see that you're (still) using a DVI workflow: > > any particular reason for this? I suspect a majority are using one of > > the direct-to-PDF workflows, like pdflatex or lualatex. > > I use this workflow simply because it is the only Linux > workflow with which I am familiar. Migration to Linux was > motivated by one of the few genuine Y2K bugs; MS Word 5.0 for > DOS, which was the last rodent-free version, began writing > garbage to the document file. I abandoned multiple dozens of [snipped long, yet interesting and informative, story.] > > A few months ago I learned about latexmk, and used it > successfully with the -pcv option in Debian 8; that worked > well, providing all the output files I need, in addition to an > xdvi file which I use as I compose. But when I installed > Debian 9, this instability problem appeared, making latexmk > unusable.
Good Day, Thank you for the history you are sharing! I suppose we could find alternative worklflows well established in recent Debian versions. If you wish to stick to DVI, it would be possible to render these files directly into emacs apparently, but I don't know if there is a setup similar to the -pvc option of latexmk; I am not an Emacs user. Anyway, this functionality is documented here, if you need more details: https://www.gnu.org/software/emacs/manual/html_node/emacs/Document-View.html#Document-View Otherwise, on my side, I'm using a Makefile for my PDF based workflow. On the PDF viewing side, I use zathura and keep it open on a side window; when the document updates, zathura reloads it automatically. I believe viewers such evince will do this kind of job very well too. Finally the main environment I use to do such a job is Debian 9, using Xfce, and without much issue worth nothing for almost two years (well except maybe the few occasions where zathura got stuck, after redraw attempts on not well formed PDF documents). I will move this work environment to Debian 10 once it becomes Stable. Basically I put a Makefile in the directory in which I typeset my LaTeX document, and when I want to see changes, I save the document and run the simple command "make". Knowing Emacs by reputation, I'm pretty much certain that there is a shortcut for doing the "save and run `make`" step in one shortcut (M-x compile perhaps). Initially, my directory would have the two following files: $ ls Makefile my_document.tex The corresponding Makefile would look like the following one which you can use as a template. Careful when copy and pasting, as indentation using <Tab> instead of spaces is important: # ==================== BEGIN "Makefile" ==================== DOCUMENT = my_document.tex # Use this variable if the document includes other files INCLUDES = # ex: chapter1.tex picture.png docs/datasheet.pdf pdf: $(DOCUMENT:.tex=.pdf) # Swap thes two lines, if you want to all: pdf ps # build all every time you type make ps: $(DOCUMENT:.tex=.ps) %.pdf: %.tex $(INCLUDES) @ pdflatex -draftmode $< \ && pdflatex $< %.ps: %.pdf @ pdf2ps $< clean: @ rm -vf *.log *.aux *.toc mrproper: clean @ rm -vf $(DOCUMENT:.tex=.pdf) $(DOCUMENT:.tex=.ps) .PHONY: all pdf ps clean mrproper # ==================== END "Makefile" ==================== This Makefile will trigger rebuilds of LaTeX twice, to include changes to cross references properly. The use of -draftmode speeds-up the first build, as it does not touch the pdf, only auxiliary files. If several files are included for producing the final document, put their names in the INCLUDE variable, so that their changes are taken in account too. It is not perfect, but does the job. To trigger said rebuild from the command line, first save your file, then use: $ make Then, pdflatex runs, the PDF is produced, and zathura, or evince, redraws the document automatically, should no error occur. Once you are happy with your document, run the following to produce all your version (here the PS file) of the document, ready for publication: $ make all Once you are done, you can run the following command to clean up all the LaTeX files left over the place: $ make clean removed 'my_document.log' removed 'my_document.aux' In case something goes wrong and your document builds are stuck, you can also take advantage of the mrproper target to start anew: $ make mrproper removed 'my_document.log' removed 'my_document.aux' removed 'my_document.pdf' removed 'my_document.ps' David Wright, on 2019-04-20: > On Fri 19 Apr 2019 at 18:10:14 (-0500), rlhar...@oplink.net wrote: > > On 2019.04.19 17:33, Étienne Mollier wrote: > > > Are you running your Xfce desktop with or without the > > > compositor ? > > > > I found the menu; ENABLE DISPLAY COMPOSITING was checked. I > > was unaware of the "tweaks" menu. > > That's the sort of thing I can't interpret (as a DE non-user), > but it could be related to the previous paragraph. (That's just > a guess.) If you uncheck it, you may discover the xdvi redraw I mentioned, under the form of a flickering when you hover the DVI document with a window. The compositor keeps in memory the content of every window, older behaviour without compositor was to recompute the content of windows each time they were uncovered. If xdvi has been programmed initially to work with these X events, then deactivating the compositor could help perhaps. > The gnome approach must appeal to the video gamer; As a, formerly, heavy video gamer, I say: "No". Every CPU cycle counts. Gnome interferes too much with the OpenGL layer; I lose a bit more FPS after every releases. My window manager for such purpose is dwm for a few years. :) Kind Regards, -- Étienne Mollier <etienne.moll...@mailoo.org>