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, 22 Sep 2014 00:06:42 +0200 Message-ID: <87r3z4mxvx.fsf@fencepost.gnu.org> References: <871tr6qup8.fsf@fencepost.gnu.org> <87y4tdnkro.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1411337227 19895 80.91.229.3 (21 Sep 2014 22:07:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Sep 2014 22:07:07 +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 Sep 22 00:07:00 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 1XVpHY-0007em-Ba for ged-emacs-devel@m.gmane.org; Mon, 22 Sep 2014 00:07:00 +0200 Original-Received: from localhost ([::1]:41130 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XVpHX-0003sm-Sn for ged-emacs-devel@m.gmane.org; Sun, 21 Sep 2014 18:06:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59626) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XVpHU-0003rf-Gx for emacs-devel@gnu.org; Sun, 21 Sep 2014 18:06:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XVpHT-0003VF-M5 for emacs-devel@gnu.org; Sun, 21 Sep 2014 18:06:56 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42808) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XVpHT-0003Rq-I2 for emacs-devel@gnu.org; Sun, 21 Sep 2014 18:06:55 -0400 Original-Received: from localhost ([127.0.0.1]:49976 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XVpHH-00051P-8w; Sun, 21 Sep 2014 18:06:43 -0400 Original-Received: by lola (Postfix, from userid 1000) id 3FC6CE06F7; Mon, 22 Sep 2014 00:06:42 +0200 (CEST) In-Reply-To: (Richard Stallman's message of "Sun, 21 Sep 2014 17:48:03 -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:174631 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. ]]] > > Because you don't want _anything_ that text properties do. You don't > want to have the stuff cut&paste, > > 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. > 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? No. The same input text at a different location in the same document might show a different equation number. In a different document it might not compile at all or have a different size. > This is what lead me to think of text properties first for this job. > > you don't want to have the buffer > modified because images are switched on and off, > > We can provide a feature for turning off and on the display > of these images without changing the text properties themselves. > I think there already is a way. > > you don't want anything inserted anywhere inheriting > anything from it. > > We already have ways to specify no inheritance. > > you most definitely > don't want ever to split its identity in two if there are insertions in > the middle, > > That's true. However, isn't such insertion anomalous anyway? How bad > is it, if that anomalous act causes the image to appear twice? Bad. Text properties and overlays have different semantics. You basically say "let's ignore all the mismatching semantics because the performance of overlays is bad". That does not make sense. If it did, we would not have overlays in the first place. -- David Kastrup