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: Wed, 20 Nov 2019 09:38:18 -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=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="134992"; mail-complaints-to="usenet@blaine.gmane.org" Cc: eliz@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 Nov 20 18:41:53 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 1iXTzF-000Yz3-Ek for ged-emacs-devel@m.gmane.org; Wed, 20 Nov 2019 18:41:53 +0100 Original-Received: from localhost ([::1]:32982 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iXTzD-0002jg-TF for ged-emacs-devel@m.gmane.org; Wed, 20 Nov 2019 12:41:51 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56920) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iXTvw-0000I5-Ll for emacs-devel@gnu.org; Wed, 20 Nov 2019 12:38:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iXTvt-0005AY-QY for emacs-devel@gnu.org; Wed, 20 Nov 2019 12:38:27 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:51876) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iXTvr-00058M-2u; Wed, 20 Nov 2019 12:38:23 -0500 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAKHY5js143628; Wed, 20 Nov 2019 17:38:21 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=FifHQCOOd4aSBE2Dyu+UbuR9+rjmf8qJ24oo+XfW/Pg=; b=Sepihh1TxKA2/vn+JoqKDdIGR0cFqM2RByItauv2/r6nTPQ4KkrsCXr5K5FgN1J/s2M3 chJy5Tuh8BbxHMFcOmMoOYBz7h3umlh5YdFk/9sgRggc4cCVhJf9Sc/Cbq5jx38ksK9z 6WcuPYFIE7DH90fTvyd6A1O6+WTeB/9OiVm66a3EtMLIyPuxE7rQgrZNSXvjC8VFvXhd fS34GNM8YtYYCBMmgqd4eiHde2JtxlQC14szB8IYYagMhCI33DH5+LMRI+wclkSIQSO/ NjY7CBClCpURNACy//2jhuCU6EOUn3p9Q8an4bmgL/7EUVLcEBLEtN52u2ksVXI5XRIv 6Q== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 2wa92py3xg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 20 Nov 2019 17:38: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 xAKHXRI3142697; Wed, 20 Nov 2019 17:38:20 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3030.oracle.com with ESMTP id 2wda04g4rw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 20 Nov 2019 17:38:20 +0000 Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id xAKHcJmJ015861; Wed, 20 Nov 2019 17:38:19 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=9446 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-1911200148 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9446 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-1911200148 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 141.146.126.78 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:242515 Archived-At: > > 1. Why, if you pass markers [to `make-overlay], > > isn't the default to use the insertion types of > > those markers? >=20 > I don't think I ever thought about the question back then. >=20 > Did pointers even have insertion types, back when > overlays were first introduced? No idea. I know much less than you about this. > However, the function calling convention would have > to be complex to give you three options: yes, no, > or inherit from the marker. Not sure what you mean. We already have the ability to specify, using optional args, the insertion types and the buffer. The only question is where the _defaults_ for those come from, i.e., when you don't specify their optional args. Today, the defaults ignore such info from any marker args. Today, the current buffer is the default buffer, and the default for insertion is "the overlay extends to include any text inserted at the beginning, but not text inserted at the end". If we instead allowed the defaults to be taken from marker args, and if someone wanted today's default behavior, s?he would just pass a marker position (`marker-position') instead of the marker itself. And as I mentioned to Eli, if two markers are passed and they disagree wrt such things, then the defaulting could be done as it is now: ignore conflicting info from the markers. E.g., if two markers have the same buffer (or if only one of the position args passed is a marker), use that `marker-buffer'. Similarly, for FRONT-ADVANCE and REAR-ADVANCE. And yes, such a change in defaulting would not be backward compatible - code that passes markers and expects the default buffer and default insertion behavior to be as now would break. Users would need to update such code to use `marker-position'. But again, I wasn't proposing that or anything else. I was just trying to understand why we do what we do. > > 2. Why isn't there (or is there?) a simple way to > > change the "marker insertion types" of an > > existing overlay? >=20 > I never thought of adding it. >=20 > > 3. 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 > I never thought about it. >=20 > > 4. Can you retrieve the markers that are "used by" > > an overlay, i.e., as markers? >=20 > If you could get at them, you could change their buffer positions. > I think that would mess up the overlay sort order and cause bugs. > You could also put them in another buffer and cause even worse > trouble. That's what Stefan said. See my reply to him about that: https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg00603.html In particular, I think it's confusing for the doc to talk about the _markers of an overlay_ (this is not about the markers that you pass to `make-overlay'), since they are not markers in the usual sense of being Lisp objects (that is, visible and accessible from Lisp). At least it confused me and prompted my questions. Now that I understand a bit more, I'd suggest that the doc be changed to remove mention of an overlay having markers (internal though they are). That doesn't add anything, I think, and it can confuse. It should be enough to say that, like a marker, an overlay has a buffer and text-insertion behavior. In particular, the latter means that, by default, an overlay advances when you insert text before it.