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, 23 Sep 2014 01:50:28 +0200 Message-ID: <87ppenjjuj.fsf@fencepost.gnu.org> References: <871tr6qup8.fsf@fencepost.gnu.org> <87y4tdnkro.fsf@fencepost.gnu.org> <87r3z4mxvx.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1411430493 7947 80.91.229.3 (23 Sep 2014 00:01:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 23 Sep 2014 00:01:33 +0000 (UTC) Cc: emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 23 02:01:26 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 1XWDXp-0007Vp-Tq for ged-emacs-devel@m.gmane.org; Tue, 23 Sep 2014 02:01:26 +0200 Original-Received: from localhost ([::1]:50016 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWDXp-0002gG-Gq for ged-emacs-devel@m.gmane.org; Mon, 22 Sep 2014 20:01:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWDXh-0002fX-W6 for emacs-devel@gnu.org; Mon, 22 Sep 2014 20:01:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWDXc-0008Qg-Hn for emacs-devel@gnu.org; Mon, 22 Sep 2014 20:01:17 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43935) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWDXc-0008Pn-Fh for emacs-devel@gnu.org; Mon, 22 Sep 2014 20:01:12 -0400 Original-Received: from localhost ([127.0.0.1]:50938 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWDNX-0001Ff-NL; Mon, 22 Sep 2014 19:50:48 -0400 Original-Received: by lola (Postfix, from userid 1000) id DBC93E620D; Tue, 23 Sep 2014 01:50:28 +0200 (CEST) In-Reply-To: (Richard Stallman's message of "Mon, 22 Sep 2014 19:11:31 -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:174664 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. ]]] > > > Why not? If the images are thought of as part of the buffer contents, > > They most emphatically aren't. Search and replace works on the > underlying text (invalidating the image when a replace happens), > incremental search works on the underlying text (temporarily removing > the image), saving saves the underlying text, all editing commands apply > to the underlying text. > > Could you explain to me why this is right? I never used that feature, > so I don't understand the context. The text that is being edited is LaTeX source code. preview-latex displays previews of the edited material in the source buffer. The source are things like $\sum_{i=0}^\infty \frac{1}{i+i}$ that are easy to enter and edit and somewhat cumbersome to read in context. Replacing those fragments with the rendered images in the source code while the particular corresponding source code is not being edited makes it easier to peruse the mathematical meaning of the source while continuing to compose further text and mathematics. This is a visual aid, not something changing the text in any manner. Like a tooltip, it has to get out of the way whenever you actually want to do something to the source code of the text. > No, I am not saying that. I am saying something else: > > > I'd expect it to be desirable that they follow text that is copied. > > If you kill text that contains some of these images of math > > and then yank it back, shouldn't it come back with the images? > > > This is what lead me to think of text properties first for this job. > > Since you say that is not the desired behavior, I'd like to understand > why not. > > What is a scenario for editing the text that is under the image > overlay, Any editing at all. The image is a visualization, you cannot edit that. It is output, not input. > and what is the right behavior? The same as without preview-latex. This is just like a document previewer, only scattered over the corresponding input in order to save place and concentration. It's pointless for plain text: hopefully you have selected a more readable font in your editor for that on a low-contrast 100dpi color screen than some washed-out downsampling of a font intended to look best printed with 1200dpi on a high-contrast two-color output device. But for stuff that becomes harder to follow when looking at its source code rather than the rendered rendition, it's helpful. -- David Kastrup