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 17:53:06 +0000 (UTC) Message-ID: <3b0f7464-a74f-4687-b91b-b654697cc1cc@default> References: <10c2ca80-b3d5-4efb-a2b1-5ded0cc8a14d@default> <874kzfyzk5.fsf@marxist.se> 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="194525"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 38051@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 08 18:54:11 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 1iT8SZ-000oRm-E8 for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Nov 2019 18:54:11 +0100 Original-Received: from localhost ([::1]:58484 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iT8SX-0004Wr-Pl for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Nov 2019 12:54:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47253) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iT8SR-0004Wg-Pp for bug-gnu-emacs@gnu.org; Fri, 08 Nov 2019 12:54:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iT8SQ-0001MO-Hs for bug-gnu-emacs@gnu.org; Fri, 08 Nov 2019 12:54:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38738) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iT8SQ-0001ME-Dq for bug-gnu-emacs@gnu.org; Fri, 08 Nov 2019 12:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iT8SQ-0004Gr-6N for bug-gnu-emacs@gnu.org; Fri, 08 Nov 2019 12:54:02 -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 17:54:02 +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.157323559916370 (code B ref 38051); Fri, 08 Nov 2019 17:54:02 +0000 Original-Received: (at 38051) by debbugs.gnu.org; 8 Nov 2019 17:53:19 +0000 Original-Received: from localhost ([127.0.0.1]:47559 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iT8Ri-0004Fx-RK for submit@debbugs.gnu.org; Fri, 08 Nov 2019 12:53:19 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:55406) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iT8Rg-0004Fg-6x for 38051@debbugs.gnu.org; Fri, 08 Nov 2019 12:53:17 -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 xA8Hhmhb013556; Fri, 8 Nov 2019 17:53:10 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=sCxM30KnrihCzxXAUojfgJGFqkJx0U47xnN8Cq9zZXw=; b=BlHbXpcqfgoYvWWzZC6xaIunoBP0gDstr1ZSBYpGs3a5VVMBDxxqgcVyhNGahzTrffQ5 Cwr2mwKtAmKibRvtxBgfLk5WdmP2dcaexQLhXVFYWO5DpDHo4EwLznI4R+a7DOBwrhrV IpKpR+yUSxvFdo37IWfIgU3y5zRrw2R+ChJWpXy/i4HlWKwgBHFuvL4EXD/DaE4T3ioj XzCKG1o0LkkjkS9szPmtOpCD64vLeC/qEH4J5PaAf7SzBWYMuYCKafJNoQ3Qgc6tOkWS XgqPHLgjkPDhqGYMoASKd2n3z9oInGRUbRKev+Df242xLQFb7UdtYVG1ky5DbBxGprHB hg== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 2w41w16t9g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 08 Nov 2019 17:53:10 +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 xA8HnZLd041370; Fri, 8 Nov 2019 17:53:09 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 2w5bmpyjkt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 08 Nov 2019 17:53:09 +0000 Original-Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xA8Hr61B022187; Fri, 8 Nov 2019 17:53:07 GMT In-Reply-To: <874kzfyzk5.fsf@marxist.se> 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=9434 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-1910280000 definitions=main-1911080174 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9434 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-1910280000 definitions=main-1911080174 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:171238 Archived-At: We'll have to agree to disagree, I guess. IMO: 1. From a user point of view (conceptual model), markers _are_ objects that can be located _in_ a buffer, _at_ buffer positions. (So if chars are present, a marker can be located before or after a char, or between two chars). 2. Yes, we do sometimes draw a distinction, since marker changes, like overlay changes, are "not recorded in the buffer's undo list, since the overlays are not part of the buffer's contents." -- (elisp) `Managing Overlays'. Markers and overlays aren't part of a buffer's _contents_, but they are located in the buffer. 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). The doc of `marker-position' doesn't say that the marker "points at" the position. It says that the marker currently has that position - "the position of the marker". Nothing is gained, IMO, and confusion can be introduced, by saying that markers "point at" buffer positions, instead of saying markers are "located at" buffer positions or they "have" buffer positions. Yes, this question is more general than just the particular text questioned by the bug report, which compounds the problem of using "points at" because of different uses of the word "point". I see nothing positive about using "point at" or "point into" for markers. Occam's razor says simplify - just say that a marker can be _in_ a buffer _at_ a buffer position. IOW, speak of markers the same way we speak of overlays. `overlay-buffer' is the buffer that "OVERLAY _belongs to_", not the buffer that OVERLAY points to or that OVERLAY's positions point to. We create an overlay "in" a buffer, or that a given overlay is "in" no buffer. This means that I'd also change the doc of `marker-buffer', to speak of the buffer where MARKER is located, not "the buffer that MARKER points into". =20 And yes, a marker need not be located in any buffer. The doc string of `marker-buffer' says that it "points into" no buffer, and that of `marker-position' says that it "points nowhere". We should instead just say that the marker is not in any buffer. Likewise, we should say that a marker is located in a dead buffer, rather than saying that it "points into" a dead buffer. Note that we already do say that a marker is "in no buffer", here: (setq m (point-marker)), kill the buffer, then `C-h v m'. This is not an argument for consistency. It's an argument for a simpler description and user model: a marker can be in a buffer, or not. If in a buffer, it has a non-nil position. If not, its position is nil. This is how we treat overlays. We should treat markers the same way. The (undefined!) notion of a marker "pointing at" a buffer position isn't needed, and it isn't helpful.