From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Overlay insertion types, markers, etc. Date: Fri, 15 Nov 2019 19:12:42 +0200 Message-ID: <83v9rl12t1.fsf@gnu.org> References: <<20c74b83-6272-44e9-b4ac-829fd4cd0143@default>> <<83lfsh2zvf.fsf@gnu.org>> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="23106"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 15 18:13:48 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iVfAK-0005to-2W for ged-emacs-devel@m.gmane.org; Fri, 15 Nov 2019 18:13:48 +0100 Original-Received: from localhost ([::1]:42456 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVfAI-0001pJ-VS for ged-emacs-devel@m.gmane.org; Fri, 15 Nov 2019 12:13:46 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60212) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVf9V-0001p5-Rm for emacs-devel@gnu.org; Fri, 15 Nov 2019 12:12:58 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33368) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iVf9U-00034H-Fp; Fri, 15 Nov 2019 12:12:57 -0500 Original-Received: from [176.228.60.248] (port=1134 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iVf9T-000527-Gq; Fri, 15 Nov 2019 12:12:55 -0500 In-reply-to: (message from Drew Adams on Fri, 15 Nov 2019 08:54:05 -0800 (PST)) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.org gmane.emacs.devel:242245 Archived-At: > Date: Fri, 15 Nov 2019 08:54:05 -0800 (PST) > From: Drew Adams > Cc: emacs-devel@gnu.org > > > Because the markers passed to make-overlay are treated > > only as representing buffer positions, similarly to > > other functions, like goto-char. > > But _why_ are they used only for their positions? Because that's the minimal useful thing to do. We do that in many other APIs. Anything beyond that would need a good reason. > > > Why isn't there (or is there?) a simple way to > > > change the "marker insertion types" of an existing > > > overlay? > > > > Because it's easy to do that by hand? > > How so? How do you change the insertion types of > an _existing_ overlay (by hand or otherwise)? You make a new overlay and copy whatever you want to keep from the old one. > Is there a good reason not to provide a way to > change insertion types in an existing overlay? I don't know. Probably because a need never aroused. > You can change overlay properties of an existing > overlay. And you can change its limits > (`move-overlay'). But you can't change its > insertion types or its buffer (or can you?). > Why not provide a way to do that? We don't normally provide every possible way to do every possible change. Just those which are needed. > I'm not so much proposing a change. To start > with, I really want to understand the design and > its logic. The design was b y Richard, so he is the only one who might remember why he didn't go beyond what we have. > > > Why, if you pass markers to `make-overlay', and > > > you don't pass arg BUFFER, isn't the default to > > > use the buffer of those markers? > > > > Because that just complicates the implementation with no real gain: > > what to do if the markers point to different buffers, or if their > > buffers don't exist, or the position information doesn't fit, etc.? > > (This is about determining the _default_ buffer > value, when the BUFFER arg is not provided.) > > There are various possibilities (design choices). > Off the top of my head, naively: Sure, there is. But they all complicate things, whereas passing a buffer is simple and efficient. > > > Can you retrieve the markers that are "used by" > > > an overlay, i.e., as markers? > > > > No. We don't want to give Lisp access to those markers, > > as that could mean giving to long a rope to Lisp programs > > to hang themselves. > > I don't see what the problem is. They're just > markers (presumably). Any code can use any marker > to hang to hang itself now. How is that related to > the fact that an overlay would use such a marker? Giving Lisp programs access to those markers will complicate related features. For example, the display engine currently tracks only changes to overlays, it doesn't track changes to its markers. Also, having references to those markers lying around will complicate how overlays are deleted -- currently we just delete their markers. And these are just results of 5 sec of thinking. > > I believe that remark is for C programming. > > So in the Elisp manual we tell users not to try > to use C to modify the markers in an overlay > "by hand"? > > Why is such a remark appropriate/helpful? How > would a reader even guess that C programming is > what that remark has in mind? I don't know. I certainly find it helpful. > But I have no special use case in mind. It just > seems (so far) like something useful is missing. I don't think anything potentially useful is missing. You can do everything you want with this stuff, albeit sometimes indirectly. > I'm guessing that I'm wrong about this, just > because I don't yet understand enough why things > are the way they are. Is this maybe just a case > of no one ever getting around to improve it, or > are there good reasons why things are the way > they are? I don't know.