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.bugs Subject: bug#38051: 26.3; (elisp) `Insertion' use of verb "point" Date: Fri, 8 Nov 2019 11:56:29 -0800 (PST) Message-ID: References: <<10c2ca80-b3d5-4efb-a2b1-5ded0cc8a14d@default>> <<874kzfyzk5.fsf@marxist.se>> <<3b0f7464-a74f-4687-b91b-b654697cc1cc@default>> <<83a796b2tx.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="191172"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38051@debbugs.gnu.org, stefan@marxist.se To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 08 20:57:17 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1iTANh-000nXG-2g for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Nov 2019 20:57:17 +0100 Original-Received: from localhost ([::1]:59786 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iTANa-0006XQ-Fp for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Nov 2019 14:57:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37683) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iTANU-0006Wn-Ph for bug-gnu-emacs@gnu.org; Fri, 08 Nov 2019 14:57:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iTANT-0003PM-ON for bug-gnu-emacs@gnu.org; Fri, 08 Nov 2019 14:57:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38840) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iTANT-0003PF-LF for bug-gnu-emacs@gnu.org; Fri, 08 Nov 2019 14:57:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iTANS-00013H-0S for bug-gnu-emacs@gnu.org; Fri, 08 Nov 2019 14:57:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Nov 2019 19:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38051 X-GNU-PR-Package: emacs Original-Received: via spool by 38051-submit@debbugs.gnu.org id=B38051.15732430004017 (code B ref 38051); Fri, 08 Nov 2019 19:57:01 +0000 Original-Received: (at 38051) by debbugs.gnu.org; 8 Nov 2019 19:56:40 +0000 Original-Received: from localhost ([127.0.0.1]:47661 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iTAN6-00012i-H7 for submit@debbugs.gnu.org; Fri, 08 Nov 2019 14:56:40 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:42586) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iTAN4-00012T-Nx for 38051@debbugs.gnu.org; Fri, 08 Nov 2019 14:56:39 -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 xA8Jmv64129364; Fri, 8 Nov 2019 19:56:32 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=sT+52wsP1IAEPUDeBwLE3+1Jtm7D7/n17s6XX4W98jM=; b=nxBzUod+r6LV/Pk9E0YtghJm46Gy2yg3rcQ0r0ZXg/ZhdhgQkA0FsjfnutFTjKb2FK9w DbpGnkv7jW0edsLqhkmDbh9knLbvdxBus3/aQTQY61n86IuDlq6l3lrIdC+haNpR2V7N MUBDFd+KDTcgVvZbXrnvkPvv0canliv9LvLC49n+T8BfZv5tUJYeD+v1VjEYOqfZuWN2 zjAXiJRQG6Qpus6BBXuX7rxSyZYUvhf6ctvRm7P09gC0Ix/1GGnSPqJj0cALxl0i/EHA S5n7I+8ATtvxXUtrPoYqIZatm/Lc9JXvuozCGzRK+Mg7XkXIIVchg53L/0laCHaQR3Na 7w== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2130.oracle.com with ESMTP id 2w41w1feea-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 08 Nov 2019 19:56:32 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xA8JmulH044150; Fri, 8 Nov 2019 19:56:32 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 2w50m63w03-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 08 Nov 2019 19:56:31 +0000 Original-Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xA8JuUD0006363; Fri, 8 Nov 2019 19:56:30 GMT In-Reply-To: <<83a796b2tx.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4900.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9435 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=896 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911080192 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9435 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=972 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911080192 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:171256 Archived-At: > > 1. From a user point of view (conceptual model), > > markers _are_ objects that can be located > > _in_ a buffer, _at_ buffer positions. >=20 > That is incorrect. A marker stores a buffer and a location within > that buffer, but it isn't itself located in a buffer. >From a user point of view. That's the point. That can't be "incorrect". It's a question of what the user needs as a conceptual model to work with markers (and overlays, for that matter). Does the model fit the observable behavior? That's something that makes sense to ask. So far, I've seen no example of a case where it doesn't fit. It does not matter one whit to a user what the implementation of a marker is. Whether a marker "stores a buffer and a location" or a marker stores a (code) pointer to a buffer and a location, or however else it might be implemented. Unless you can show the contrary. Ehat user-visible behavior is unexplained by the simpler user model I described (and which we already use for overlays, and which we already partly - but not consistently - use for markers)? > > 3. When we document `char-after', we don't say > > that the char (which is conceptually _in_ the > > buffer) "points at" a buffer position. We > > say "Return the character _in_ current buffer > > _at_ position POS." > > > > Markers, like characters, are at buffer > > positions (chars are actually after, not at). >=20 > See above: that's correct about characters, but incorrect about > markers. "Incorrect" is the wrong way to talk about such things. A user description/model that is coherent, consistent, and complete - jibes with observable behavior - is fine and dandy. Useful, sufficient. =20 > > This is how we treat overlays. >=20 > Overlays are completely different beasts. If you say so (without any explanation of why you think so). Does an overlay store a buffer and two locations within that buffer? Why is it necessary (or even useful) for a user to think in terms of a marker doing that but not an overlay? What is it in the user-observable behavior of a marker that requires introducing the extra (I'd say extraneous) construct of it "pointing to" a buffer and a position within that buffer? A construct that is nowhere defined or explicated.