unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Kangas <stefan@marxist.se>
To: Drew Adams <drew.adams@oracle.com>
Cc: 38051@debbugs.gnu.org
Subject: bug#38051: 26.3; (elisp) `Insertion' use of verb "point"
Date: Fri, 08 Nov 2019 01:36:10 +0100	[thread overview]
Message-ID: <874kzfyzk5.fsf@marxist.se> (raw)
In-Reply-To: <10c2ca80-b3d5-4efb-a2b1-5ded0cc8a14d@default> (Drew Adams's message of "Sun, 3 Nov 2019 13:26:08 -0800 (PST)")

Drew Adams <drew.adams@oracle.com> 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





  parent reply	other threads:[~2019-11-08  0:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-03 21:26 bug#38051: 26.3; (elisp) `Insertion' use of verb "point" Drew Adams
2019-11-04 17:23 ` Eli Zaretskii
2019-11-08  0:36 ` Stefan Kangas [this message]
2019-11-08 17:53   ` Drew Adams
2019-11-08 19:11     ` Eli Zaretskii
     [not found] <<10c2ca80-b3d5-4efb-a2b1-5ded0cc8a14d@default>
     [not found] ` <<83sgn3h7yj.fsf@gnu.org>
2019-11-04 18:10   ` Drew Adams
2019-11-04 18:36     ` Eli Zaretskii
     [not found] ` <<874kzfyzk5.fsf@marxist.se>
     [not found]   ` <<3b0f7464-a74f-4687-b91b-b654697cc1cc@default>
     [not found]     ` <<83a796b2tx.fsf@gnu.org>
2019-11-08 19:56       ` Drew Adams
2019-11-08 20:14         ` Eli Zaretskii
2019-11-09 14:55           ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874kzfyzk5.fsf@marxist.se \
    --to=stefan@marxist.se \
    --cc=38051@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).