all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Drew Adams <drew.adams@oracle.com>
Cc: michael_heerdegen@web.de, 23067@debbugs.gnu.org
Subject: bug#23067: 25.0.92; A detail in the doc of query-replace
Date: Fri, 25 Mar 2016 07:41:58 -0700 (PDT)	[thread overview]
Message-ID: <f0e7282f-e005-4ce2-b34c-600cef039a59@default> (raw)
In-Reply-To: <<837fgq1vr4.fsf@gnu.org>>

> > > However, I must say that it makes very little sense to me to make such
> > > corrections only in a couple of functions, when we have gobs of them
> > > with the same problem in the doc strings, so much so that I wonder
> > > whether "end of buffer" isn't already a widely accepted synonym of
> > > "end of the buffer's accessible portion", and we shouldn't bother,
> > > certainly not with fixing that one function at a time.  I won't be
> > > surprised if the same issue has crept in the manuals as well.
> > >
> > > Please, let's not start another prolonged dispute that leads nowhere.
> > > Instead, if someone really thinks this stuff should be spelled out in
> > > documentation, that someone is kindly requested to submit a patch that
> > > fixes _all_ of the instances where we don't say that explicitly.  TIA.
> >
> > There's another way to look at this that occurs to me.  It is also
> > perhaps not without some ambiguity, but it might nevertheless help.
> >
> > "End of buffer" can be regarded as `point-max'.
> 
> What do you mean "can be"?  I was saying that it already is regarded
> as such.

OK, "is", then.  I wrote "can be" because I think it can also be
regarded as the end of the buffer without regard to any possible
restriction.

I thought the point of this bug report was to distiguish end of
buffer in this sense from last buffer position without regard to
restriction.

If "end of buffer" is always understood as `point-max' then the
missing term is for the latter - the end of the buffer when any
restriction is ignored.

> > This is what we say in the doc string of the predicate (`eobp') that
> > determines (tests for) end-of-buffer-ness:
> >
> >  Return t if point is at the end of the buffer.
> >  If the buffer is narrowed, this means the end of the narrowed part.
> 
> Are you saying we should change all the similar doc strings to say the
> same?  If so, how is this different from what I said above, about the
> need to change all of them?

I'm not saying we should change all of anything.  I'm simply
pointing out that "end of buffer" really does sometimes (you might
say always) mean `point-max' - in particular, it does for the
description of `eobp'.  So changing "end of buffer" to text that
says `point-max' should not be necessary, if we are clear that
"end of buffer" means `point-max'.

But in that case, we will sometimes want to refer to the end of
the buffer without restriction.  AFAIK, we don't have a short
name for that.

And I believe we do sometimes say something like "the end of
the buffer, or the end of its accessible portion if it is
narrowed".

If we do say things like that then that gives credence to an
impression that "end of buffer" might not always mean
`point-max' (otherwise, we would not contrast it with a
description of the buffer end when there is a restriction).





       reply	other threads:[~2016-03-25 14:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <<<87oaa9vrdz.fsf@web.de>
     [not found] ` <<<83k2kq27j0.fsf@gnu.org>
     [not found]   ` <<42d06a78-824b-4661-aa84-845def8ca855@default>
     [not found]     ` <<837fgq1vr4.fsf@gnu.org>
2016-03-25 14:41       ` Drew Adams [this message]
2016-03-25 15:55         ` bug#23067: 25.0.92; A detail in the doc of query-replace Michael Heerdegen
2016-03-25 16:08           ` Drew Adams
     [not found] <<87oaa9vrdz.fsf@web.de>
     [not found] ` <<83k2kq27j0.fsf@gnu.org>
2016-03-25 14:13   ` Drew Adams
2016-03-25 14:23     ` Eli Zaretskii
2016-03-20  2:02 Michael Heerdegen
2016-03-20  2:14 ` Drew Adams
2016-03-25 10:09 ` Eli Zaretskii
2016-03-26 22:06   ` John Wiegley

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

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

  git send-email \
    --in-reply-to=f0e7282f-e005-4ce2-b34c-600cef039a59@default \
    --to=drew.adams@oracle.com \
    --cc=23067@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=michael_heerdegen@web.de \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.