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: Sun, 17 Nov 2019 09:35:47 -0800 (PST) Message-ID: References: <20c74b83-6272-44e9-b4ac-829fd4cd0143@default>>> <83lfsh2zvf.fsf@gnu.org>>> > <83v9rl12t1.fsf@gnu.org>> <6dfab4eb-3701-40bb-80f1-942edd375295@default> <29c934d3-712c-414e-b4aa-9ed8f3c609a2@default> 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="69196"; mail-complaints-to="usenet@blaine.gmane.org" Cc: eliz@gnu.org, rms@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 17 18:36:07 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 1iWOSz-000Hpl-9Q for ged-emacs-devel@m.gmane.org; Sun, 17 Nov 2019 18:36:05 +0100 Original-Received: from localhost ([::1]:55242 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iWOSy-0003LT-2A for ged-emacs-devel@m.gmane.org; Sun, 17 Nov 2019 12:36:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40634) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iWOSq-0003I3-GQ for emacs-devel@gnu.org; Sun, 17 Nov 2019 12:35:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iWOSo-0007Wx-EF for emacs-devel@gnu.org; Sun, 17 Nov 2019 12:35:55 -0500 Original-Received: from userp2120.oracle.com ([156.151.31.85]:58640) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iWOSm-0007TC-1T; Sun, 17 Nov 2019 12:35:52 -0500 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAHHTNNG056273; Sun, 17 Nov 2019 17:35:50 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=z8Aa60QOqYPP/xf/u4VBiFdsXhLcofb/5G1al9BeR+A=; b=H4otXL3Ob2BM3DkmAaS2D6y8PbIS3zjRGbf8UTDHZUbrz37e8s8vqaPnmm3KW6V8yGYk nTwP6AVONKpf4hbElnjRGs4ihBpaj3sboL6wPJv3rHJNcmL9dVDkQMHFTWdQYaOS49Oh ZNwKGG2R4ocX1qWxq6j7kXFWX7eUOAlIiUiyX08b0ddzlQ/p5jCT3YBPGwuHAzPV/kfC oqdgnuEwU2jNve04YET76UpafDXvnr8hct5w/reqFvRqmgvrVUNS1aopzzpZObZKEQp6 vhGVimHeJhMMkgM7YWS8s58lDPUT0tstR4NbKLHBZEvTg7ef+ba48me7aYM5T8x6QS8D 2Q== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 2wa9rq42p4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 17 Nov 2019 17:35:50 +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 xAHHXMXU113038; Sun, 17 Nov 2019 17:35:49 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 2watjw32ac-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 17 Nov 2019 17:35:49 +0000 Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xAHHZmJ9029568; Sun, 17 Nov 2019 17:35:48 GMT In-Reply-To: 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=9444 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-1911170168 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9444 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-1911170168 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.85 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:242285 Archived-At: > > 4. Can you retrieve the markers that are "used by" > > an overlay, i.e., as markers? >=20 > No, you can't, and you shouldn't be able to: it's > an implementation detail, that may change in the > future (IIUC the `noverlays` branch indeed makes > this change as part of a rewrite which tries to > eliminate some algorithmic complexity problems in > the overlay code). OK. The other questions I asked were about using the markers passed to `make-overlay' to specify the _defaults_ for the overlay: insertion types and buffer. That is, the values to use for those if the optional args to specify them aren't provided. Those other questions were not about the markers in the overlay itself - they were only about obtaining default info when creating an overlay and passing it markers instead of numbers. This question (#4) was different. It was about Lisp access to the markers used in the overlay itself. About which nothing is said, BTW. But Eli has confirmed that they are indeed markers. "Marker" in the Elisp doc (other than here) means an object accessible from Lisp. It's confusing to talk, in passing - with no description or explanation, of "markers" that are used by an overlay (i.e., as part of it), but that are (it turns out) not markers in the usual sense, because they're not accessible to Lisp. It confused me anyway. All the more so because the doc doesn't actually say they're only internal, not accessible. Hence this question (#4), to find out if they are in fact somehow accessible. > Also it would introduce all kinds of extra work: > - when an overlay is moved, the redisplay code is > told about it, whereas no redisplay is normally > caused by moving a marker, so we'd need to figure > out what to do when an "overlay-owned" marker is > moved. I'm not proposing anything. But I'm guessing that that point is incorrect in one sense (one direction). If the overlay does, as the doc and Eli say, use markers, then when the overlay is moved those markers are presumably already updated accordingly. But there's also the reverse, which you bring up: moving the markers. You segue to moving (e.g. by Lisp) one or both of the overlay markers. > - the user could now move the start-marker of an > overlay to another buffer than the end-marker > - the user could now move the end-marker of an > overlay before the start-marker (this can already > happen but only in very specific cases, so we'd > have to handle it in more cases). Those are cases of not only examining the markers from Lisp but changing them. There is already a (mysterious, IMO, since the markers are currently internal) warning in the Elisp manual _not to do_ that: "Do not try modifying the markers in the overlay by hand..." (Eli has said that that warning must be to not try that using C code. Why such a warning would be in the Elisp manual is not clear to me.) But suppose the markers were modifiable from Lisp, and suppose someone ignored the warning. The result could (by design) simply be to delete the overlay. IOW, if an overlay for any reason has markers that are nonsensical (for an overlay) then treat it as deleted (no buffer). One possibility. Again, I didn't propose providing Lisp access. I was asking why we tell users that an overlay has markers, instead of, for example, just saying that it has a start, an end, and a buffer? Why talk about the "markers" of an overlay at all? Especially since they apparently are not markers in the usual sense (Lisp objects). We don't use markers passed as `make-overlay' args for anything but initializing the start and end positions (presumably swapping them, if passed in the wrong order numerically). What's the point of documenting that an overlay has markers? And not saying clearly that they're only internal - not normal markers (i.e., Lisp-accessible)? And warning users not to modify them - which they can't do anyway using Lisp. It's the doc that led me to ask these questions. I haven't proposed any changes to the behavior - or even to the doc. But given the answers to my questions so far, it seems to me (assuming that no behavior changes are in order or desired), that the doc should maybe be changed a bit. No? --- BTW, you mention "the `noverlays` branch indeed makes this change as part of a rewrite which tries to eliminate some algorithmic complexity problems in the overlay code." What's that about? Is there a plan to remove overlays? It would be good to know this, so we (e.g. 3rd-party code) don't waste time developing things that depend more on overlays.