From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Overlay mechanic improvements Date: Tue, 30 Sep 2014 18:20:06 +0200 Organization: Organization?!? Message-ID: <871tqtjd1l.fsf@fencepost.gnu.org> References: <871tr6qup8.fsf@fencepost.gnu.org> <87ppepne6d.fsf@fencepost.gnu.org> <87mw9smxaz.fsf@fencepost.gnu.org> <87sijii1cd.fsf@fencepost.gnu.org> <87vbo7j7yy.fsf@fencepost.gnu.org> <87a95hx5re.fsf@uwakimon.sk.tsukuba.ac.jp> <8761g5jy6e.fsf@fencepost.gnu.org> <87iok5cs6b.fsf@gmx.us> <83sij9kx2r.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1412094044 19509 80.91.229.3 (30 Sep 2014 16:20:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Sep 2014 16:20:44 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 30 18:20:38 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XZ0AI-0006zH-Cq for ged-emacs-devel@m.gmane.org; Tue, 30 Sep 2014 18:20:38 +0200 Original-Received: from localhost ([::1]:44323 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZ0AH-0000ou-WA for ged-emacs-devel@m.gmane.org; Tue, 30 Sep 2014 12:20:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZ0A7-0000nl-R4 for emacs-devel@gnu.org; Tue, 30 Sep 2014 12:20:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XZ09y-0005NC-TL for emacs-devel@gnu.org; Tue, 30 Sep 2014 12:20:27 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:42503) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZ09y-0005Mr-K9 for emacs-devel@gnu.org; Tue, 30 Sep 2014 12:20:18 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XZ09x-0006qv-Iv for emacs-devel@gnu.org; Tue, 30 Sep 2014 18:20:17 +0200 Original-Received: from x2f3b83d.dyn.telefonica.de ([2.243.184.61]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Sep 2014 18:20:17 +0200 Original-Received: from dak by x2f3b83d.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 30 Sep 2014 18:20:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 95 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f3b83d.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) Cancel-Lock: sha1:bDU+ktyVr4h4XhldOcjzJoF+lQU= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:174869 Archived-At: Eli Zaretskii writes: >> From: Rasmus >> Date: Tue, 30 Sep 2014 12:35:08 +0200 >> >> > preview-latex does an excellent job, but much of its code is not at all >> > related to the AUCTeX user interface or the LaTeX input language, and >> > yet it will work for nothing but the AUCTeX user interface and the LaTeX >> > input language. >> > >> > And without generally available facilities to do that sort of work, it >> > will remain a singularly useful application without peers. Because it's >> > far too much work to do a peer from scratch for similar needs. It was >> > supposed to make it easier for me to work on my PhD thesis, but I ended >> > up doing it _instead_ of my PhD thesis. >> > >> > The main shortcoming of preview-latex in my book is that it stands out. >> > It should be one of possibly many thin applications on top of rendering >> > frameworks provided by Emacs proper. >> >> I agree wholeheartedly. Org has a similar mechanism as well, but it >> *sucks* compared to preview-latex. I tried to get >> preview-latex working with Org (which uses LaTeX-syntax for math), but >> it was non-trivial. Thus, I don't interact much with preview-latex >> these days, but I have very fond memories of using it. >> >> If you ever decide to allocate time to generalize preview-latex and >> have it shipped with Emacs-core I'd happily support that work! > > Feel free to expand on the problem(s) you hint on, because just by > reading this exchange, I don't really understand what kind of > facilities are missing in the core. (I don't use preview-latex and > probably never will.) Since preview-latex is trivial to install via ELPA (as it's included in AUCTeX), I am somewhat at a loss figuring out what point people are trying to make by stating that they are not going to bother looking at it, preferring me to type descriptions for hours. There is a paper sketching the working mode of preview-latex some more. But the problem is that static images/screenshots are not really much help in seeing how the generation of images is actually integrated into the interactive workflow. The screenshots would not have looked significantly different after the first prototype was running, so they don't really do a lot more than give the information "Emacs can show images". I found some conference video Kaveh Bazargan made of me at , picture quality pretty flaky. While it does not really say a lot about the Emacs parts of the process, it is pretty obvious that the editing is not at all disturbed by the images and that any images are regenerated instantaneously without any obvious delays or interference with the editing workflow. That's probably 2007 or 2008, so the processor I use is probably something like 600MHz. Emacs does not offer any default support for rendering images on-demand from source code in a buffer. The pipelines that preview-latex can be something like buffer -> LaTeX -> Dvips -> Ghostscript -> PNG buffer -> PDFLaTeX -> pdftodsc -> Ghostscript -> PNG buffer -> LaTeX -> Dvipng -> PNG It will also run several of those in parallel, like running LaTeX->Dvipng but falling back to Dvips->Ghostscript for those images which contain embedded PostScript. The Ghostscript pipeline will render the on-screen images first to make for better interactive response. In addition to the images, LaTeX produces geometry, baseline, source location and various other info (for example, default font size in order to match the rendering scale to the current default screen font) which is parsed by Emacs and used for integrating the resulting images in the right place and scale into the originating buffer. So there are prioritized rendering pipelines and information side paths that deliver information crucial for tying the image stream back into the proper buffer locations, with proper scale and baseline. There is other stuff like being able to paste text plus images into MIME mails (with the obvious loss of baseline and other formatting information, but for display math it is somewhat helpful), and desktop mode saving and restoring the images associated with a buffer. All of that is not specific to LaTeX, and Emacs does not really provide anything helpful for creating that kind of facility apart from the display feature itself and the possibility to run processes and process filters. -- David Kastrup