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: Wed, 01 Oct 2014 12:38:52 +0900 Message-ID: <87r3ysv4qb.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> <87a95hx5re.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1412134784 5562 80.91.229.3 (1 Oct 2014 03:39:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Oct 2014 03:39:44 +0000 (UTC) Cc: dak@gnu.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 01 05:39:37 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 1XZAlM-0001Pj-Nx for ged-emacs-devel@m.gmane.org; Wed, 01 Oct 2014 05:39:36 +0200 Original-Received: from localhost ([::1]:47612 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZAlM-0006Rx-AH for ged-emacs-devel@m.gmane.org; Tue, 30 Sep 2014 23:39:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZAl3-0006QP-DH for emacs-devel@gnu.org; Tue, 30 Sep 2014 23:39:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XZAkv-0007XS-Tq for emacs-devel@gnu.org; Tue, 30 Sep 2014 23:39:17 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:56365) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZAkm-0007UX-Q2; Tue, 30 Sep 2014 23:39:01 -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 D17071C39B3; Wed, 1 Oct 2014 12:38:52 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C34A11A2697; Wed, 1 Oct 2014 12:38:52 +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:174896 Archived-At: Richard Stallman writes: > > But you keep the overlay in existence -- how come? > > Why do you care? > > Because I want to understand what this program is doing. That much is obvious. But why do you care what the program is doing? Do you plan to become an AUCTeX developer? Do you want to check whether it's possible for AUCTeX to use text properties rather than overlays? Do you want to check if AUCTeX is highly wasteful of overlays, leading to the efficiency issue, so that an improvement to Emacs overlays is actually unnecessary for the use case? The first motivation seems implausible given your time constraints and non-use of AUCTeX, and I am quite sure the second two are wastes of your time -- you will discover that AUCTeX's overlay implementation is preferable to using text properties and that it doesn't leak overlays, it just uses a lot of them in a big document. For two reasons: I know a little bit about the implementation, and independently come to those conclusions, and as confirmation, I know that David knows his business. Do you have yet another motivation for studying AUCTeX's implementation? > David knows his business, isn't that good enough? > > Good enough to tell me the program logic??? Of course not. But knowing the program logic tells you what it is doing, not why it does it that way. If the program is a poor program, you could probably find ways to optimize it, and so avoid a large change to Emacs. But I see every reason to believe that is not the case. At this point, from my point of view, we've been going around in a tight spiral for several days. It would be nice if we could go straight to the point, that's all. Or, it would be nice if you could show that we are already on the straight path to the point.