From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#23067: 25.0.92; A detail in the doc of query-replace Date: Fri, 25 Mar 2016 07:41:58 -0700 (PDT) Message-ID: References: <<<87oaa9vrdz.fsf@web.de>>> <<<83k2kq27j0.fsf@gnu.org>>> <<42d06a78-824b-4661-aa84-845def8ca855@default>> <<837fgq1vr4.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1458917010 14472 80.91.229.3 (25 Mar 2016 14:43:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Mar 2016 14:43:30 +0000 (UTC) Cc: michael_heerdegen@web.de, 23067@debbugs.gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 25 15:43:15 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ajSxG-0000KQ-Jr for geb-bug-gnu-emacs@m.gmane.org; Fri, 25 Mar 2016 15:43:14 +0100 Original-Received: from localhost ([::1]:56512 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajSxC-0004eB-Qk for geb-bug-gnu-emacs@m.gmane.org; Fri, 25 Mar 2016 10:43:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49843) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajSx8-0004dc-RD for bug-gnu-emacs@gnu.org; Fri, 25 Mar 2016 10:43:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ajSx4-0006n7-L1 for bug-gnu-emacs@gnu.org; Fri, 25 Mar 2016 10:43:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40845) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajSx4-0006n1-HV for bug-gnu-emacs@gnu.org; Fri, 25 Mar 2016 10:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ajSx4-0005kA-AV for bug-gnu-emacs@gnu.org; Fri, 25 Mar 2016 10:43:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 25 Mar 2016 14:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23067 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23067-submit@debbugs.gnu.org id=B23067.145891692822016 (code B ref 23067); Fri, 25 Mar 2016 14:43:02 +0000 Original-Received: (at 23067) by debbugs.gnu.org; 25 Mar 2016 14:42:08 +0000 Original-Received: from localhost ([127.0.0.1]:37972 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ajSwC-0005j2-4Z for submit@debbugs.gnu.org; Fri, 25 Mar 2016 10:42:08 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:40441) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ajSwA-0005iX-WB for 23067@debbugs.gnu.org; Fri, 25 Mar 2016 10:42:07 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2PEg0AA016756 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 25 Mar 2016 14:42:01 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u2PEg0qU018745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 25 Mar 2016 14:42:00 GMT Original-Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u2PEfx3L001798; Fri, 25 Mar 2016 14:41:59 GMT In-Reply-To: <<837fgq1vr4.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] 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: 208.118.235.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:115481 Archived-At: > > > However, I must say that it makes very little sense to me to make suc= h > > > 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 tha= t > > > 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'. >=20 > 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. >=20 > 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).