From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Overlay mechanic improvements Date: Tue, 30 Sep 2014 10:21:25 +0900 Message-ID: <87a95hx5re.fsf@uwakimon.sk.tsukuba.ac.jp> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1412040148 30401 80.91.229.3 (30 Sep 2014 01:22:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Sep 2014 01:22:28 +0000 (UTC) Cc: David Kastrup , emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 30 03:22:21 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 1XYm8v-00087G-7a for ged-emacs-devel@m.gmane.org; Tue, 30 Sep 2014 03:22:17 +0200 Original-Received: from localhost ([::1]:39959 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XYm8u-0000K4-Ij for ged-emacs-devel@m.gmane.org; Mon, 29 Sep 2014 21:22:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38969) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XYm8l-0000J2-6O for emacs-devel@gnu.org; Mon, 29 Sep 2014 21:22:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XYm8d-0001NM-OE for emacs-devel@gnu.org; Mon, 29 Sep 2014 21:22:07 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:45808) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XYm8V-0001LQ-Bu; Mon, 29 Sep 2014 21:21:51 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id F0A521C391C; Tue, 30 Sep 2014 10:21:25 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E29D21A2697; Tue, 30 Sep 2014 10:21:25 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:174822 Archived-At: Richard Stallman writes: > > Does this mean you turn off display of the image on the > > overlay when the text in that region is changed? > > 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. > > I see. > > 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.) In most cases the object is something, such as an equation, which is marked by explicit delimiters, so unless you actually delete the delimiters or add new ones, it makes sense to keep the overlay which provably still contains the correct boundaries[1], rather than re-parse the relevant region, and change only the image associated with the delimited object at next request for the formatted display. Unlike a fundamentally WYSIWYG application, preview-latex provides no facility for displaying syntactically incorrect formatted output.[2] Instead, preview-latex gets out of the user's way, and allows them to take advantage of AUCTeX's[3] features to ensure syntactically correct source editing, then provides immediate feedback as to whether the input LaTeX code is *semantically* correct. Ie, the source entered displays as the user expects. Because it is based on the device-independent rendering system which will be used to produce formatted content, this feedback is as accurate as possible in most cases. Compare with WYSIWYG office suites, which typically not only produce ugly math, but produce *different* ugliness on different devices. They even auto-bogotify macro features like whether a table gets split across pages depending on whether it's output to screen or to a printer. In preview-latex, Emacs is at its text-editing best. Footnotes: [1] And it in theory could provide "protection" for the delimiters against inadvertant corruption, although AFAIK such a feature has not been added. [2] Eg, if you are entering a superscript, theoretically a WYSIWYG editor could provide a transient raised text-entry field and move the cursor there. I don't know if any actually do that. [3] AFAIK, preview-latex is heavily dependent on AUCTeX features, although it probably could be ported to other TeX modes, even *ML modes, with a more or less great expenditure of effort.