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 10:43:37 +0200 Message-ID: <8761g5jy6e.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1412066653 8462 80.91.229.3 (30 Sep 2014 08:44:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Sep 2014 08:44:13 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 30 10:44:06 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 1XYt2T-0007m9-UV for ged-emacs-devel@m.gmane.org; Tue, 30 Sep 2014 10:44:06 +0200 Original-Received: from localhost ([::1]:41599 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XYt2T-0008EY-Gu for ged-emacs-devel@m.gmane.org; Tue, 30 Sep 2014 04:44:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47683) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XYt2G-0008ET-Q5 for emacs-devel@gnu.org; Tue, 30 Sep 2014 04:43:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XYt2F-0003P3-7q for emacs-devel@gnu.org; Tue, 30 Sep 2014 04:43:52 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51167) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XYt2F-0003Og-4F for emacs-devel@gnu.org; Tue, 30 Sep 2014 04:43:51 -0400 Original-Received: from localhost ([127.0.0.1]:58343 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XYt22-0008HD-5B; Tue, 30 Sep 2014 04:43:38 -0400 Original-Received: by lola (Postfix, from userid 1000) id 90E65E0525; Tue, 30 Sep 2014 10:43:37 +0200 (CEST) In-Reply-To: <87a95hx5re.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Tue, 30 Sep 2014 10:21:25 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:174832 Archived-At: "Stephen J. Turnbull" writes: > Richard Stallman writes: > > > > Does this mean you turn off display of the image on the > > > overlay when the text in that region is changed? > >=20 > > Very much so, yes. Changing the text in the region would be a > > pain if you could not see it, and changing it breaks the > > correspondence between text and image anyway. > >=20 > > I see. > >=20 > > But you keep the overlay in existence -- how come? > > Why do you care? David knows his business, isn't that good enough? > (These are real questions, not an attack. It would be easier to > answer your questions informatively if we knew where you are going.) Well, there are, of course, places where one might want to go. Historically, preview-latex was inspired by Emacs=A021'st upcoming ability to integrate EPS images into a buffer, with a proof-of-concept up in about a week. Getting the whole thing to work as one smooth application took quite more than a man-year and a number of collaborateurs, however. And part of the reason for that is that is that a lot of functionality had to be implemented from scratch to be usable: static screenshots don't really reflect the interactive nature and efficiency with which one could work on complex documents with 1000+ equations while having a single 200MHz processor at one's disposal. One key element is using DSC comments in the generated single PostScript file for out-of-order rendering of images: Emacs entertains a pipeline into a Ghostscript process that first gets all on-screen images converted into PNG graphics before it reverts to conversion of the remaining off-screen material. If the on-screen regions change, the rendering pipeline switches the workload accordingly. With today's processors, it is actually hard to see that effect in action, but at the time it was implemented, scrolling around in a partially rendered buffer lead to an xroach-like effect where changes in the window lead to new images scurrying in until the display was static again. This sort of display-oriented rendering pipeline is not in any way specific to working with TeX/LaTeX. It is infrastructure that would be nice for a whole lot of things. In its current form, the code works in AUCTeX's LaTeX mode. It does not work for Emacs' builtin TeX modes, not even its LaTeX mode (mostly because of being tied in the process management and keymaps of AUCTeX). It does not work for AUCTeX's TeX or Texinfo modes (and the latter would be nice for working on GNU LilyPond which uses lots of images in its manuals generated from source code in the manuals). It does not work for calc's TeX output (which would increase its readability and usability significantly). It does not work for other image-generating modes like LilyPond-mode. I=A0think that something like some Maxima-mode or similar copied an early version of preview-latex in order to implement some similar functionality. It's probably fallen victim to bitrot long ago. 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. Like I said: the barely-workable proof-of-concept (good for screenshots but not actual work) took about a week. The ideal state of Emacs would be that implementing similar functionality for a comparable text input language that can be rendered into PostScript graphics with DSC comments (a non-trivial subset) or into PNG images or whatever, would take about that long. That would get us to see a whole lot more editing modes with supplementary graphic support. That this shortcoming of Emacs can be cured on the Elisp side alone (as preview-latex does not need more than a working Emacs=A021 binary) does not make it less of a shortcoming. --=20 David Kastrup