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: Mon, 06 Oct 2014 23:02:43 +0200 Message-ID: <87h9zgdi8c.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> <87d2adk63p.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1412629480 29819 80.91.229.3 (6 Oct 2014 21:04:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Oct 2014 21:04:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 06 23:04:34 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 1XbFSL-00043c-QW for ged-emacs-devel@m.gmane.org; Mon, 06 Oct 2014 23:04:33 +0200 Original-Received: from localhost ([::1]:54395 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbFSK-0000rL-UF for ged-emacs-devel@m.gmane.org; Mon, 06 Oct 2014 17:04:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56433) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbFSF-0000r9-Cn for emacs-devel@gnu.org; Mon, 06 Oct 2014 17:04:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbFSE-0007Tm-7p for emacs-devel@gnu.org; Mon, 06 Oct 2014 17:04:27 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52044) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbFSE-0007Ti-4U for emacs-devel@gnu.org; Mon, 06 Oct 2014 17:04:26 -0400 Original-Received: from localhost ([127.0.0.1]:59213 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbFS6-0004eX-C7; Mon, 06 Oct 2014 17:04:18 -0400 Original-Received: by lola (Postfix, from userid 1000) id AC036E0803; Mon, 6 Oct 2014 23:02:43 +0200 (CEST) In-Reply-To: (Richard Stallman's message of "Mon, 06 Oct 2014 15:14:42 -0400") 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:175050 Archived-At: Richard Stallman writes: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > Thanks for the explanation. Now I understand, more or less. > > If you write, say, word_text instead of word\_text (throwing LaTeX into > inadvertant math mode), the resulting nuisance overlay will need to get > manually removed (with keyboard sequence or mouse click) after > correcting the syntax error since no image will reappear in that area > after the correction. > > If you regenerate that region, and it makes no image, can't that delete > the overlay automatically? Conceivably. However, a region might just be \input{bozo} \input{clown} \input{summary} with the actual images appearing in respectively other buffers than the region. So clearing out the original region would be a heuristic rather than the full deal and should not be mandatory for satisfactory operation. > 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. > > What is the obstacle to supporting other interfaces? The job control that is used is that of AUCTeX. That involves management of various process buffers (without getting "A compilation is already in progress" problems), expansion of commands with variable elements based on the involved buffers and files. The command sequences which are executed are based on the various ways of generating graphical output from TeX input. These kind of chains are not really specified as some sort of abstract interface but hardcoded. There are sidepaths from LaTeX for geometry and source location information: Emacs parses the resulting error/log files in order to get all those out. There is no other source for this information. A lot of convenience functions from AUCTeX are used that are not actually related to TeX at all. The user interface parts are not done in any way independent from the AUCTeX user interface. > Would preview-latex be of any use with Texinfo? > Maybe not, since generally there are few equations in Texinfo. The LilyPond (music typesetter) documentation is generated via Texinfo. There are probably not all that many people using the Info version with graphical images but it beats the pants off the generally used online HTML version (all the web pages, not just the manuals, are also generated from Texinfo). But the _only_ usable reader for the Info version with graphics is Emacs. Yelp (GNOME help viewer) purports to support images in Info but does not scale to ten thousands of images. One never gets across the "Loading" message. Now the LilyPond documentation is probably the best use of images in Info anywhere. Still I would not want to bet my life savings on more than a dozen people actively using the Info variants of those manuals. But while few people actually use the Info output format, lots more use Texinfo with other backends. I could imagine the Texinfo/preview-latex combination to be popular with our documentation editors even though most of them probaly have never looked at Info output and consider HTML and PDF the "normal" output formats. -- David Kastrup