From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#24663: 24.5; doc string of `completion-at-point-functions' Date: Thu, 13 Oct 2016 14:18:53 -0700 (PDT) Message-ID: <1efe9646-66d2-4d9b-b557-9911e148cb63@default> References: <<<2178d9e1-fd5c-4045-9a10-d0c45b0de591@default> <<<83fuo088wa.fsf@gnu.org> <<225e9a9e-eaa2-4c6a-96f8-7106a9817491@default> <<83eg3k815a.fsf@gnu.org> <30cc62fc-abee-4f28-9677-82c610b841c5@default> <94371f44-4d03-64f2-ed88-edff3546a399@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1476393632 8303 195.159.176.226 (13 Oct 2016 21:20:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 13 Oct 2016 21:20:32 +0000 (UTC) Cc: 24663@debbugs.gnu.org To: Dmitry Gutov , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 13 23:20:28 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bunQH-0000BM-ON for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Oct 2016 23:20:17 +0200 Original-Received: from localhost ([::1]:43049 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bunQG-0007UT-37 for geb-bug-gnu-emacs@m.gmane.org; Thu, 13 Oct 2016 17:20:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bunQ6-0007R5-EB for bug-gnu-emacs@gnu.org; Thu, 13 Oct 2016 17:20:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bunQ2-0000LI-4Q for bug-gnu-emacs@gnu.org; Thu, 13 Oct 2016 17:20:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48356) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bunQ2-0000LC-1L for bug-gnu-emacs@gnu.org; Thu, 13 Oct 2016 17:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bunQ1-0000qG-RS for bug-gnu-emacs@gnu.org; Thu, 13 Oct 2016 17:20:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Oct 2016 21:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24663 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24663-submit@debbugs.gnu.org id=B24663.14763935463170 (code B ref 24663); Thu, 13 Oct 2016 21:20:01 +0000 Original-Received: (at 24663) by debbugs.gnu.org; 13 Oct 2016 21:19:06 +0000 Original-Received: from localhost ([127.0.0.1]:54546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bunP8-0000p4-0o for submit@debbugs.gnu.org; Thu, 13 Oct 2016 17:19:06 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:26978) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bunP5-0000oZ-DD for 24663@debbugs.gnu.org; Thu, 13 Oct 2016 17:19:03 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u9DLIvYf013952 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 13 Oct 2016 21:18:57 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u9DLIu8Y007828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Oct 2016 21:18:56 GMT Original-Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u9DLIsTq029828; Thu, 13 Oct 2016 21:18:55 GMT In-Reply-To: <94371f44-4d03-64f2-ed88-edff3546a399@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] 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" Xref: news.gmane.org gmane.emacs.bugs:124450 Archived-At: > >>> 1. It cannot be "THE" thing (or THE entity) at point. Which one? > >> > >> The one at point. > > > > The symbol? word? file name? URL? ... (yes, ... - there are any > > number of kinds of things, most of which - nay, all of which - > > could be completed. >=20 > The code in the hooks decides that. In practice, it's a part of a major > or a minor mode. Exactly. That's what should be said. Some text before point can get completed. The completing code decides (1) WHICH text before point (what kind of thing, if you want to think of it that way) and (2) what the possible COMPLETIONS of it are. > >> My understanding is that it's up to the hooks. > > > > Then them most that the doc can & should say is that SOMETHING >=20 > What does that mean? >=20 > > (some text) BEFORE point, is susceptible to completion. >=20 > AROUND point. Really? In that case, that's what needs to be said in the doc. Of course, if it is AROUND point then presumably any text in the buffer can be used to determine what's to be completed (and in turn what the possible completions are). It could use only the first two or last six characters of the buffer, ignoring the text immediately surrounding point. It sounds like the real point (sic) is this: The completion functions (1) are passed point, and (2) they can do anything they want, to complete any bits of text existing anywhere in the buffer (or even perhaps ignoring all text in the buffer). And presumably, after the user chooses one of the completion candidates, that candidate is inserted at point. If this (or similar0 is the behavior then it is what should be said in the doc. There should be nothing additional and gratuitous, that implies that the text immediately preceding or following (or both) point is what gets completed. And it certainly should not speak in terms of any "thing" or "entity" at (or before or after or around) point.