From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Overlay insertion types, markers, etc. Date: Fri, 15 Nov 2019 08:54:05 -0800 (PST) Message-ID: References: <<20c74b83-6272-44e9-b4ac-829fd4cd0143@default>> <<83lfsh2zvf.fsf@gnu.org>> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="220942"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 15 17:56:57 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 1iVeu1-000vMK-F1 for ged-emacs-devel@m.gmane.org; Fri, 15 Nov 2019 17:56:57 +0100 Original-Received: from localhost ([::1]:41940 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVetz-000332-OP for ged-emacs-devel@m.gmane.org; Fri, 15 Nov 2019 11:56:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56821) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iVerd-0007sT-E4 for emacs-devel@gnu.org; Fri, 15 Nov 2019 11:54:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iVerb-0004sj-Cx for emacs-devel@gnu.org; Fri, 15 Nov 2019 11:54:28 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:60874) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iVerZ-0004gr-0f; Fri, 15 Nov 2019 11:54:25 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAFGn0xt178664; Fri, 15 Nov 2019 16:54:20 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=V/FytQTEyWNu9+uGuAq64UUhdG0rYMZx33KvshuD4zo=; b=ISeiDYPGAfz5s8+704EUKy7LVfR8hnwtSaE33hj4w3zt+AxgBIrtlpmfmrHAFxwQ5j99 +4JGqUscEeUYpDXhrPF1gY+jQzIDIF3V4+zLrGdiiQqOxY8b5qXfr+AKOfRl6GZzSBiV 4n94IaIp76XG6HHq5jB1FOUEfwWMGC76L7UkzhPCwlyBZGk36QDGg8wdLdnTKTaE6XQo qrCPTVjSrTCh9sqcTDfWAxkVNi05yxC7R9Tx8EGN2PyrH8X2KqdL+MzoF4ALn8+GSFyi YjnGxYmr5p66DP4E9NG7Q+3XgmdaChvsTo1Bsuw0El3eZJ82LeVmguoTJLdPnQy14MPW Aw== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 2w9gxpme68-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 15 Nov 2019 16:54:20 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAFGsBGA178268; Fri, 15 Nov 2019 16:54:19 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3030.oracle.com with ESMTP id 2w9h14ttf9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 15 Nov 2019 16:54:13 +0000 Original-Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xAFGs55M006977; Fri, 15 Nov 2019 16:54:06 GMT In-Reply-To: <<83lfsh2zvf.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4927.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9442 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911150149 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9442 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911150149 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.86 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:242243 Archived-At: Thanks very much for answering. I have a few follow-up questions, for clarity. I don't expect to belabor this, but things are still not very clear to me. > > Why, if you pass markers, isn't the default to use > > the insertion types of those markers? >=20 > 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? That's the question. Functions like `goto-char' have no use of the other information (buffer, insertion types) in a marker, besides its position. An overlay does have an associated buffer and insertion types. (I suppose someone might suggest that `goto-char' could go to a marker in another buffer, and that it could accept an optional BUFFER arg. But I haven't done that. In any case, surely it could have no use for an insertion type, right?) Why doesn't `make-overlay' get the defaults for such things from its input markers? > > 2. `make-overlay' seems to be the only way to specify > > the insertion types for an overlay. Is that right, > > or did I miss something? >=20 > That's right. >=20 > > Why isn't there (or is there?) a simple way to > > change the "marker insertion types" of an existing > > overlay? >=20 > 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)? I don't see that possibility. And below you seem to point to using C (?). I'm asking whether (and if so how) you can do this with Lisp. > > Suppose you want to copy an existing overlay and > > then change some things in the copy. You can't > > change the insertion types for it, right? > > > > I guess you need to use `make-overlay', specifying > > insertion types, and then explicitly copy everything > > else from the first overlay. Is that right? >=20 > Yes. Is there a good reason not to provide a way to change insertion types in an existing overlay? (Assuming there is no such way - see above: not clear to me what doing so "by hand" means, i.e., how to do it.) 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? Wouldn't it be useful to even have setter functions for an overlay, which correspond to the getter functions (`overlay-start', `overlay-end', `overlay-buffer')? Or even be able to use `setf' with such getters? I'm not so much proposing a change. To start with, I really want to understand the design and its logic. > > 3. Similarly, the default BUFFER for `make-overlay' > > is the current buffer, even if you pass markers. > > > > Third question (similar to the first): > > > > 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? >=20 > 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: One obvious possibility is to just do what we do now, if the markers don't provide usable buffer info: use the current buffer. If the markers point to different buffers, for example, just ignore those buffers - just do what we do now (use current buffer). If one limit passed to `make-overlay' is a marker and the other is a number, use the buffer of the marker. If a marker has no buffer then it also has no position, no? How could it not? So I don't get your question "if their buffers don't exist". If a marker has a position then that position must "fit" its buffer, no? How could it not? So I don't get your question "if the position information doesn't fit". But again, if for some reason the info from a marker isn't usable, then just don't use it - do what we do now. > > 4. (Repeating) "An overlay uses markers to record > > its beginning and end." > > > > It seems that an overlay "uses markers" but those > > aren't the markers you passed to `make-overlay'. > > Is that right? >=20 > Yes. >=20 > > Can you retrieve the markers that are "used by" > > an overlay, i.e., as markers? >=20 > 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? > > "This is the only valid way to change the endpoints > > of an overlay. Do not try modifying the markers in > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > the overlay by hand, as that fails to update other > > vital data structures and can cause some overlays > > to be lost." > > > > That makes me wonder. I don't even see how you > > could try to "modify the markers of the overlay" > > (with Lisp). >=20 > 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? ___ Please note: I have nothing particular in mind here - no agenda. I'm trying to understand what the case is, and why. Depending on the "why" (once I understand it), if it seems weak then I may also wonder "why not" do something more helpful/useful. So far, that's what I'm wondering about things like obtaining the insertion types and buffer from the markers used to define an overlay. But I have no special use case in mind. It just seems (so far) like something useful is missing. 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?