From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 03 16:26:20 2019 Received: (at submit) by debbugs.gnu.org; 3 Nov 2019 21:26:20 +0000 Received: from localhost ([127.0.0.1]:35300 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iRNO7-0005Ju-Vp for submit@debbugs.gnu.org; Sun, 03 Nov 2019 16:26:20 -0500 Received: from lists.gnu.org ([209.51.188.17]:51251) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iRNO3-0005Jb-TH for submit@debbugs.gnu.org; Sun, 03 Nov 2019 16:26:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:55097) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iRNO2-0003mE-IH for bug-gnu-emacs@gnu.org; Sun, 03 Nov 2019 16:26:15 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_MED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iRNO0-0004SW-UY for bug-gnu-emacs@gnu.org; Sun, 03 Nov 2019 16:26:14 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:53680) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iRNO0-0004SB-Ls for bug-gnu-emacs@gnu.org; Sun, 03 Nov 2019 16:26:12 -0500 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 xA3L9RR6019364 for ; Sun, 3 Nov 2019 21:26:11 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=aTlZl3zZrDE8hNgCNyu7xzUwKy09QibN61JaxO9lLk4=; b=hgTn+j23tKi+KduAyt202RpFJNPMyiRwrHNpKwFf/xe+EEPEK/rJtC1GxQ8FffX2Yun8 LQ2pcXXEc48Y6bvHWqTqlBiR7PDx1yJKcMKJrknCY0KhPJHzC8qUZtPwzHBHjTReIx75 rHQmaZuE+3E/d934sDcawXI9s7mvT3s6knm1DiwatLvZgFyCkzKRt2BEciK6ooHpPACW I8p1Na1WdCSzpCXBOUoNCgIAf68RG17Qw1LNzuzZePK6LSip6FRnRpjmZ1jaxLkw8DWv IGyIBPQSHEGTCDmo/M39Op3NSqdJryIRqmMI3nWjegR2K5PTcLynnMPq25uOeSU3hhY7 ZQ== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 2w12equx9y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sun, 03 Nov 2019 21:26:11 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xA3LDAEI186147 for ; Sun, 3 Nov 2019 21:26:10 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3020.oracle.com with ESMTP id 2w1ka89xwp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sun, 03 Nov 2019 21:26:10 +0000 Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id xA3LQ90S016574 for ; Sun, 3 Nov 2019 21:26:09 GMT MIME-Version: 1.0 Message-ID: <10c2ca80-b3d5-4efb-a2b1-5ded0cc8a14d@default> Date: Sun, 3 Nov 2019 13:26:08 -0800 (PST) From: Drew Adams To: bug-gnu-emacs@gnu.org Subject: 26.3; (elisp) `Insertion' use of verb "point" X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4900.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9430 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 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-1908290000 definitions=main-1911030223 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9430 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=1 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-1908290000 definitions=main-1911030223 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.85 X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) In a few places this node uses the verb "to point" to refer to a marker's position, as in the marker points to position N. This is unfortunate, as it makes the text confusing - especially so because the text in the node refers often to "point" meaning, well, point, the position of the cursor. Too many occurrences of "point", and in some cases with different possible meanings (some of which are wrong). It would be better to just talk about the position of the marker, or the position the marker has, than to talk about the position the marker points to. Examples: 1. When a marker points at the place of insertion... 2. Certain special functions such as `insert-before-markers' relocate all such markers to point after the inserted text, regardless of the markers' insertion type. 3. ...it relocates markers initially pointing at the insertion point, to point after the inserted text. #1 is not confusing or ambiguous. #2 and #3 can confuse you into thinking that "point after the inserted text" is maybe talking about point (the cursor position) being (just) after the inserted text, as if the text had another comma: "relocate all such markers to point, after the inserted text,..." Yes, lack of that comma does make the meaning clear, unless you read the text carefully you can be confused or misled. If the text instead speaks of the position of a marker, or speaks of where a marker "is", instead of speaking of where a marker "points", the problem disappears. E.g.: 1. When a marker is at the place of insertion... 2. Certain special functions such as `insert-before-markers' relocate all such markers to be after the inserted text, regardless of the markers' insertion type. 3. ...it relocates markers that are initially at the insertion point, to be after the inserted text. (This node also talks about "code point", which is a third meaning for "point". But that's unavoidable, and the text is not confusing.) In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32) of 2019-08-29 Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd Windowing system distributor `Microsoft Corp.', version 10.0.17763 Configured using: `configure --without-dbus --host=3Dx86_64-w64-mingw32 --without-compress-install 'CFLAGS=3D-O2 -static -g3'' From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 04 12:22:57 2019 Received: (at 38051) by debbugs.gnu.org; 4 Nov 2019 17:22:57 +0000 Received: from localhost ([127.0.0.1]:37470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iRg48-000334-TX for submit@debbugs.gnu.org; Mon, 04 Nov 2019 12:22:57 -0500 Received: from eggs.gnu.org ([209.51.188.92]:51677) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iRg47-00032q-1F for 38051@debbugs.gnu.org; Mon, 04 Nov 2019 12:22:55 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34057) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iRg41-0003Rw-Mt; Mon, 04 Nov 2019 12:22:49 -0500 Received: from [176.228.60.248] (port=3011 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iRg40-0005HC-KJ; Mon, 04 Nov 2019 12:22:49 -0500 Date: Mon, 04 Nov 2019 19:23:00 +0200 Message-Id: <83sgn3h7yj.fsf@gnu.org> From: Eli Zaretskii To: Drew Adams In-reply-to: <10c2ca80-b3d5-4efb-a2b1-5ded0cc8a14d@default> (message from Drew Adams on Sun, 3 Nov 2019 13:26:08 -0800 (PST)) Subject: Re: bug#38051: 26.3; (elisp) `Insertion' use of verb "point" References: <10c2ca80-b3d5-4efb-a2b1-5ded0cc8a14d@default> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38051 Cc: 38051@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 3 Nov 2019 13:26:08 -0800 (PST) > From: Drew Adams > > In a few places this node uses the verb "to point" to refer to a > marker's position, as in the marker points to position N. > > This is unfortunate, as it makes the text confusing - especially so > because the text in the node refers often to "point" meaning, well, > point, the position of the cursor. Too many occurrences of "point", and > in some cases with different possible meanings (some of which are wrong). FWIW, I see no reason to shy away from using the word "point" in its usual sense, just because we also have a special meaning for it. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 04 13:12:50 2019 Received: (at 38051) by debbugs.gnu.org; 4 Nov 2019 18:12:50 +0000 Received: from localhost ([127.0.0.1]:37498 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iRgqP-0004L5-VS for submit@debbugs.gnu.org; Mon, 04 Nov 2019 13:12:50 -0500 Received: from userp2130.oracle.com ([156.151.31.86]:60610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iRgqJ-0004Kk-PP for 38051@debbugs.gnu.org; Mon, 04 Nov 2019 13:12:48 -0500 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 xA4I98NR010991; Mon, 4 Nov 2019 18:12:37 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=lVvTV9pA/ieSSnYvWwRP6lgBaRRUx//zt46QSUBxseA=; b=AxCMPSH0+ox1bPSWv71k1hIm+4DjeEfISAbsu8UjC9f8cQoGYoMZM9j8UrgntzeLGuLj TNL7Lr5WrmYLb9wPYbtomjPU+qfD2QeFC2ewKOL8IGNkD2N0xRoBhHqCVzTa+gGaoTj0 laa0AWAwf5Hoa1kN2QPtaPVYp+KlL/G0MjtgZkZbHIqUmVVcPplLq9j15fQfhGbbi/vK hA0kfzydfagUQuVFJHVG8BaUlIEMMQw3dCh/xjfLOV9JJITpcsm/q1iOzRId1aWKy95j Zyy+tPaEUyFeZ7z/2Ok+vaAnHB+/J5kmm1iP0w36AtMmmOWB9cJ8KRwe6Giw8+eygi81 oQ== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 2w117ts772-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 04 Nov 2019 18:12:37 +0000 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 xA4I7wQU075121; Mon, 4 Nov 2019 18:10:37 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 2w1k8v84yp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 04 Nov 2019 18:10:37 +0000 Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xA4IAZi4011352; Mon, 4 Nov 2019 18:10:36 GMT MIME-Version: 1.0 Message-ID: Date: Mon, 4 Nov 2019 10:10:34 -0800 (PST) From: Drew Adams To: Eli Zaretskii , Drew Adams Subject: RE: bug#38051: 26.3; (elisp) `Insertion' use of verb "point" References: <<10c2ca80-b3d5-4efb-a2b1-5ded0cc8a14d@default>> <<83sgn3h7yj.fsf@gnu.org>> In-Reply-To: <<83sgn3h7yj.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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9431 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=642 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1911040177 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9431 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=720 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1911040177 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38051 Cc: 38051@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > FWIW, I see no reason to shy away from using the word "point" in its > usual sense, just because we also have a special meaning for it. Do you see no reason because you don't see the possible confusion? Or do you see that but don't consider it's worth using different language to prevent it? From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 04 13:36:17 2019 Received: (at 38051) by debbugs.gnu.org; 4 Nov 2019 18:36:17 +0000 Received: from localhost ([127.0.0.1]:37518 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iRhD6-0004zH-O9 for submit@debbugs.gnu.org; Mon, 04 Nov 2019 13:36:17 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35824) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iRhD1-0004yz-Hh for 38051@debbugs.gnu.org; Mon, 04 Nov 2019 13:36:13 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iRhCw-00062Z-65; Mon, 04 Nov 2019 13:36:06 -0500 Received: from [176.228.60.248] (port=3504 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iRhCv-0006kt-Ed; Mon, 04 Nov 2019 13:36:05 -0500 Date: Mon, 04 Nov 2019 20:36:18 +0200 Message-Id: <83r22nh4kd.fsf@gnu.org> From: Eli Zaretskii To: Drew Adams In-reply-to: (message from Drew Adams on Mon, 4 Nov 2019 10:10:34 -0800 (PST)) Subject: Re: bug#38051: 26.3; (elisp) `Insertion' use of verb "point" References: <<10c2ca80-b3d5-4efb-a2b1-5ded0cc8a14d@default>> <<83sgn3h7yj.fsf@gnu.org>> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38051 Cc: 38051@debbugs.gnu.org, drew.adams@oracle.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 4 Nov 2019 10:10:34 -0800 (PST) > From: Drew Adams > Cc: 38051@debbugs.gnu.org > > > FWIW, I see no reason to shy away from using the word "point" in its > > usual sense, just because we also have a special meaning for it. > > Do you see no reason because you don't see the > possible confusion? Or do you see that but don't > consider it's worth using different language to > prevent it? The former. From debbugs-submit-bounces@debbugs.gnu.org Thu Nov 07 19:36:23 2019 Received: (at 38051) by debbugs.gnu.org; 8 Nov 2019 00:36:24 +0000 Received: from localhost ([127.0.0.1]:44159 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iSsGF-0008Cc-Bl for submit@debbugs.gnu.org; Thu, 07 Nov 2019 19:36:23 -0500 Received: from host.gofardesign.uk ([208.79.239.190]:53823) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iSsGB-0008CN-B2 for 38051@debbugs.gnu.org; Thu, 07 Nov 2019 19:36:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=marxist.se; s=default; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=4IGwvl4pJWfo8sY5t4T9GCCsv3KcjslU4/jttkKW4fU=; b=oRkLMTHGpPOUUigqt8LF4biKL/ hJEVV2xzFlzdx2Y4dYHOj95/mA0VQkYD1UlL+8K45NLD+U5TTcB3OHbkLT8AZ+2qus6vb0YASldtc EXp+L1ZuxS62CFx3GxM2dSJdDb5gp0ZWO2Dp00MSxeovYyjF3OJBiY59mEpbgwMtsYNo=; Received: from h-70-69.a785.priv.bahnhof.se ([155.4.70.69]:53740 helo=localhost) by host.gofardesign.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1iSsG4-0003I1-BB; Thu, 07 Nov 2019 18:36:12 -0600 From: Stefan Kangas To: Drew Adams Subject: Re: bug#38051: 26.3; (elisp) `Insertion' use of verb "point" In-Reply-To: <10c2ca80-b3d5-4efb-a2b1-5ded0cc8a14d@default> (Drew Adams's message of "Sun, 3 Nov 2019 13:26:08 -0800 (PST)") References: <10c2ca80-b3d5-4efb-a2b1-5ded0cc8a14d@default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Date: Fri, 08 Nov 2019 01:36:10 +0100 Message-ID: <874kzfyzk5.fsf@marxist.se> MIME-Version: 1.0 Content-Type: text/plain X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.gofardesign.uk X-AntiAbuse: Original Domain - debbugs.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - marxist.se X-Get-Message-Sender-Via: host.gofardesign.uk: authenticated_id: stefan@marxist.se X-Authenticated-Sender: host.gofardesign.uk: stefan@marxist.se X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 38051 Cc: 38051@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Drew Adams writes: > In a few places this node uses the verb "to point" to refer to a > marker's position, as in the marker points to position N. > > This is unfortunate, as it makes the text confusing - especially so > because the text in the node refers often to "point" meaning, well, > point, the position of the cursor. Too many occurrences of "point", and > in some cases with different possible meanings (some of which are wrong). I agree with what Eli said in his reply, and I don't, in general, see any risk for confusion. In any case, I would suggest that we treat this on a case by case basis, rather than a one size fits all. You have pointed to three cases below, and I hope that you will find the following observations useful. > It would be better to just talk about the position of the marker, or the > position the marker has, than to talk about the position the marker > points to. > > Examples: > > 1. When a marker points at the place of insertion... > > 2. Certain special functions such as `insert-before-markers' relocate > all such markers to point after the inserted text, regardless of the > markers' insertion type. > > 3. ...it relocates markers initially pointing at the insertion point, to > point after the inserted text. > > #1 is not confusing or ambiguous. #2 and #3 can confuse you into > thinking that "point after the inserted text" is maybe talking about > point (the cursor position) being (just) after the inserted text, as if > the text had another comma: "relocate all such markers to point, after > the inserted text,..." > > Yes, lack of that comma does make the meaning clear, unless you read the > text carefully you can be confused or misled. > > If the text instead speaks of the position of a marker, or speaks of > where a marker "is", instead of speaking of where a marker "points", the > problem disappears. E.g.: > > 1. When a marker is at the place of insertion... I actually think it's more clear to say "points at" here, because the marker is really an object in memory that "points at" a buffer location. It is not actually in the buffer itself. > 2. Certain special functions such as `insert-before-markers' relocate > all such markers to be after the inserted text, regardless of the > markers' insertion type. I think the original reads better, and is more clear, as above. > 3. ...it relocates markers that are initially at the insertion point, to > be after the inserted text. The same reasoning applies here. > (This node also talks about "code point", which is a third meaning for > "point". But that's unavoidable, and the text is not confusing.) Agreed. Best regards, Stefan Kangas From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 08 12:53:19 2019 Received: (at 38051) by debbugs.gnu.org; 8 Nov 2019 17:53:19 +0000 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 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 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== 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 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 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 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 MIME-Version: 1.0 Message-ID: <3b0f7464-a74f-4687-b91b-b654697cc1cc@default> Date: Fri, 8 Nov 2019 17:53:06 +0000 (UTC) From: Drew Adams To: Stefan Kangas Subject: RE: bug#38051: 26.3; (elisp) `Insertion' use of verb "point" References: <10c2ca80-b3d5-4efb-a2b1-5ded0cc8a14d@default> <874kzfyzk5.fsf@marxist.se> 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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38051 Cc: 38051@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 08 14:11:56 2019 Received: (at 38051) by debbugs.gnu.org; 8 Nov 2019 19:11:56 +0000 Received: from localhost ([127.0.0.1]:47622 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iT9fo-0006Ng-CC for submit@debbugs.gnu.org; Fri, 08 Nov 2019 14:11:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49455) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iT9fm-0006NT-HC for 38051@debbugs.gnu.org; Fri, 08 Nov 2019 14:11:54 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53799) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iT9fh-0003P5-19; Fri, 08 Nov 2019 14:11:49 -0500 Received: from [176.228.60.248] (port=3649 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iT9ff-00013T-Ik; Fri, 08 Nov 2019 14:11:48 -0500 Date: Fri, 08 Nov 2019 21:11:38 +0200 Message-Id: <83a796b2tx.fsf@gnu.org> From: Eli Zaretskii To: Drew Adams In-reply-to: <3b0f7464-a74f-4687-b91b-b654697cc1cc@default> (message from Drew Adams on Fri, 8 Nov 2019 17:53:06 +0000 (UTC)) Subject: Re: bug#38051: 26.3; (elisp) `Insertion' use of verb "point" References: <10c2ca80-b3d5-4efb-a2b1-5ded0cc8a14d@default> <874kzfyzk5.fsf@marxist.se> <3b0f7464-a74f-4687-b91b-b654697cc1cc@default> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38051 Cc: 38051@debbugs.gnu.org, stefan@marxist.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 8 Nov 2019 17:53:06 +0000 (UTC) > From: Drew Adams > Cc: 38051@debbugs.gnu.org > > 1. From a user point of view (conceptual model), > markers _are_ objects that can be located > _in_ a buffer, _at_ buffer positions. That is incorrect. A marker stores a buffer and a location within that buffer, but it isn't itself located in a 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). See above: that's correct about characters, but incorrect about markers. > This is how we treat overlays. Overlays are completely different beasts. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 08 14:56:40 2019 Received: (at 38051) by debbugs.gnu.org; 8 Nov 2019 19:56:40 +0000 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 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 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== 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 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 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 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 MIME-Version: 1.0 Message-ID: Date: Fri, 8 Nov 2019 11:56:29 -0800 (PST) From: Drew Adams To: Eli Zaretskii , Drew Adams Subject: RE: bug#38051: 26.3; (elisp) `Insertion' use of verb "point" References: <<10c2ca80-b3d5-4efb-a2b1-5ded0cc8a14d@default>> <<874kzfyzk5.fsf@marxist.se>> <<3b0f7464-a74f-4687-b91b-b654697cc1cc@default>> <<83a796b2tx.fsf@gnu.org>> 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)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38051 Cc: 38051@debbugs.gnu.org, stefan@marxist.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 08 15:14:51 2019 Received: (at 38051) by debbugs.gnu.org; 8 Nov 2019 20:14:51 +0000 Received: from localhost ([127.0.0.1]:47674 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iTAeg-0001Up-Qv for submit@debbugs.gnu.org; Fri, 08 Nov 2019 15:14:51 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59313) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iTAee-0001UZ-8W for 38051@debbugs.gnu.org; Fri, 08 Nov 2019 15:14:48 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54826) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iTAeY-0000F4-Pn; Fri, 08 Nov 2019 15:14:42 -0500 Received: from [176.228.60.248] (port=3614 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iTAeY-0000IF-6p; Fri, 08 Nov 2019 15:14:42 -0500 Date: Fri, 08 Nov 2019 22:14:33 +0200 Message-Id: <8336eyazx2.fsf@gnu.org> From: Eli Zaretskii To: Drew Adams In-reply-to: (message from Drew Adams on Fri, 8 Nov 2019 11:56:29 -0800 (PST)) Subject: Re: bug#38051: 26.3; (elisp) `Insertion' use of verb "point" References: <<10c2ca80-b3d5-4efb-a2b1-5ded0cc8a14d@default>> <<874kzfyzk5.fsf@marxist.se>> <<3b0f7464-a74f-4687-b91b-b654697cc1cc@default>> <<83a796b2tx.fsf@gnu.org>> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38051 Cc: 38051@debbugs.gnu.org, stefan@marxist.se X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 8 Nov 2019 11:56:29 -0800 (PST) > From: Drew Adams > Cc: stefan@marxist.se, 38051@debbugs.gnu.org > > > > 1. From a user point of view (conceptual model), > > > markers _are_ objects that can be located > > > _in_ a buffer, _at_ buffer positions. > > > > 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". Of course it can. And it is. > It's a question of what the user needs as a > conceptual model to work with markers (and > overlays, for that matter). Wrong conceptual models will bite you down the road. It is best to have correct conceptual models. > > 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? No. Like I said: it's a different beast. > 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? Convenience and clarity of description. And please, can we stop this bikeshedding? It goes nowhere. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 09 09:55:22 2019 Received: (at 38051) by debbugs.gnu.org; 9 Nov 2019 14:55:22 +0000 Received: from localhost ([127.0.0.1]:49022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iTS93-0000vT-Qf for submit@debbugs.gnu.org; Sat, 09 Nov 2019 09:55:22 -0500 Received: from mail-pg1-f172.google.com ([209.85.215.172]:37461) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iTS91-0000p1-NE for 38051@debbugs.gnu.org; Sat, 09 Nov 2019 09:55:20 -0500 Received: by mail-pg1-f172.google.com with SMTP id z24so6090539pgu.4 for <38051@debbugs.gnu.org>; Sat, 09 Nov 2019 06:55:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ktbhwxXOlD1VW2r0bR+Cpi8SFxWZwChmg0kfSvNFhLo=; b=iFTJyyGVV8M/67wC9M05Zy/jKugmLErbj1XTnzSINbiROKetJrSUp8UxJ1Eu5nLP/N C1eAq0D5R92eBv00BnN/WA838KPGsydm6pjw4IWGOdzI6oBmudpjZvGjDVkC2H6mYs6O UBRX8xYbdkEHBz/kMC3k98ZVa1ZjtVqAbD90XKimQMz8XKLJepLj5yYUSntD6rTeAzdW ODPdWkQ7B+50S6gs17hhPxuAhgHckzXVSLFkiJwLwIdvPkznG7e9MY1icOFKAyBl0GW7 /WtKU9r0dxBGFUL5J6Vayy6aI2mT5IS9o0+FLz6wjqzDsDgJH2Ago37IwbPCQn2xycN1 wB+Q== X-Gm-Message-State: APjAAAV8NjIvEBPIeLKXxgMU1jECqyihWijHX/olnB981npG/hPzXka9 HIOwzBeRKHgq/NQJfKX1ytynk0voov+Ye62F4yw= X-Google-Smtp-Source: APXvYqx7LA7Vvc72mHKYhzVDj/IJnVDbgrcOSwnDd0d/iSZZs5WRLc8EfN1zVmd5ZkKXBnk2O92rIueZHENMSosNAn4= X-Received: by 2002:a62:7f93:: with SMTP id a141mr18853319pfd.107.1573311313863; Sat, 09 Nov 2019 06:55:13 -0800 (PST) MIME-Version: 1.0 References: <8336eyazx2.fsf@gnu.org> In-Reply-To: <8336eyazx2.fsf@gnu.org> From: Stefan Kangas Date: Sat, 9 Nov 2019 15:55:02 +0100 Message-ID: Subject: Re: bug#38051: 26.3; (elisp) `Insertion' use of verb "point" To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 38051 Cc: 38051@debbugs.gnu.org, Drew Adams X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) tags 38051 + wontfix close 38051 thanks Eli Zaretskii writes: > > It's a question of what the user needs as a > > conceptual model to work with markers (and > > overlays, for that matter). > > Wrong conceptual models will bite you down the road. It is best to > have correct conceptual models. I think this is the key here, not least because we are discussing the Emacs Lisp manual. I think we can indeed agree to disagree, while the decision seems to be to not make any changes along the suggested lines. I'm therefore closing this bug report. Thanks. Best regards, Stefan Kangas From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 09 09:58:32 2019 Received: (at control) by debbugs.gnu.org; 9 Nov 2019 14:58:32 +0000 Received: from localhost ([127.0.0.1]:50155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iTSC8-0001Hi-C6 for submit@debbugs.gnu.org; Sat, 09 Nov 2019 09:58:32 -0500 Received: from mail-pl1-f178.google.com ([209.85.214.178]:40228) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iTSC7-0001HT-Gg for control@debbugs.gnu.org; Sat, 09 Nov 2019 09:58:31 -0500 Received: by mail-pl1-f178.google.com with SMTP id e3so5615807plt.7 for ; Sat, 09 Nov 2019 06:58:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MQ/JUvbDFO6XLxGRPZgFbHBB62hyFNuzeV+2KNWL6bU=; b=TxPKIt3/gcZC+6yh6rQ1PzYHhkDKbl9/cUTBPOzRg1I3aMfQB9S1FP74T3xGIQYxJI psaVLChBKqqLceanMJ/XysAKzGlpg98gHSwgmFiK2I15+5ZIg6jCPEfiacSqNVYf/C6V xn7OQ2NH/+ZGCk8C3VVO64Go3/br3EVjKWcLzxGwY8jXlpAhLGi08ZbQFkNPqGCV2zbD acvjIuPwMM93nrbY4xouPsh4GLwd80r5rpaMBFMX13YRmC9as/YSboSXBXo0LfbCBmnG 9HDnwZxhooggGwaiUYxkoO/UA8LdWlw3uQyFZ97b46DitOLDi9ojt9Q/7wFwrBonikPX wLcA== X-Gm-Message-State: APjAAAWVwNG8/+MWjUvRkuE8YoHj1E4+xZ+eZIV6lfY09H+XbnVD+vks ZD2H1ccucP2AGw/wZu1B5Oc+5YgLtJGp5tDFyIt9wA== X-Google-Smtp-Source: APXvYqwPRXIaH/gUgQ/25zP+HMIC22LSgMbnavmj7s2bdhTowUb2keOWttH0WMieYsmANkV01TbRLOBK5k4u/hYiaec= X-Received: by 2002:a17:902:b482:: with SMTP id y2mr7888307plr.128.1573311504305; Sat, 09 Nov 2019 06:58:24 -0800 (PST) MIME-Version: 1.0 From: Stefan Kangas Date: Sat, 9 Nov 2019 15:58:13 +0100 Message-ID: Subject: To: control@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 2.3 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: tags 38051 + notabug thanks Content analysis details: (2.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stefankangas[at]gmail.com) 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.214.178 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.214.178 listed in list.dnswl.org] 2.0 BLANK_SUBJECT Subject is present but empty 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: tags 38051 + notabug thanks Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [209.85.214.178 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.214.178 listed in list.dnswl.org] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stefankangas[at]gmail.com) 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager 2.0 BLANK_SUBJECT Subject is present but empty 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders tags 38051 + notabug thanks From unknown Fri Jun 13 10:47:13 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 08 Dec 2019 12:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator